libtool woes

Ryan Schmidt ryandesign at macports.org
Sun Feb 3 12:03:26 PST 2008


On Feb 3, 2008, at 13:50, Peter O'Gorman wrote:

> Ryan Schmidt wrote:
>
>>>> what baffles me about this is that the libtool that's being  
>>>> invoked is
>>>> part of the port's code:
>>>>
>>>> /bin/sh ./libtool --tag=CC   --mode=link gcc  -O2 -no-cpp-precomp
>>>> -version-info 0:0:0 -L/opt/local/lib -lglib-2.0 -lintl -liconv
>>>> -no-undefined -L/opt/local/lib -o libIDL-2.la -rpath /opt/local/lib
>>>> parser.lo lexer.lo ns.lo util.lo
>
> This is failing with 'unable to infer tagged configuration'? Seems
> pretty strange as it has a --tag argument, it should not even be  
> trying
> to infer the tag.

I don't know what's going on; I'm just quoting here.

>>>> if I run port configure (with -d), what's happening here?
>>>>
>>>> configure: creating libtool
>>>> appending configuration tag "CXX" to libtool
>>>> checking for ld used by /usr/bin/g++-4.0... /usr/bin/ld
>>>> checking if the linker (/usr/bin/ld) is GNU ld... no
>>>> checking whether the /usr/bin/g++-4.0 linker (/usr/bin/ld) supports
>>>> shared libraries... yes
>>>
>>> libtool is usually built in the build directory by running  
>>> configure, it
>>> is included in the package. I had a quick look at the bugs  
>>> mentioned:
>>>
>>> http://trac.macosforge.org/projects/macports/ticket/13653
>>> http://trac.macosforge.org/projects/macports/ticket/13648
>>>
>>> In both cases an installed GNU libtool
>>
>> which installed GNU libtool? you mean the libtool that the project  
>> built
>> for itself?
>
> one is calling /opt/local/bin/glibtool, the other is using apr's  
> libtool
> (/opt/local/share/apr-1/build/libtool).

I don't know what "one" or "the other" is. But now you're saying  
there are three libtools involved -- the one in /opt/local/bin/ 
glibtool, the one in /opt/local/share/apr-1/build/libtool, and the  
one in ${worksrcdir}/libtool?

I have the libtool port installed and do not see the problem. Maybe I  
would see the problem if I removed the libtool port?

Maybe the problem is that the users experiencing this problem  
installed either libtool or apr or both before MacPorts 1.6 and are  
now trying to install apache2 with MacPorts 1.6? Could that be? If so  
the solution would be to rebuild libtool or apr?

>>> is being called with a different
>>> compiler (at least a different compiler name) than it was built  
>>> with.
>>
>> what compiler name was it built with, and what compiler name is it  
>> being
>> called with? and why are they different?
>
> I assume it was built with 'gcc' and it is being called with
> '/usr/bin/gcc-4.0'. Not the same name.



More information about the macports-users mailing list