Re: libtool doesn't pass LDFLAGS to linker - Solaris 64 bit

2006-01-17 Thread Jaimon Jose


Ralf Wildenhues wrote the following on 01/15/2006 09:51 PM:

Hi Jaimon,

* Jaimon Jose wrote on Sat, Jan 14, 2006 at 07:25:34PM CET:
  
Compiler flag -xarch=v9 or -xarch=generic64 ( sunstudio 8 
onwards ) is used to build 64 bit object files.  The same flag needs to 
be provided to the linker driver, so that the compiler driver picks up 
the correct runtime libraries before calling the linker.  However, 
libtool is not passing the LDFLAGS before invoking the linker driver. 
I'm building it on Solaris 8 with both SunForte U2 and SunStudio 11.  
Libtool  used is 1.5.18.



This should be fixed in Libtool-1.5.22.
  
Thanks for the heads up.  Libtool-1.5.22 passes the linker flags 
correctly. 

I see a new problem with this.  Shared library extension is not passed 
correctly, 'cause of which extension is missing from shared libraries.  
( For eg.  libname.1.1.1 )
The problems seems to be with un-initiallized shrext_cmds variable.  
This is initialized in link mode only if a shrext argument is found in 
the command line.  Shouldn't this be initialized by default ( as soon as 
you enter link mode ) with variable shrext ?  ( I tried this and that 
seems to be solving the problem )


Thanks
--jaimon


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


Re: libtool doesn't pass LDFLAGS to linker - Solaris 64 bit

2006-01-17 Thread Ralf Wildenhues
Hi Jaimon,

* Jaimon Jose wrote on Tue, Jan 17, 2006 at 09:37:58AM CET:
> Ralf Wildenhues wrote the following on 01/15/2006 09:51 PM:
> >* Jaimon Jose wrote on Sat, Jan 14, 2006 at 07:25:34PM CET:
> >  
> Thanks for the heads up.  Libtool-1.5.22 passes the linker flags 
> correctly. 

Good.

> I see a new problem with this.  Shared library extension is not passed 
> correctly, 'cause of which extension is missing from shared libraries.  
> ( For eg.  libname.1.1.1 )
> The problems seems to be with un-initiallized shrext_cmds variable.  
> This is initialized in link mode only if a shrext argument is found in 
> the command line.  Shouldn't this be initialized by default ( as soon as 
> you enter link mode ) with variable shrext ?  ( I tried this and that 
> seems to be solving the problem )

This is a likely indication that you have updated ltmain.sh but are not
using the new macros from libtool.m4/ltdl.m4.  aclocal likely did not
pick them up: tell it where to find them (search for `-I' or `dirlist'
in the Automake documentation).

Cheers,
Ralf


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


Re: libtool doesn't pass LDFLAGS to linker - Solaris 64 bit

2006-01-17 Thread Peter O'Gorman

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Jaimon Jose wrote:
|
| Ralf Wildenhues wrote the following on 01/15/2006 09:51 PM:
|
|> Hi Jaimon,
|>
|> * Jaimon Jose wrote on Sat, Jan 14, 2006 at 07:25:34PM CET:
|>
|>
|>> Compiler flag -xarch=v9 or -xarch=generic64 ( sunstudio 8 onwards )
|>> is used to build 64 bit object files.  The same flag needs to be
|>> provided to the linker driver, so that the compiler driver picks up
|>> the correct runtime libraries before calling the linker.  However,
|>> libtool is not passing the LDFLAGS before invoking the linker driver.
|>> I'm building it on Solaris 8 with both SunForte U2 and SunStudio 11.
|>> Libtool  used is 1.5.18.
|>>
|>
|>
|> This should be fixed in Libtool-1.5.22.
|>
|
| Thanks for the heads up.  Libtool-1.5.22 passes the linker flags correctly.
| I see a new problem with this.  Shared library extension is not passed
| correctly, 'cause of which extension is missing from shared libraries.
| ( For eg.  libname.1.1.1 )
| The problems seems to be with un-initiallized shrext_cmds variable.
| This is initialized in link mode only if a shrext argument is found in
| the command line.  Shouldn't this be initialized by default ( as soon as
| you enter link mode ) with variable shrext ?  ( I tried this and that
| seems to be solving the problem )

If shrext_cmds is unset it is because the configure script has a libtool.m4
that does not match the version of ltmain.sh. If you installed libtool in
/usr/local, but have aclocal in /usr/bin, then you are likely getting the
old libtool.m4 from /usr/share/aclocal/libtool.m4 rather than the latest one
at /usr/local/share/...

Add the right -I flags to your aclocal invocation, or install automake in
the same prefix as libtool.

Peter
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.0 (Darwin)

iQCVAwUBQ8zqMriDAg3OZTLPAQLuWQQAtzsckJYdNQgbfMQoD50H8U+uw29hvI91
M4Tw/+elizIbhMlbeFtBBaiNQZ2Lj6w1Oq3kahM2HHyOIQzhCiiW9vbDuJWCG073
FH+iM+wkzsf3JJRxpDkG9GUoxSHXA8naV5NW3zKjOe2sn/9K2prgJWWUyjBN4ybb
4XgPr3rr+r8=
=siiW
-END PGP SIGNATURE-


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


Re: 1.5.22 fails to configure on AIX 5.1

2006-01-17 Thread Howard Chu

Howard Chu wrote:
Well damn, after the reboot the problem seems to have disappeared, 
configure runs cleanly start to finish. (A colleague of mine requested 
the reboot, to clear up some "linker path problem" which suggests to me 
that we had some corrupted shared library or somesuch. I don't know why 
slibclean wouldn't have done the trick, but it didn't occur to me to ask 
for more details at the time.)


For future reference, the machine was a vanilla AIX 5.1 install with no 
patches, the reboot was to bring up AIX maintenance level 9. And voila, 
no more shell bug.


--
  -- Howard Chu
  Chief Architect, Symas Corp.  http://www.symas.com
  Director, Highland Sunhttp://highlandsun.com/hyc
  OpenLDAP Core Teamhttp://www.openldap.org/project/


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


Re: The .so is missing from my Linux shared libraries

2006-01-17 Thread Thomas Gagné

Your advice worked.  Thank you very much.

Mike Frysinger wrote:

On Monday 16 January 2006 14:52, Thomas Gagné wrote:
  

Oddly, the libraries work on my Suse Linux 9.1 but not my Redhat boxes.
ldconfig doesn't seem to recognize the .so-less libraries as libraries
at all.  Inside my build directory the file libtool reports
shrext='.so', but it doesn't seem to build them that way.



sounds like there's a version mismatch between your autotool files 
(configure / ltmain.sh)


make sure you re-run aclocal, libtoolize -c -f, autoconf, and all that jazz
-mike


  


--
Visit , or
  for more great reading.



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


Re: libtool doesn't pass LDFLAGS to linker - Solaris 64 bit

2006-01-17 Thread Jaimon Jose


Peter O'Gorman wrote the following on 01/17/2006 06:29 PM:

Jaimon Jose wrote:
| Thanks for the heads up.  Libtool-1.5.22 passes the linker flags 
correctly.

| I see a new problem with this.  Shared library extension is not passed
| correctly, 'cause of which extension is missing from shared libraries.
| ( For eg.  libname.1.1.1 )
| The problems seems to be with un-initiallized shrext_cmds variable.
| This is initialized in link mode only if a shrext argument is found in
| the command line.  Shouldn't this be initialized by default ( as 
soon as

| you enter link mode ) with variable shrext ?  ( I tried this and that
| seems to be solving the problem )

If shrext_cmds is unset it is because the configure script has a 
libtool.m4

that does not match the version of ltmain.sh. If you installed libtool in
/usr/local, but have aclocal in /usr/bin, then you are likely getting the
old libtool.m4 from /usr/share/aclocal/libtool.m4 rather than the 
latest one

at /usr/local/share/...

Add the right -I flags to your aclocal invocation, or install automake in
the same prefix as libtool.
Yes.  You are right.  New libtool was installed in /usr/local and it was 
not picking up the latest aclocal.m4.  Everything goes through fine with 
-I flag.


Thanks
--jaimon


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