RE: libtool problem when cross compiling net-snmp

[Göran Hillebrink]

Thank you for your response.

Attached are the logs you asked for.
libc is located in /home/goranh/src/etrax/target/crisv32-axis-linux-gnu/lib.

/Goran


-Original Message-
From:   Ralf Wildenhues [mailto:[EMAIL PROTECTED]
Sent:   Wed 1/9/2008 8:51 PM
To: Göran Hillebrink
Cc: libtool@gnu.org
Subject:Re: libtool problem when cross compiling net-snmp

Hello Göran,

* Göran Hillebrink wrote on Wed, Jan 09, 2008 at 04:27:27PM CET:
> 
> I'm trying to cross compile net-snmp but have run into a libtool
> problem. I'm using libtool 1.5.24 together with net-snmp 5.4.1.
> 
> I've tracked down the problem to archive_cmds in libtool. The $deplibs
> parameter indicates -L/usr/lib instead of
> -L/home/goranh/src/etrax/target/crisv32-axis-linux-gnu/usr/lib.

Not sure whether I can help you, but could you please run this command
manually with --debug added right after `../libtool':

> (cd /usr/local/src/etrax/apps/ucd-snmp/net-snmp-5.4/src/agent; /bin/sh 
> ../libtool  --mode=relink gcc-cris -isystem 
> /home/goranh/src/etrax/target/crisv32-axis-linux-gnu/include -isystem 
> /home/goranh/src/etrax/target/crisv32-axis-linux-gnu/usr/include -mlinux 
> -march=v32 -Wall -Os -g 
> -I/home/goranh/src/etrax/target/crisv32-axis-linux-gnu/usr/include -Ulinux 
> -Dlinux=linux -rpath /usr/lib -version-info 16:0:1 -o libnetsnmpagent.la 
> snmp_agent.lo snmp_vars.lo agent_read_config.lo agent_registry.lo 
> agent_index.lo agent_trap.lo kernel.lo agent_handler.lo 
> mibgroup/utilities/execute.lo mibgroup/mibII/vacm_conf.lo 
> mibgroup/snmpv3/usmConf.lo ../snmplib/libnetsnmp.la 
> -L/home/goranh/src/etrax/target/crisv32-axis-linux-gnu/lib 
> -L/home/goranh/src/etraxtarget/crisv32-axis-linux-gnu/lib 
> -L/home/goranh/src/etrax/target/crisv32-axis-linux-gnu/usr/lib 
> -L/home/goranh/src/etrax/target/crisv32-axis-linux-gnu/usr/lib 
> -inst-prefix-dir /home/goranh/src/etrax/target/crisv32-axis-linux-gnu)

and this added at the end
  > log-snmp-cross-relink 2>&1 && gzip log-snmp-cross-relink

and post log-snmp-cross-relink.gz as well as the output of
  ../libtool --config

?  Further, where is the cris libc located on your system?

Thanks,
Ralf







log-snmp-cross-relink.gz
Description: log-snmp-cross-relink.gz


log-snmp-cross-relink-config.gz
Description: log-snmp-cross-relink-config.gz
___
http://lists.gnu.org/mailman/listinfo/libtool

Re: make -s

[Richard Hacker]

On Thursday 10 January 2008 08:29, Ralf Wildenhues wrote:
> For whatever output is left done by libtool I expect that whoever want's
> it silenced hard enough will have enough motivation to send a patch to
> <[EMAIL PROTECTED]>.
That shouldn't bee too difficult.

As a hint, make adds 's' to the environment variable MAKEFLAGS:
MAKEFLAGS=s

MFLAGS=-s also exists, but its use seems to be superceded by MAKEFLAGS

When I change ltmain.sh using the following patch, it seems to work. I am 
using
# libtool --version
ltmain.sh (GNU libtool) 1.5.22 (1.1220.2.365 2005/12/18 22:14:06)

I hope this patch is portable I am certainly no expert in portability!

 patch start 
--- old/ltmain.sh   2006-11-25 12:34:55.0 +0100
+++ /usr/share/libtool/ltmain.sh2008-01-10 13:28:59.0 +0100
@@ -384,6 +384,15 @@
 done
 func_extract_archives_result="$my_oldobjs"
 }
+
+func_is_make_silent ()
+{
+case $1 in
+*s*) true;;
+*) false;;
+esac
+}
+
 # End of Shell function definitions
 #

@@ -392,6 +401,12 @@

 disable_libs=no

+if func_is_make_silent "$MAKEFLAGS"
+then
+   show=:
+   preserve_args="$preserve_args $arg"
+fi
+
 # Parse our command line options once, thoroughly.
 while test "$#" -gt 0
 do
 patch end 

- Richard


___
http://lists.gnu.org/mailman/listinfo/libtool

-prefer-pic

[Olly Betts]

The output from:

libtool --help --mode=compile

contains:

  -prefer-pic   try to building PIC objects only
  -prefer-non-pic   try to building non-PIC objects only

Firstly, that's poor grammar ("try to build" would be better).

Secondly, this seems to be the full extent of the documentation for
these options - searching the info manual for "-prefer" doesn't find
anything.  The NEWS file notes they were added in libtool 1.3d "to
control the generation of PIC/non-PIC code".

Experimenting, it seems that -prefer-pic results in PIC code in static
libraries, whereas -prefer-non-pic results in non-PIC code in shared
libraries, but it's unclear to me what "try" means.  On x86-64 Linux,
(which doesn't allow non-PIC code in shared libraries), I still get
non-PIC code in the object destined for the shared library, so it
doesn't seem to take platform-specific restrictions into account:

$ /usr/share/misc/config.guess
x86_64-unknown-linux-gnu
$ libtool --mode=compile gcc -prefer-non-pic -c xxx.c -o xxx.o
 gcc -c xxx.c -o .libs/xxx.o
 gcc -c xxx.c -o xxx.o >/dev/null 2>&1

However, looking at the libtool script, I see:

if test "$pic_mode" = no && test "$deplibs_check_method" != pass_all; then
  # non-PIC code in shared libraries is not supported
  pic_mode=default
fi

This is with the Ubuntu gutsy libtool package of 1.5.24, but vanilla
1.5.22 seems to behave the same way:

$ libtool --version
ltmain.sh (GNU libtool) 1.5.24 Debian 1.5.24-1ubuntu1 (1.1220.2.456 2007/06/24 
02:25:32)

I think it would be useful to cover these options in a bit more detail
in the manual.

Cheers,
Olly



___
http://lists.gnu.org/mailman/listinfo/libtool

Re: build check in AIX 5.2 / 5.3 / 6.1 - gcc/g++

[Ralf Wildenhues]

Hello Rainer,

* Rainer Tammer wrote on Thu, Jan 10, 2008 at 09:39:01AM CET:
>>> If you like me to perforce some tests with gcc then I can try that too..
>>
>> Yes, that would be great.  The systems I test on currently don't have
>> g++ or gfortran (or gcj) installed, so if you could test
>>   ./configure CC=gcc CXX=g++ FC=gfortran F77=gfortran
>>   
> branch-1.5
> ===
>
> The make check does show some errors...

Indeed:

> /bin/sh ./libtool --tag=CXX   --mode=link g++  -g -O2  -Wl,-brtl -o tagdemo 
> main.o libbaz.la
> g++ -g -O2 -Wl,-brtl -o tagdemo main.o  ./.libs/libbaz.a
> ld: 0711-317 ERROR: Undefined symbol: .std::basic_ostream std::char_traits >& std::operator<<  
> >(std::basic_ostream >&, char const*)
> ld: 0711-317 ERROR: Undefined symbol: .std::basic_ostream std::char_traits >& std::endl 
> >(std::basic_ostream >&)
> ld: 0711-317 ERROR: Undefined symbol: vtable for 
> __cxxabiv1::__si_class_type_info
> ld: 0711-317 ERROR: Undefined symbol: vtable for __cxxabiv1::__class_type_info
> ld: 0711-317 ERROR: Undefined symbol: .std::basic_ostream std::char_traits >::operator<<(double)
> ld: 0711-317 ERROR: Undefined symbol: .std::basic_ostream std::char_traits >::operator<<(unsigned long)
> ld: 0711-317 ERROR: Undefined symbol: .std::basic_ostream std::char_traits >::operator<<(long)
> ld: 0711-345 Use the -bloadmap or -bnoquiet option to obtain more information.
> collect2: ld returned 8 exit status
> gmake[3]: *** [tagdemo] Error 1

Can you try these and show output?
  cd tagdemo
  /bin/sh ./libtool --tag=CXX --mode=link g++ -v -g -O2 -Wl,-brtl -o tagdemo 
main.o libbaz.la
  /bin/sh ./libtool --tag=CXX --mode=link g++ -v -g -O2 -Wl,-brtl -o tagdemo 
main.o libbaz.la -lstdc++ -lm

Please also show
  ./libtool --tag=CXX --config | grep -E '^(pre|post)dep'

Somehow it seems '-lstdc++ -lm' does not find its way into CXX postdeps.

Thanks,
Ralf


___
Bug-libtool mailing list
[EMAIL PROTECTED]
http://lists.gnu.org/mailman/listinfo/bug-libtool

Re: multiple libraries with inter-dependencies and relinking with DESTDIR

[Ralf Wildenhues]

Hello Mike,

* Mike Frysinger wrote on Mon, Dec 31, 2007 at 09:52:36PM CET:
> archives seem to indicate this has always been an issue, and while it's been 
> getting better over time, it hasnt really been considered "fully fixed".  
> what i'm looking at here is:
> src/one/libone.la:
>   SOURCES = some files
> src/two/libtwo.la:
>   SOURCES = some files
>   LDFLAGS = ../one/libone.la
> when doing `make install DESTDIR=/some/place`, the relinking is fine for 
> libone.la.  but when relinking libtwo.la, -L$libdir is incorrectly added to 
> the linking step.  an -L flag pointing to the $DESTDIR/$libdir is added 
> before this and that's great ... it means libtwo.la is relinked against the 
> new/current version of libone.la and not some random old version in $libdir.  
> the problem with -L$libdir being added *at all* is cross-compiling.  this 
> path can easily be a host libpath which means it gets searched before the 
> normal cross-compiler library paths.

Indeed, and there has just been another bug report about this.

AFAICS, the
  add_dir="-L$libdir"
  ...
  add_dir="$add_dir -L$inst_prefix_dir$libdir"

idiom happens twice in ltmain.  

My qualm with changing that code is: sometimes we do *need* to add both
of those paths.  Otherwise, users will scream about breaking their
legitimate setups.  Now, how to find out when it is needed and when not?

FWIW, it's not only cross-compiling that suffers.  But it suffers most
obviously (through hard link failures), not less obviously (through
mistakenly linking against the wrong library).

Cheers,
Ralf


___
http://lists.gnu.org/mailman/listinfo/libtool

Re: multiple libraries with inter-dependencies and relinking with DESTDIR

[Mike Frysinger]

On Thursday 10 January 2008, Ralf Wildenhues wrote:
> Hello Mike,
>
> * Mike Frysinger wrote on Mon, Dec 31, 2007 at 09:52:36PM CET:
> > archives seem to indicate this has always been an issue, and while it's
> > been getting better over time, it hasnt really been considered "fully
> > fixed". what i'm looking at here is:
> > src/one/libone.la:
> > SOURCES = some files
> > src/two/libtwo.la:
> > SOURCES = some files
> > LDFLAGS = ../one/libone.la
> > when doing `make install DESTDIR=/some/place`, the relinking is fine for
> > libone.la.  but when relinking libtwo.la, -L$libdir is incorrectly added
> > to the linking step.  an -L flag pointing to the $DESTDIR/$libdir is
> > added before this and that's great ... it means libtwo.la is relinked
> > against the new/current version of libone.la and not some random old
> > version in $libdir. the problem with -L$libdir being added *at all* is
> > cross-compiling.  this path can easily be a host libpath which means it
> > gets searched before the normal cross-compiler library paths.
>
> Indeed, and there has just been another bug report about this.
>
> AFAICS, the
>   add_dir="-L$libdir"
>   ...
>   add_dir="$add_dir -L$inst_prefix_dir$libdir"
>
> idiom happens twice in ltmain.
>
> My qualm with changing that code is: sometimes we do *need* to add both
> of those paths.  Otherwise, users will scream about breaking their
> legitimate setups.  Now, how to find out when it is needed and when not?

can you describe such a legitimate setup ?  off the top of my head, i cant 
think of one.
-mike


signature.asc
Description: This is a digitally signed message part.
___
http://lists.gnu.org/mailman/listinfo/libtool

Re: make -s

[Ralf Wildenhues]

Hello Richard,

* Richard Hacker wrote on Thu, Jan 10, 2008 at 01:39:31PM CET:
> On Thursday 10 January 2008 08:29, Ralf Wildenhues wrote:
> > For whatever output is left done by libtool I expect that whoever want's
> > it silenced hard enough will have enough motivation to send a patch to
> > <[EMAIL PROTECTED]>.
> That shouldn't bee too difficult.

Misunderstanding again, this time my fault, sorry.

What I meant was: even with
  make -s LIBTOOLFLAGS=--silent

there will be some leftover output done by libtool.  If somebody wants
to fix that, be invited to provide a (complete) patch (best including
testsuite amend; the stresstest in Libtool HEAD would probably come in
handy).

If you want all tools silenced which are called by make, then I suggest
to simply use
  make >/dev/null || make

Eric already mentioned the portability issue with your patch.

Hope that helps.

Cheers,
Ralf


___
http://lists.gnu.org/mailman/listinfo/libtool

Re: libtool problem when cross compiling net-snmp

[Ralf Wildenhues]

* Göran Hillebrink wrote on Thu, Jan 10, 2008 at 10:17:31AM CET:
> 
> Attached are the logs you asked for.
> libc is located in /home/goranh/src/etrax/target/crisv32-axis-linux-gnu/lib.

Thanks.  So this is indeed the same issue as Mike Frysinger described in
.

So far I can only suggest a workaround that may work for you.
You could try building with
  make LDFLAGS=-L/home/goranh/src/etrax/target/crisv32-axis-linux-gnu/lib

Hope that helps.

Cheers,
Ralf


___
http://lists.gnu.org/mailman/listinfo/libtool

Re: multiple libraries with inter-dependencies and relinking with DESTDIR

[Ralf Wildenhues]

* Mike Frysinger wrote on Thu, Jan 10, 2008 at 08:29:29PM CET:
> On Thursday 10 January 2008, Ralf Wildenhues wrote:
> > * Mike Frysinger wrote on Mon, Dec 31, 2007 at 09:52:36PM CET:
> > > when doing `make install DESTDIR=/some/place`, the relinking is fine for
> > > libone.la.  but when relinking libtwo.la, -L$libdir is incorrectly added
> > > to the linking step.  an -L flag pointing to the $DESTDIR/$libdir is
> > > added before this and that's great ... it means libtwo.la is relinked
> > > against the new/current version of libone.la and not some random old
> > > version in $libdir. the problem with -L$libdir being added *at all* is
> > > cross-compiling.  this path can easily be a host libpath which means it
> > > gets searched before the normal cross-compiler library paths.

> > My qualm with changing that code is: sometimes we do *need* to add both
> > of those paths.  Otherwise, users will scream about breaking their
> > legitimate setups.  Now, how to find out when it is needed and when not?
> 
> can you describe such a legitimate setup ?  off the top of my head, i cant 
> think of one.

I think this is such a setup (but I haven't tried it out now, please say
so if you want me to try it):

Non-cross-compiling:  I have a package, am not root.  Its libraries
depend on some in /usr/lib.  I do
  make install DESTDIR=/temp/dest

(which needs relinking, thus needs the libraries from /usr/lib),
create a tarball from /temp/dest/usr/local/...
and hand that tarball over to the superuser to install it.

FWIW, this setup avoids that the compiler is ever run by root.

Cheers,
RAlf


___
http://lists.gnu.org/mailman/listinfo/libtool

Re: multiple libraries with inter-dependencies and relinking with DESTDIR

[Mike Frysinger]

On Thursday 10 January 2008, Ralf Wildenhues wrote:
> * Mike Frysinger wrote on Thu, Jan 10, 2008 at 08:29:29PM CET:
> > On Thursday 10 January 2008, Ralf Wildenhues wrote:
> > > * Mike Frysinger wrote on Mon, Dec 31, 2007 at 09:52:36PM CET:
> > > > when doing `make install DESTDIR=/some/place`, the relinking is fine
> > > > for libone.la.  but when relinking libtwo.la, -L$libdir is
> > > > incorrectly added to the linking step.  an -L flag pointing to the
> > > > $DESTDIR/$libdir is added before this and that's great ... it means
> > > > libtwo.la is relinked against the new/current version of libone.la
> > > > and not some random old version in $libdir. the problem with
> > > > -L$libdir being added *at all* is cross-compiling.  this path can
> > > > easily be a host libpath which means it gets searched before the
> > > > normal cross-compiler library paths.
> > >
> > > My qualm with changing that code is: sometimes we do *need* to add both
> > > of those paths.  Otherwise, users will scream about breaking their
> > > legitimate setups.  Now, how to find out when it is needed and when
> > > not?
> >
> > can you describe such a legitimate setup ?  off the top of my head, i
> > cant think of one.
>
> I think this is such a setup (but I haven't tried it out now, please say
> so if you want me to try it):
>
> Non-cross-compiling:  I have a package, am not root.  Its libraries
> depend on some in /usr/lib.  I do
>   make install DESTDIR=/temp/dest
>
> (which needs relinking, thus needs the libraries from /usr/lib),
> create a tarball from /temp/dest/usr/local/...
> and hand that tarball over to the superuser to install it.
>
> FWIW, this setup avoids that the compiler is ever run by root.

sorry, but which libraries are we talking about here ?  it is my understanding 
that libtool would do the '-lfoo' => 'libfoo.la' translation already which 
means the paths for any libtool libraries would be discovered and used, and 
any system libraries (like the libc) are the domain of the toolchain to 
handle.

i'd also think that the libdir in any individual .la script makes a statement 
about that library and that library alone ... it implies nothing about the 
libraries' dependencies, after all isnt that the explicit purpose of 
$dependency_libs ?

why is the explicit -L$libdir required only when inter-dependencies are 
involved ?  in my original example, libone.la has its libdir set to /usr/lib 
yet libtool does not feel the need to add -L$libdir to it.

or am i mistaken as to the source of the -L$libdir (it comes from the 
libraries' own .la and not any other's .la) ?  so in the libone/libtwo 
example, is the -L$libdir from libone.la or libtwo.la ?  i was thinking that 
the libtwo relinking step was taking -L$libdir from libtwo.la and not from 
libone.la ...
-mike


signature.asc
Description: This is a digitally signed message part.
___
http://lists.gnu.org/mailman/listinfo/libtool

Re: make -s

[Mike Frysinger]

On Thursday 10 January 2008, Ralf Wildenhues wrote:
> * Richard Hacker wrote on Thu, Jan 10, 2008 at 01:39:31PM CET:
> > On Thursday 10 January 2008 08:29, Ralf Wildenhues wrote:
> > > For whatever output is left done by libtool I expect that whoever
> > > want's it silenced hard enough will have enough motivation to send a
> > > patch to <[EMAIL PROTECTED]>.
> >
> > That shouldn't bee too difficult.
>
> Misunderstanding again, this time my fault, sorry.
>
> What I meant was: even with
>   make -s LIBTOOLFLAGS=--silent
>
> there will be some leftover output done by libtool.  If somebody wants
> to fix that, be invited to provide a (complete) patch (best including
> testsuite amend; the stresstest in Libtool HEAD would probably come in
> handy).
>
> If you want all tools silenced which are called by make, then I suggest
> to simply use
>   make >/dev/null || make

well, we're after the automatic output going away, not intended output.  but i 
guess you could (reasonably) argue that status messages intended to be seen 
should be sent to stderr, not stdout ...
-mike


signature.asc
Description: This is a digitally signed message part.
___
http://lists.gnu.org/mailman/listinfo/libtool

Re: make -s

[Ralf Wildenhues]

* Mike Frysinger wrote on Thu, Jan 10, 2008 at 08:58:09PM CET:
> On Thursday 10 January 2008, Ralf Wildenhues wrote:
> >
> > What I meant was: even with
> >   make -s LIBTOOLFLAGS=--silent
> >
> > there will be some leftover output done by libtool.  If somebody wants
> > to fix that, be invited to provide a (complete) patch (best including
> > testsuite amend; the stresstest in Libtool HEAD would probably come in
> > handy).
> >
> > If you want all tools silenced which are called by make, then I suggest
> > to simply use
> >   make >/dev/null || make
> 
> well, we're after the automatic output going away, not intended output.

So what's intended output?  That by make, libtool is apparently not.
What about makeinfo, texi2dvi, dvips?  autoconf/aclocal/automake reruns,
configure reruns?  Are you suggesting each of them parse $MAKEFLAGS and
go silent with that, too?

libtool need not be invoked by make alone.  There are multitudinous
other build systems, some of which call libtool at times.  Should
libtool parse their $TOOLFLAGS too?

I merely think that MAKEFLAGS is for make, and other flags should be for
other programs.  And hey, that's just my personal opinion, not cast in
stone or anything; but I would like to be shown why another choice is
better.

If all you want is libtool to go silent globally in your package then
what about just
  AC_SUBST([AM_LIBTOOLFLAGS], [--silent])

in configure.ac.

> but i guess you could (reasonably) argue that status messages intended
> to be seen should be sent to stderr, not stdout ...

Well that's another point.

FWIW, for me, make output is not read by me (unless I debug a build),
but parsed by my editor.  It's good at throwing away what I don't want
to see.

Cheers,
Ralf


___
http://lists.gnu.org/mailman/listinfo/libtool

Re: make -s

[Bob Rossi]

On Thu, Jan 10, 2008 at 09:30:21PM +0100, Ralf Wildenhues wrote:
> * Mike Frysinger wrote on Thu, Jan 10, 2008 at 08:58:09PM CET:
> > On Thursday 10 January 2008, Ralf Wildenhues wrote:
> > >
> > > What I meant was: even with
> > >   make -s LIBTOOLFLAGS=--silent
> > >
> > > there will be some leftover output done by libtool.  If somebody wants
> > > to fix that, be invited to provide a (complete) patch (best including
> > > testsuite amend; the stresstest in Libtool HEAD would probably come in
> > > handy).
> > >
> > > If you want all tools silenced which are called by make, then I suggest
> > > to simply use
> > >   make >/dev/null || make
> > 
> > well, we're after the automatic output going away, not intended output.
> 
> So what's intended output?  That by make, libtool is apparently not.
> What about makeinfo, texi2dvi, dvips?  autoconf/aclocal/automake reruns,
> configure reruns?  Are you suggesting each of them parse $MAKEFLAGS and
> go silent with that, too?
> 
> libtool need not be invoked by make alone.  There are multitudinous
> other build systems, some of which call libtool at times.  Should
> libtool parse their $TOOLFLAGS too?
> 
> I merely think that MAKEFLAGS is for make, and other flags should be for
> other programs.  And hey, that's just my personal opinion, not cast in
> stone or anything; but I would like to be shown why another choice is
> better.

Well, I might be over simplifying things because I don't understand the
big picture. When I type 'make -s' I assume that the compiler commands
that make kicks off will not be sent to stdout/stderr. I do expect that
if the user has some stuff in the Makefile that prints to stdout/stderr
that it would show up there.

Now, before I started using libtool and I only used automake, when I
typed 'make -s' I didn't see any g++ or linker commands. After I added 
libtool, some g++ commands started to appear. I thought it would seem 
natural that the -s to the Makefile would be supported by the libtool 
generated Makefile code.

It was just my "This is how things should intuitively work" reaction.

Thanks,
Bob Rossi


___
http://lists.gnu.org/mailman/listinfo/libtool

Re: make -s

[Peter O'Gorman]

Bob Rossi wrote:

> Well, I might be over simplifying things because I don't understand the
> big picture. When I type 'make -s' I assume that the compiler commands
> that make kicks off will not be sent to stdout/stderr.

You do not see the compiler commands kicked off by make, you see the
compiler commands kicked off by libtool...

This has been discussed before and is, IIRC, the reason that Ralf
introduced LIBTOOLFLAGS in automake.

Peter
-- 
Peter O'Gorman
http://pogma.com


___
http://lists.gnu.org/mailman/listinfo/libtool

Problem with libtool

[Richard Graham]

I am trying to build Open MPI on the Cray's (Compute Node Linux), and ran
into the following problem.  In our configure script we get the wl parameter
set to -Wl,

But when the following part of the build is run:

/bin/sh ../../../libtool --tag=CC   --mode=link cc  -O2
-I/opt/xt-pe/default/include/   -L/opt/xt-mpt/default/lib/snos64/  -o
orteboot orteboot.o ../../../orte/libopen-rte.la  -lnsl -lutil -lpct
-lalpslli -lalpsutil


It results in:
cc -O2 -I/opt/xt-pe/default/include/ -o orteboot orteboot.o
-L/opt/xt-mpt/default/lib/snos64/ ../../../orte/.libs/libopen-rte.a
-L/opt/torque/2.2.0-snap.200711011704/lib
/opt/torque/2.2.0-snap.200711011704/lib/libtorque.so
/ccs/home/rlgraham/orte_cnl/opal/.libs/libopen-pal.a -lnsl -lutil -lpct
-lalpslli -lalpsutil --rpath /opt/torque/2.2.0-snap.200711011704/lib --rpath
/opt/torque/2.2.0-snap.200711011704/lib

Loosing the -Wl, value.  Insteat of -Wl,--rpath I get --rpath, which the pgi
compiler does not recognize.  Are there any hints on how to trouble shoot
this ?

I manually ran:
/bin/sh ../../../libtool --tag=CC   --mode=link cc  -O2
-I/opt/xt-pe/default/include/   -L/opt/xt-mpt/default/lib/snos64/  -o
orteboot orteboot.o ../../../orte/libopen-rte.la  -lnsl -lutil -lpct
-lalpslli -lalpsutil

And here is some (seemingly) relevant output:
+ reload_cmds=$LD$reload_flag -o $output$reload_objs
+ wl=
+ objext=o
+ libext=a
+ shrext_cmds=.so

I am sure this is incomplete information, but am not sure what else to
provide to help diagnose this.

Thanks,
Rich



___
Bug-libtool mailing list
[EMAIL PROTECTED]
http://lists.gnu.org/mailman/listinfo/bug-libtool

Re: make -s

[Mike Frysinger]

On Thursday 10 January 2008, Ralf Wildenhues wrote:
> * Mike Frysinger wrote on Thu, Jan 10, 2008 at 08:58:09PM CET:
> > On Thursday 10 January 2008, Ralf Wildenhues wrote:
> > > What I meant was: even with
> > >   make -s LIBTOOLFLAGS=--silent
> > >
> > > there will be some leftover output done by libtool.  If somebody wants
> > > to fix that, be invited to provide a (complete) patch (best including
> > > testsuite amend; the stresstest in Libtool HEAD would probably come in
> > > handy).
> > >
> > > If you want all tools silenced which are called by make, then I suggest
> > > to simply use
> > >   make >/dev/null || make
> >
> > well, we're after the automatic output going away, not intended output.
>
> So what's intended output?  That by make, libtool is apparently not.
> What about makeinfo, texi2dvi, dvips?  autoconf/aclocal/automake reruns,
> configure reruns?  Are you suggesting each of them parse $MAKEFLAGS and
> go silent with that, too?
>
> libtool need not be invoked by make alone.  There are multitudinous
> other build systems, some of which call libtool at times.  Should
> libtool parse their $TOOLFLAGS too?
>
> I merely think that MAKEFLAGS is for make, and other flags should be for
> other programs.  And hey, that's just my personal opinion, not cast in
> stone or anything; but I would like to be shown why another choice is
> better.

i think we're focusing on the "big" offenders here.  libtool is certainly much 
more prevalent than any other tool cited here when combined with autotools.  
taking that into consideration, the fact that libtool outputs status 
information that amounts pretty closely (almost exactly) to what make itself 
would output, the idea of having it be autosilenced according to -s is a 
common (and logical) expectation for people.  i'm not saying this is grounds 
for "this must be done!", just putting it out there.

there is some precedence here with tools automatically checking MAKEFLAGS for 
the s flag and tweaking their status output, but those tend to be one-off 
things integrated into existing build systems.  the other common behavior in 
the world is letting the Makefile itself decide.  since libtool/automake are 
integrated tightly, another direction to take things would be to have 
automake's default behavior conditionally execute libtool with --silent 
depending on MAKEFLAGS.  while POSIX dictates the portability of MAKEFLAGS, 
autotools is a superset of such things, so i dont know how much that comes 
into play with these decisions.

> If all you want is libtool to go silent globally in your package then
> what about just
>   AC_SUBST([AM_LIBTOOLFLAGS], [--silent])
>
> in configure.ac.

but i want make cake and it too ! :)
-mike


signature.asc
Description: This is a digitally signed message part.
___
http://lists.gnu.org/mailman/listinfo/libtool

Re: make -s

[Bob Rossi]

On Thu, Jan 10, 2008 at 04:15:12PM -0500, Mike Frysinger wrote:
> On Thursday 10 January 2008, Ralf Wildenhues wrote:
> > * Mike Frysinger wrote on Thu, Jan 10, 2008 at 08:58:09PM CET:
> > > On Thursday 10 January 2008, Ralf Wildenhues wrote:
> > > > What I meant was: even with
> > > >   make -s LIBTOOLFLAGS=--silent
> > > >
> > > > there will be some leftover output done by libtool.  If somebody wants
> > > > to fix that, be invited to provide a (complete) patch (best including
> > > > testsuite amend; the stresstest in Libtool HEAD would probably come in
> > > > handy).
> > > >
> > > > If you want all tools silenced which are called by make, then I suggest
> > > > to simply use
> > > >   make >/dev/null || make
> > >
> > > well, we're after the automatic output going away, not intended output.
> >
> > So what's intended output?  That by make, libtool is apparently not.
> > What about makeinfo, texi2dvi, dvips?  autoconf/aclocal/automake reruns,
> > configure reruns?  Are you suggesting each of them parse $MAKEFLAGS and
> > go silent with that, too?
> >
> > libtool need not be invoked by make alone.  There are multitudinous
> > other build systems, some of which call libtool at times.  Should
> > libtool parse their $TOOLFLAGS too?
> >
> > I merely think that MAKEFLAGS is for make, and other flags should be for
> > other programs.  And hey, that's just my personal opinion, not cast in
> > stone or anything; but I would like to be shown why another choice is
> > better.
> 
> i think we're focusing on the "big" offenders here.  libtool is certainly 
> much 
> more prevalent than any other tool cited here when combined with autotools.  
> taking that into consideration, the fact that libtool outputs status 
> information that amounts pretty closely (almost exactly) to what make itself 
> would output, the idea of having it be autosilenced according to -s is a 
> common (and logical) expectation for people.  i'm not saying this is grounds 
> for "this must be done!", just putting it out there.

Exactly, I would think most people would not expect the current
behavior. I would say "Hey, I told make to be quit, but it's not."

Ingorance is bliss.

Bob Rossi


___
http://lists.gnu.org/mailman/listinfo/libtool

Re: support AIX 6.1 in config.rpath

[Ralf Wildenhues]

* Ralf Wildenhues wrote on Tue, Jan 08, 2008 at 09:34:37PM CET:
> * Rainer Tammer wrote on Tue, Jan 08, 2008 at 05:03:30PM CET:
> 
> > The first part of the test run did produce some errors:
> [...]
> > did not find the `myfunc' function
> > error was: Function not implemented (myfunc)
> > did not find the `myvar' variable
> > error was: Function not implemented (myvar)
> [...]
> > FAIL: tests/mdemo-exec.test
> [...]
> > 
> > 3 of 106 tests failed
> 
> Yep, I see these on AIX < 6 as well.  This is a regression of HEAD over
> branch-1-5.  Sigh.

branch-1-5 ltdl finds these symbols with the preopen loader.
HEAD tries with the dlopen one, and then fails.

I think this is due to the order in which lt_dlopen tries the loaders,
and for some reason or other we changed that order (deliberately?) in
HEAD over branch-1-5.

At least with this crude hack I can get the failure to disappear.
What I don't know yet is how to fix this right, nor why this patch would
even be needed: glancing at the documentation, dlopen(NULL) should just
work.

Cheers,
Ralf

Index: libltdl/loaders/dlopen.c
===
RCS file: /cvsroot/libtool/libtool/libltdl/loaders/dlopen.c,v
retrieving revision 1.11
diff -u -r1.11 dlopen.c
--- libltdl/loaders/dlopen.c4 Jul 2007 23:05:05 -   1.11
+++ libltdl/loaders/dlopen.c10 Jan 2008 21:19:18 -
@@ -178,7 +178,13 @@
 #endif
 }
 
-  module = dlopen (filename, module_flags);
+/* dlopen(NULL) does not work well on AIX */
+#ifdef _AIX
+  if (!filename)
+module = NULL;
+  else
+#endif _AIX
+module = dlopen (filename, module_flags);
 
   if (!module)
 {


___
Bug-libtool mailing list
[EMAIL PROTECTED]
http://lists.gnu.org/mailman/listinfo/bug-libtool

Re: Problem with libtool

[Ralf Wildenhues]

Hello Richard,

* Richard Graham wrote on Thu, Jan 10, 2008 at 10:14:46PM CET:
> I am trying to build Open MPI on the Cray's (Compute Node Linux), and ran
> into the following problem.  In our configure script we get the wl parameter
> set to -Wl,
> 
> But when the following part of the build is run:
> 
> /bin/sh ../../../libtool --tag=CC   --mode=link cc  -O2
> -I/opt/xt-pe/default/include/   -L/opt/xt-mpt/default/lib/snos64/  -o
> orteboot orteboot.o ../../../orte/libopen-rte.la  -lnsl -lutil -lpct
> -lalpslli -lalpsutil
> 
> It results in:
> cc -O2 -I/opt/xt-pe/default/include/ -o orteboot orteboot.o
[...]
> -lalpslli -lalpsutil --rpath /opt/torque/2.2.0-snap.200711011704/lib --rpath
> /opt/torque/2.2.0-snap.200711011704/lib
> 
> Loosing the -Wl, value.  Insteat of -Wl,--rpath I get --rpath, which the pgi
> compiler does not recognize.  Are there any hints on how to trouble shoot
> this ?

Libtool is really dumb.  At configure time, it looks at $CC and tries to
find out whether it knows this compiler.  If this is a Linux of some
sort (which I guess it is) and the Portland compiler, then try
  ./configure CC=pgcc

because libtool should recognize pgcc better than cc.  If after that,
  ./libtool --config | grep "^wl"

still shows empty, then you can still try fixing that by editing
libtool manually,
  sed --in-place 's|^wl=.*|wl="-Wl,"|' ./libtool

If this is not the Portland compiler on Linux, then Libtool first needs
to be ported to that combination.

Hope that helps.

Cheers,
Ralf


___
Bug-libtool mailing list
[EMAIL PROTECTED]
http://lists.gnu.org/mailman/listinfo/bug-libtool

Re: make -s

[Bob Friesenhahn]

On Thu, 10 Jan 2008, Bob Rossi wrote:

Well, I might be over simplifying things because I don't understand the
big picture. When I type 'make -s' I assume that the compiler commands
that make kicks off will not be sent to stdout/stderr. I do expect that
if the user has some stuff in the Makefile that prints to stdout/stderr
that it would show up there.


Yes, all 'make -s' is supposed to do is to cause make not to provide 
information about what it is doing.  It should not influence anything 
else.


The only contract that libtool should offer is that if --silent is 
supplied, it should similarly not provide information about what it is 
doing.  It should only provide information about what has gone wrong. 
Unfortunately, sometimes it is very difficult to decipher an error 
message unless you know the precise action which was being performed.


The automake project would be a better place to add extra smarts for a 
more silent build when using libtool.


Bob
==
Bob Friesenhahn
[EMAIL PROTECTED], http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/



___
http://lists.gnu.org/mailman/listinfo/libtool