Opened 21 years ago

Last modified 21 years ago

#447 closed defect (duplicate)

link error trying to build GDAL

Reported by: russo@… 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:1 by warmerdam, 21 years ago

Thomas, 

I am pretty certain the problem you are running into is that an old
ogrsf_frmts.h is being used that does not include a prototype for 
the RegisterOGRODBC() function marking it as C linkage.  Thus it defaults
to using C++ linkage with funky extra bits on the name. 

I would assume this comes down to using an old ogrsf_frmts.h from
/usr/local/include.  

Could you verify that my guess is right?  Note that you will need to force
the code in the gdal/ogr/ogrsf_frmts/odbc directory to be recompiled so that
the register function will be emitted in the object file with the correct
linkage (naming convention).  Doing a make clean, and make with the latest
CVS might fix up the problem if Andrey's fixes from #446 are comprehensive. 
If not, let me know what you find and I may turn this one over to Andrey to 
dig into as well. 

Thanks for the bugs!

comment:2 by russo@…, 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.

comment:3 by russo@…, 21 years ago


*** This bug has been marked as a duplicate of 446 ***
Note: See TracTickets for help on using tickets.