libtool-patches
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: tagdemo link problem libtool HEAD / AIX 5.3


From: Ralf Wildenhues
Subject: Re: tagdemo link problem libtool HEAD / AIX 5.3
Date: Mon, 14 Jan 2008 22:34:51 +0100
User-agent: Mutt/1.5.13 (2006-08-11)

* Rainer Tammer wrote on Sun, Jan 13, 2008 at 06:10:01PM CET:
> Ralf Wildenhues wrote:
>>> The above TESTS="..."  is not working... I have modified it to:
>>
>> Oh, sorry about that glitch.
>>   
> No problem... :-)
>>> ... and the "BFD: ..." errors are gone.
>>
>> Cool.  But you're saying the link errors remain?
>>   
> No linking was OK.

Ah, great.  So it seems we finally got all AIX issues nailed.  The GCC
fixincludes screwup for unistd.h seems likely to break other headers as
well, and more importantly, I think it should be breaking lots of
packages.  Surely we could
  #ifndef R_OK
  # define R_OK 4
  #endif

just like we do for MSVC, but we certainly cannot replace all of
unistd.h (and no, I'm not going to drag in gnulib for a GCC bug in
a way old version).  Let that be fixed upstream.

>>> The IBM AIX Linux Toolbox contains ar / nm from GNU binutils 2.14 20030612.
>>> Currently I am trying to build GNU binutils 2.18.50 on AIX 5.3.
>>>
>>> Is it possible / advisable to always use the AIX ar/nm version ??

Seems like it.

>> It should be if you configure like this:
>>   ./configure AR=ar NM="nm -B" ...
>>
>> or, if the GNU stuff is first in $PATH, use their absolute names.
>>   
> Yes, but normally the user only says ./configure ... without any
> additional  options.

> And if the old Toolbox ar/nm is installed things are going wrong.

Well, we strive to make that work for as many setups as possible, but
for this one I think we should just put a note in doc/notes.texi.
I've applied the patch below and backported it to branch-1-5's README.
(I don't like unconditionally rejecting free-software binutils over
proprietary native, because it may be fixed in due time, or a newer
version is already, and actually testing for the C++ link failure just
for deciding which nm to use would be too complex.)

> Is it possible to check if we are on AIX and then switch automatically  
> to the AIX ar/nm ??

Possibly.  But it would be rather complicated, and this is IMHO a rather
rare use case for which I don't think the added complexity is worth it.

Cheers,
Ralf

2008-01-14  Ralf Wildenhues  <address@hidden>

        * doc/notes.texi: Mention AIX binutils deficiency for C++ code.
        Report by Rainer Tammer.
        Suggest using bash for configure.

Index: doc/notes.texi
===================================================================
RCS file: /cvsroot/libtool/libtool/doc/notes.texi,v
retrieving revision 1.3
diff -u -r1.3 notes.texi
--- doc/notes.texi      25 Feb 2007 15:33:24 -0000      1.3
+++ doc/notes.texi      14 Jan 2008 21:28:36 -0000
@@ -9,6 +9,19 @@
 similar to address@hidden  In case of doubt use @code{LDFLAGS=-Wl,-brtl} for 
the latter style.
 
 @item
+On AIX, native tools are to be preferred over binutils; especially for C++ 
code,
+if using the AIX Toolbox GCC 4.0 and binutils, configure with
address@hidden/usr/bin/ar LD=/usr/bin/ld NM='/usr/bin/nm -B'}.
+
address@hidden
+On AIX, the @command{/bin/sh} is very slow due to its inefficient handling
+of here-documents.  A modern shell is preferable:
address@hidden
+CONFIG_SHELL=/bin/bash; export $CONFIG_SHELL
+$CONFIG_SHELL ./configure [...]
address@hidden example
+
address@hidden
 For C++ code with templates, it may be necessary to specify the way the 
compiler
 will generate the instantiations.  For Portland pgCC version5, use
 @code{CXX='pgCC --one_instantiation_per_object'} and avoid parallel 
@command{make}.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]