Opened 12 years ago

Closed 12 years ago

#1644 closed defect (fixed)

Cannot build on Debian Wheezy (parser file gets rewritten)

Reported by: darkblueb Owned by: pramsey
Priority: medium Milestone: PostGIS 2.0.0
Component: postgis Version: master
Keywords: build make loader shp2pgsql Cc:


Fails when building shp2pgsql

Background: I had a wheezy system setup in a VM, and had been using it for a number of months to test with.. but sometime recently the build no longer completed.. So thinking it might be something on my side, I built a new VM with the latest and greatest Debian, and Pg 9.1 from package.. Same error…

make[1]: Entering directory `/home/shared/srcs_wheezy/postgis_trunk/loader' /bin/bash ../libtool —mode=link gcc -g -O2 -fPIC -DPIC -Wall -Wmissing-prototypes shpopen.o dbfopen.o getopt.o shp2pgsql-core.o shpcommon.o shp2pgsql-cli.o safileio.o ../liblwgeom/ -o shp2pgsql -lc libtool: link: gcc -g -O2 -fPIC -DPIC -Wall -Wmissing-prototypes shpopen.o dbfopen.o getopt.o shp2pgsql-core.o shpcommon.o shp2pgsql-cli.o safileio.o -o .libs/shp2pgsql ../liblwgeom/.libs/ -lc ../liblwgeom/.libs/ undefined reference to `wkt_yylex' ../liblwgeom/.libs/ undefined reference to `wkt_lexer_init' ../liblwgeom/.libs/ undefined reference to `wkt_lexer_close' collect2: ld returned 1 exit status make[1]: * [shp2pgsql] Error 1 make[1]: Leaving directory `/home/shared/srcs_wheezy/postgis_trunk/loader' make: * [all] Error 1

Configure output:

PostGIS is now configured for i686-pc-linux-gnu

——————— Compiler Info ——————-

C compiler: gcc -g -O2 C++ compiler: g++ -g -O2

——————— Dependencies ———————

GEOS config: /usr/local/bin/geos-config GEOS version: 3.3.2 PostgreSQL config: /usr/bin/pg_config PostgreSQL version: PostgreSQL 9.1.2 PROJ4 version: 47 Libxml2 config: /usr/bin/xml2-config Libxml2 version: 2.7.8 JSON-C support: yes PostGIS debug level: 0 Perl: /usr/bin/perl

———————- Extensions ———————-

PostGIS Raster: disabled PostGIS Topology: enabled

———— Documentation Generation ————

Change History (11)

comment:1 by darkblueb, 12 years ago

Version: 1.5.Xtrunk

comment:2 by strk, 12 years ago

Sounds like a dirty source tree, do you have a way to verify ? Fetched code from SVN ?

comment:3 by pramsey, 12 years ago

This all traces back to *f@#*$!F(($*(# libtool and the which I so despise. Forcing the commandline utilities (r9401 ) to link statically in libtool fixes the problem in building, but hey presto, you still can't win, because the won't load, for the same reason.

psql:/home/dbb/PRamseyBuild/postgis-svn/regress/00-regress-install/share/contrib/postgis/postgis.sql:69: ERROR:  could not load library "/home/dbb/PRamseyBuild/postgis-svn/regress/00-regress-install/lib/": /home/dbb/PRamseyBuild/postgis-svn/regress/00-regress-install/lib/ undefined symbol: wkt_yylex

Sure would be nice to have our internal library linked statically.

comment:4 by strk, 12 years ago

We supposedly do have the module statically linked to liblwgeom:

postgis/regress(svn-trunk)] ldd 00-regress-install/lib/ =>  (0x00007fff89fff000) => /usr/local/lib/ (0x00007f46e023f000) => /usr/local/lib/ (0x00007f46dfff0000) => /usr/lib/ (0x00007f46dfc9f000) => /lib/ (0x00007f46df91c000) => /usr/local/lib/ (0x00007f46df57e000) => /usr/lib/ (0x00007f46df269000) => /lib/ (0x00007f46defe6000) => /lib/ (0x00007f46dedcf000) => /lib/ (0x00007f46debca000) => /lib/ (0x00007f46de9b3000)
        /lib64/ (0x00007f46e072d000)

We are not even using libtool to build that library. Run "make" from under postgis/ dir. This is the last line I have:

gcc -g -O2 -g -Wall -O2 -fPIC -Wall -Wmissing-prototypes -Wpointer-arith -Wdeclaration-after-statement -Wendif-labels -fno-strict-aliasing -fwrapv -g -fpic -shared  postgis_module.o lwgeom_accum.o lwgeom_spheroid.o lwgeom_ogc.o lwgeom_functions_analytic.o lwgeom_inout.o lwgeom_functions_basic.o lwgeom_btree.o lwgeom_box.o lwgeom_box3d.o lwgeom_cache.o lwgeom_geos.o lwgeom_geos_prepared.o lwgeom_geos_clean.o lwgeom_geos_relatematch.o lwgeom_export.o lwgeom_in_gml.o lwgeom_in_kml.o lwgeom_in_geojson.o lwgeom_triggers.o lwgeom_dump.o lwgeom_functions_lrs.o long_xact.o lwgeom_sqlmm.o lwgeom_rtree.o lwgeom_transform.o gserialized_typmod.o gserialized_gist_2d.o gserialized_gist_nd.o geography_inout.o geography_btree.o geography_estimate.o geography_measurement.o geometry_estimate.o  ../liblwgeom/.libs/liblwgeom.a ../libpgcommon/libpgcommon.a  -L/usr/local/lib  -lgeos_c -lproj  -lxml2    -L/usr/lib  -o

With no trace of libtool invokation.

comment:5 by strk, 12 years ago

Alright, I confirm it is the parser file being regenerated. Newly cloned tree, ./ && ./configure && make && svn status:

../liblwgeom/.libs/ undefined reference to `wkt_yylex'
../liblwgeom/.libs/ undefined reference to `wkt_lexer_init'
../liblwgeom/.libs/ undefined reference to `wkt_lexer_close'
collect2: ld returned 1 exit status
make[1]: *** [shp2pgsql] Error 1
make: *** [all] Error 1
dbb@wheezy-vm:~/strk/src/postgis/trunk$ svn status
?       ERR
M       liblwgeom/lwin_wkt_lex.c

After an "svn revert -R ." and a second "make":

make[1]: Leaving directory `/home/dbb/strk/src/postgis/trunk/utils'
PostGIS was built successfully. Ready to install.

Also "make check" works fine.

This bug focus should be on finding _why_ the parser files get rewritten. And _when_ !!

comment:6 by strk, 12 years ago

Summary: Cannot build on Debian WheezyCannot build on Debian Wheezy (parser file gets rewritten)

comment:7 by strk, 12 years ago

It is "make" under liblwgeom:

dbb@wheezy-vm:~/strk/src/postgis/trunk/liblwgeom$ svn status
dbb@wheezy-vm:~/strk/src/postgis/trunk/liblwgeom$ make > make.out 2> make.err
dbb@wheezy-vm:~/strk/src/postgis/trunk/liblwgeom$ svn status
?       make.out
?       make.err
M       lwin_wkt_lex.c
bb@wheezy-vm:~/strk/src/postgis/trunk/liblwgeom$ grep lwin_wkt_lex.c make.*
make.out::  -t lwin_wkt_lex.l > lwin_wkt_lex.c

Last line is interesting: ":" is the value of LEX in the Makefile. I can't find no rule explicitly requesting construction of lwin_wkt_lex though, so maybe it's a builtin feature of make ?

comment:8 by strk, 12 years ago

Owner: changed from pramsey to strk
Status: newassigned

Yes, it's a builtin !!! Like with .o targets, using CC, .c targets in presence of .l use LEX. Try this:

cd liblwgeom
touch test.l
make test.c

It'll use $(LEX) -t test.l > test.c

In our case $(LEX) will evaluate to ":" thus producing an empty test.c

comment:9 by strk, 12 years ago

Owner: changed from strk to pramsey
Status: assignednew

Actually fixing it is left as an exercise to the reader ;) .. seriously, I'm off for today ..

comment:10 by pramsey, 12 years ago

OK, confirmed, on a clean check-out the .c file is regenerated, and, if I carefully substitute it with the svn version and build, I can get a working build and make check works.

comment:11 by pramsey, 12 years ago

Resolution: fixed
Status: newclosed

Kinda fixed at r9411. At least, we don't over-write the generated lexer file anymore. The parser doesn't seem to have the same problem (no default rule perhaps).

Note: See TracTickets for help on using tickets.