libtool missing --tag=LD for linking.

[warmerdam]

A GDAL 1.9.0 libtool based build on a modern Ubuntu system resulted in:

./ogr/ogr2gmlgeometry.lo ./ogr/gml2ogrgeometry.lo ./ogr/ogr_expat.lo ./ogr/ogrpgeogeometry.lo ./ogr/ogrgeomediageometry.lo \
      -rpath /usr/local/lib \
      -no-undefined \
      -version-info 17:0:16
libtool: link: unable to infer tagged configuration
libtool: link: specify a tag with `--tag'

[warmerdam]

Based on  http://www.linuxquestions.org/questions/linux-newbie-8/libtool-link-error-311506/ I believe the solution is to include --tag=LD in the LIBTOOL_LINK directive in the GDALmake.opt file.

[warmerdam]

I think I have fixed this in trunk (r23745). Corey - could you try hand applying that change in your tree and confirm a clean default build (with libtool) works now? If you can confirm it, I'll back port it to 1.9 and perhaps even 1.8.

[j03lar50n]

Replying to j03lar50n: confirming that http://trac.osgeo.org/gdal/changeset/23745 works on machine Corey was using.

[warmerdam]

I'll keep this reopened until I've back patched this into 1.9 and 1.8 branches tonight.

[warmerdam]

Patch applied in 1.9 (r23755) and 1.8 (r23756) branches.

[warmerdam]

In #4557 dustymugs reports:

""" The addition of --tag=LD in r23745 prevents GDAL trunk from compiling to completion. If --tag=LD is removed, GDAL trunk compiles successfully.

In the compile output, libtool outputs the following

libtool: link: ignoring unknown tag LD

The above message is also present in the output on Linux 64-bit but Linux compiles successfully with or without --tag=LD """

and this is confirmed by jorgearevalo on Mac OS X 10.6.8 with the comment:

""" I confirm the problem. The addition of --tag=LD breaks my build in Mac OS X 10.6.8. It compiles fine if removed. """

[warmerdam]

dustymugs, could you confirm the OS configuration you ran into this on?

I'm wondering if this is a MacOS specific problem or not.

Also, were you guys building from trunk? 1.9-branch?

[dustymugs]

warmerdam,

The problem occurs on OSX 10.6.8

Darwin osx.local 10.8.0 Darwin Kernel Version 10.8.0: Tue Jun  7 16:33:36 PDT 2011; root:xnu-1504.15.3~1/RELEASE_I386 i386

GCC

Using built-in specs.
Target: i686-apple-darwin10
Configured with: /var/tmp/gcc/gcc-5666.3~6/src/configure --disable-checking --enable-werror --prefix=/usr --mandir=/share/man --enable-languages=c,objc,c++,obj-c++ --program-transform-name=/^[cg][^.-]*$/s/$/-4.2/ --with-slibdir=/usr/lib --build=i686-apple-darwin10 --program-prefix=i686-apple-darwin10- --host=x86_64-apple-darwin10 --target=i686-apple-darwin10 --with-gxx-include-dir=/include/c++/4.2.1
Thread model: posix
gcc version 4.2.1 (Apple Inc. build 5666) (dot 3)

I'm building on trunk. 1.9.0 doesn't have this issue.

One thing worth noting is that the docs for libtool does not have LD as a recognized tag...

 http://www.gnu.org/software/libtool/manual/html_node/Tags.html

[ajolma]

Frank,

Setting the TAG makes the linking fail in the latest MinGW/MSYS too. The symptom is strange (lots of undefined references to system functions) and it was not at all obvious that removing it would be the solution.

Ari

[warmerdam]

While I'm not sure what revision it occured in, it appears I have backed this change out of 1.9 and possible other trees since it is seemingly fundamentally wrong. I am not sure why I didn't update this ticket at the time.

[kyngchaos]

Just some clarification from what I'm seeing on OS X - when libtool is passed:

--mode=link --tag=LD	g++

it spits back that error about ignoring an unknown tag, and in the link command gcc is used to link, not the g++ that was passed to libtool (this was not mentioned in above comments). So there seems to be a bug in libtool to fall back to gcc when it encounters an unknown tag.

[natevw]

This may happen if GDAL is ./configure'd *before* g++ is installed. My default Ubuntu installation did not have this installed when I first ran, and I got the same build error. I was unable to fix it by adding --tag=LD to the make script include, but hopeful that a clean build with all the dependencies will fix it by morning.

[bidandou]

the section of FileGDBAPI should look like : # # FileGDB # HAVE_FGDB = yes FGDB_LIB = -L/home/ali/Téléchargements/gdal-1.9.1/FileGDB_API/lib -lFileGDBAPI -lfgdbunixrtl FGDB_INC = -I/home/ali/Téléchargements/gdal-1.9.1/FileGDB_API/include

[warmerdam]

I have reverted the use of --tag=LD in trunk too (r25195). Still not sure what the best solution to this problem is.

[rburhum]

I tried with Ubuntu 12.04.1 LTS & Ubuntu 12.10 (trunk and gdal 1.9.2). All four builds worked fine.

From natevw's comment, it seems to be related to a system without g++ or build-essentials installed.

Closing. If any objections, please re-open.