Opened 21 years ago
Last modified 21 years ago
#447 closed defect (duplicate)
link error trying to build GDAL
Reported by: | Owned by: | warmerdam | |
---|---|---|---|
Priority: | high | Milestone: | |
Component: | default | Version: | unspecified |
Severity: | normal | Keywords: | |
Cc: |
Description
In building GDAL on FreeBSD, experiencing another problem distinct from the one I reported in #446. After making the various makefile fixes I employed to get -I/usr/local/include where it belonged, now I'm getting a link error late in the game: g++ ogrinfo.o -o .libs/ogrinfo ../.libs/libgdal.so -lodbc -ljasper -lmfhdf -ldf -ljpeg -lgeotiff -ltiff -lpng -lgrass5 -lz -L/usr/local/lib -lpq -Wl,--rpath -W l,/usr/local/lib ../.libs/libgdal.so: undefined reference to `RegisterOGRODBC' gmake[1]: *** [ogrinfo] Error 1 On investigation with "nm" on the libgdal.so file, I see: U RegisterOGRODBC 00173ff0 T RegisterOGRODBC__Fv On further digging, I find that the undefined reference to RegisterOGRODBC is in ogr/ogrsf_frmts/generic/ogrregisterall.cpp, and the file ogr/ogrsf_frmts/generic/ogrodbcdriver.cpp is the one producing the entry RegisterOGRODBC__Fv: > nm ogr/ogrsf_frmts/o/ogrregisterall.o | grep OGRODBC U RegisterOGRODBC > nm ogr/ogrsf_frmts/o/ogrodbcdriver.o | grep RegisterOGRODBC 000002d4 T RegisterOGRODBC__Fv So somewhere the mangling of the definition: void RegisterOGRODBC() in ogrodbcdriver.cpp and the prototype: void CPL_DLL RegisterOGRODBC(); in ogrsf_frmts.h aren't meshing. What I am finding extremely curious is how the definition of RegisterOGRODBC is getting mangled in an entirely different way than, say, RegisterOGRPG, which doesn't wind up with the __Fv suffix in its corresponding ogr__driver.o file, nor are any of the other ogr__driver.o's getting this weird twist on their RegisterOGRXXX symbols. I don't see any obvious difference in the way things are defined in the prototypes or in the code between, the PG and ODBC packages, but nm doesn't lie, that __Fv must be coming from someplace. This compilation is happening with gcc 2.95.4 as distributed with FreeBSD. As I write this I'm downloading and building GCC 3.2 to see if it's a GCC version issue. Will post again with a follow-up if I can pin anything down.
Change History (3)
comment:2 by , 21 years ago
You hit the nail on the head! Yes, the ODBC directory GNUmakefile does: CPPFLAGS += -I.. -I../.. which has the effect of adding the -I's *after* the -I/usr/local/include that's already in CPPFLAGS instead of before, and yes, that makes the thing find the one in /usr/local/include instead. Changing this to CPPFLAGS := -I.. -I../.. $(CPPFLAGS) appears to fix the problem. I will go back and add this to the comments on #446 as well. This bug is properly marked a duplicate of 446, then.
Note:
See TracTickets
for help on using tickets.