Opened 6 years ago

Closed 5 years ago

Last modified 2 years ago

#4436 closed defect (worksforme)

libtool missing --tag=LD for linking.

Reported by: warmerdam Owned by: warmerdam
Priority: normal Milestone: 1.9.1
Component: ConfigBuild Version: 1.9.0
Severity: normal Keywords: libtool
Cc: frewsxcv, dustymugs, jorgearevalo

Description

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'

Attachments (1)

diff (660 bytes) - added by Ari Jolma 2 years ago.
Patch for configure.in

Download all attachments as: .zip

Change History (22)

comment:1 Changed 6 years ago by warmerdam

Milestone: 1.9.1
Version: unspecified1.9.0

comment:2 Changed 6 years ago by 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.

comment:3 Changed 6 years ago by warmerdam

Status: newassigned

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.

comment:4 Changed 6 years ago by j03lar50n

Resolution: fixed
Status: assignedclosed

comment:5 in reply to:  4 Changed 6 years ago by j03lar50n

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

comment:6 Changed 6 years ago by warmerdam

Resolution: fixed
Status: closedreopened

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

comment:7 Changed 6 years ago by warmerdam

Resolution: fixed
Status: reopenedclosed

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

comment:8 Changed 6 years ago by warmerdam

Resolution: fixed
Status: closedreopened

comment:9 Changed 6 years ago by warmerdam

Cc: dustymugs jorgearevalo added

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. """

comment:10 Changed 6 years ago by 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?

comment:11 Changed 6 years ago by 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

comment:12 Changed 6 years ago by Ari Jolma

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

comment:13 Changed 6 years ago by 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.

comment:14 Changed 6 years ago by 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.

comment:15 Changed 5 years ago by 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.

comment:16 Changed 5 years ago by 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

comment:17 Changed 5 years ago by warmerdam

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

comment:18 Changed 5 years ago by rburhum

Resolution: worksforme
Status: reopenedclosed

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.

comment:19 Changed 2 years ago by Ari Jolma

This page is the first that comes up in a Google search for the error

libtool: link: unable to infer tagged configuration

You get this error if you ran configure before installing g++. Please run make clean and then ./configure and make again. Sorry for the inconvenience.

Changed 2 years ago by Ari Jolma

Attachment: diff added

Patch for configure.in

comment:20 Changed 2 years ago by Ari Jolma

I suggest modifying configure to die if no working c++ compiler is found.

comment:21 Changed 2 years ago by Even Rouault

trunk r31857 "configure: check that CXX is really a working compiler (patch by ajolma, #4436)"

Note: See TracTickets for help on using tickets.