Re: libtool "module" behavior and darwin

[Nick Hudson]

On Sunday 24 November 2002 6:23 pm, Benjamin Reed wrote:
> One of the problems we're running into getting KDE working on Darwin is 
> libtool's concept of a "module", and how it's mapped onto Darwin's 
> linker behavior.

This was talked about some time ago by Michael Matz and myself.

> To get around issues with prebinding and speed of C++ code loading, 
> especially on linux, KDE creates many of it's executables as shared 
> libraries, linked twice, once as a module and once a binary.  So the 
> "kbackgammon" program is kbackgammon.so and kbackgammon, with main() 
> existing in kbackgammon.so, and kbackgammon being linked against the 
> .so and an empty dummy.cpp file to make linkers happy as far as making 
> a program.

I have create patches to the KDE build system that solves a related problem 
that affects NetBSD a.out platforms. I believe they should fix the Darwin 
problem.

Unfortunately Michael never folded them back into KDE. I guess he is too busy. 
:(

Nick
$NetBSD: patch-aa,v 1.1 2002/05/31 14:02:54 skrll Exp $

--- kbackgammon/Makefile.am.orig	Fri Oct  5 12:52:05 2001
+++ kbackgammon/Makefile.am
@@ -2,21 +2,22 @@
 INCLUDES = -I$(top_srcdir)/libkdegames -I$(top_srcdir)/libkdegames/kgame/ -I$(srcdir)/engines $(all_includes)
 
 bin_PROGRAMS = kbackgammon
-lib_LTLIBRARIES = kbackgammon.la
+lib_LTLIBRARIES = libkbackgammon_main.la kbackgammon.la
 
-CLEANFILES = dummy.cpp
-
-kbackgammon_la_LIBADD = $(LIB_KDEUI) $(LIB_KSYCOCA) -lkdeprint \
+libkbackgammon_main_la_LIBADD = $(LIB_KDEUI) $(LIB_KSYCOCA) -lkdeprint \
 			./engines/libkbgengines.la
-kbackgammon_la_SOURCES = main.cpp kbg.cpp kbgboard.cpp kbgtextview.cpp \
+libkbackgammon_main_la_SOURCES = main.cpp kbg.cpp kbgboard.cpp kbgtextview.cpp \
 			kbgstatus.cpp
 
+kbackgammon_la_LIBADD = libkbackgammon_main.la
+kbackgammon_la_SOURCES = kbackgammon_main.cpp
+
 kbackgammon_la_METASOURCES = AUTO
 kbackgammon_la_LDFLAGS = $(all_libraries) $(KDE_RPATH) -module -avoid-version
 
-kbackgammon_LDADD = kbackgammon.la $(top_builddir)/libkdegames/libkdegames.la \
+kbackgammon_LDADD = libkbackgammon_main.la $(top_builddir)/libkdegames/libkdegames.la \
 		$(LIB_KSYCOCA)
-kbackgammon_SOURCES = dummy.cpp
+kbackgammon_SOURCES = kbackgammon_main.cpp
 kbackgammon_LDFLAGS = $(all_libraries) $(KDE_RPATH)
 
 noinst_HEADERS = version.h kbg.h kbgboard.h kbgtextview.h kbgstatus.h
@@ -34,9 +35,6 @@
 messages: rc.cpp	
 	LIST=`find . -name \*.h -o -name \*.hh -o -name \*.H -o -name \*.hxx -o -name \*.hpp -o -name \*.cpp -o -name \*.cc -o -name \*.cxx -o -name \*.ecpp -o -name \*.C`; \
 	$(XGETTEXT) $$LIST -o $(podir)/kbackgammon.pot
-
-dummy.cpp:
-	echo > dummy.cpp
 
 install-data-local:
 	rm -rf $(kde_appsdir)/Games/kbackgammon.desktop

Re: libtool "module" behavior and darwin

[Guido Draheim]

It's the correct solution AFAICS - from the same sources two
libtool libraries are built - one is a system library that
gets linked to the system binary. And the module libtool
archive is separate from that. Both .la will be able to pick
up the same .lo being compiled along, so it is nothing more
than a single extra link stage in the make process. IOW, on
linux/solaris this would be
  LINK *.lo -o kbackgammon.so
  LINK *.lo -o libkbackgammon.so
on systems like darwin it would boil down into
  LINK *.lo -o kbackgammon.so
  LINK *.lo -o libkbackgammon.dylib

Getting back to the question that followed from the original
link problem: I am not sure whether the user-binary called
"kbackgammon" does actually need a shared library to be
built from. In the setup above, there would still need to
be installed _two_ libraries into the target system, plus
the dummy binary. Binding the '-module' kbackgammon.la as
'-static' would still push two copies of the same .lo's into
the system.

It seems the original author did want to avoid having two
copies of the program's library objects around, and this is
in fact possible in most elf systems. The rpath will guide
the system loader to find its -module so-library, whereever
that one will end up. It is in fact a dependency on some
system characteristics that are portable among modern
systems being mostly elf based - but breaks when trying to
port kde somewhere else. (btw, does that link-to-module
work with cygwin?)

That limits the portability of kde as whole, perhaps, and
so the presented patch should really be merged back into
kde, taking the burden to make two libraries even on
elf systems.

Still, I am asking myself if it might be in fact a good
idea to guide all systems to link '-module' .la as static,
that is not to give a '-lmodulelib' to the linker but a
'modulelib.a' - on all systems. Atleast, I'd propose to
have a check - and utter a warning message when s.o. is
trying to link a '-module' archive into a system binary.
We could then see if someone comes around and barks at us
what that warning message has to say. That might allow us
to see where too that .so possiblity has been (ab)used.

cheers, guido

Nick Hudson wrote:

On Sunday 24 November 2002 6:23 pm, Benjamin Reed wrote:


One of the problems we're running into getting KDE working on Darwin is 
libtool's concept of a "module", and how it's mapped onto Darwin's 
linker behavior.


This was talked about some time ago by Michael Matz and myself.



To get around issues with prebinding and speed of C++ code loading, 
especially on linux, KDE creates many of it's executables as shared 
libraries, linked twice, once as a module and once a binary.  So the 
"kbackgammon" program is kbackgammon.so and kbackgammon, with main() 
existing in kbackgammon.so, and kbackgammon being linked against the 
.so and an empty dummy.cpp file to make linkers happy as far as making 
a program.


I have create patches to the KDE build system that solves a related problem 
that affects NetBSD a.out platforms. I believe they should fix the Darwin 
problem.

Unfortunately Michael never folded them back into KDE. I guess he is too busy. 
:(

Nick




$NetBSD: patch-aa,v 1.1 2002/05/31 14:02:54 skrll Exp $

--- kbackgammon/Makefile.am.orig	Fri Oct  5 12:52:05 2001
+++ kbackgammon/Makefile.am
@@ -2,21 +2,22 @@
 INCLUDES = -I$(top_srcdir)/libkdegames -I$(top_srcdir)/libkdegames/kgame/ -I$(srcdir)/engines $(all_includes)
 
 bin_PROGRAMS = kbackgammon
-lib_LTLIBRARIES = kbackgammon.la
+lib_LTLIBRARIES = libkbackgammon_main.la kbackgammon.la
 
-CLEANFILES = dummy.cpp
-
-kbackgammon_la_LIBADD = $(LIB_KDEUI) $(LIB_KSYCOCA) -lkdeprint \
+libkbackgammon_main_la_LIBADD = $(LIB_KDEUI) $(LIB_KSYCOCA) -lkdeprint \
 			./engines/libkbgengines.la
-kbackgammon_la_SOURCES = main.cpp kbg.cpp kbgboard.cpp kbgtextview.cpp \
+libkbackgammon_main_la_SOURCES = main.cpp kbg.cpp kbgboard.cpp kbgtextview.cpp \
 			kbgstatus.cpp
 
+kbackgammon_la_LIBADD = libkbackgammon_main.la
+kbackgammon_la_SOURCES = kbackgammon_main.cpp
+
 kbackgammon_la_METASOURCES = AUTO
 kbackgammon_la_LDFLAGS = $(all_libraries) $(KDE_RPATH) -module -avoid-version
 
-kbackgammon_LDADD = kbackgammon.la $(top_builddir)/libkdegames/libkdegames.la \
+kbackgammon_LDADD = libkbackgammon_main.la $(top_builddir)/libkdegames/libkdegames.la \
 		$(LIB_KSYCOCA)
-kbackgammon_SOURCES = dummy.cpp
+kbackgammon_SOURCES = kbackgammon_main.cpp
 kbackgammon_LDFLAGS = $(all_libraries) $(KDE_RPATH)
 
 noinst_HEADERS = version.h kbg.h kbgboard.h kbgtextview.h kbgstatus.h
@@ -34,9 +35,6 @@
 messages: rc.cpp	
 	LIST=`find . -name \*.h -o -name \*.hh -o -name \*.H -o -name \*.hxx -o -name \*.hpp -o -name \*.cpp -o -name \*.cc -o -name \*.cxx -o -name \*.ecpp -o -name \*.C`; \
 	$(XGETTEXT) $$LIST -o $(podir)/kbackgammon.pot
-
-dummy.cpp:
-	echo > dummy.cpp
 
 install-data-local:
 	rm -rf $(kde_appsdir)/Games/kbackgammon.desktop



_

Re: libtool "module" behavior and darwin

[Nick Hudson]

On Monday 25 November 2002 10:04 am, Guido Draheim wrote:
> It's the correct solution AFAICS - from the same sources two
> libtool libraries are built - one is a system library that
> gets linked to the system binary. And the module libtool
> archive is separate from that. Both .la will be able to pick
> up the same .lo being compiled along, so it is nothing more
> than a single extra link stage in the make process. IOW, on
> linux/solaris this would be
>LINK *.lo -o kbackgammon.so
>LINK *.lo -o libkbackgammon.so
> on systems like darwin it would boil down into
>LINK *.lo -o kbackgammon.so
>LINK *.lo -o libkbackgammon.dylib
> 
> Getting back to the question that followed from the original
> link problem: I am not sure whether the user-binary called
> "kbackgammon" does actually need a shared library to be
> built from. In the setup above, there would still need to
> be installed _two_ libraries into the target system, plus
> the dummy binary. Binding the '-module' kbackgammon.la as
> '-static' would still push two copies of the same .lo's into
> the system.

Here's what happends... The bulk of the code ends up in the shared library 
libkbackgammon_main.la. The kbackgammon.la module and the kbackgammon are 
both very small (a single function called main that calls kdemain) and they 
both depend on this dynamic library.

> It seems the original author did want to avoid having two
> copies of the program's library objects around, and this is
> in fact possible in most elf systems. The rpath will guide
> the system loader to find its -module so-library, whereever
> that one will end up. It is in fact a dependency on some
> system characteristics that are portable among modern
> systems being mostly elf based - but breaks when trying to
> port kde somewhere else. (btw, does that link-to-module
> work with cygwin?)

I wtill think the original stuff was plain messy.

> That limits the portability of kde as whole, perhaps, and
> so the presented patch should really be merged back into
> kde, taking the burden to make two libraries even on
> elf systems.

I still don't think this is a burden. The new shared object is very small, 
e.g.

$ ls -l /usr/X11R6/lib/*konqueror*.so
-rwxr-xr-x  1 root  wheel4316 Nov 22 16:53 /usr/X11R6/lib/konqueror.so
-rwxr-xr-x  1 root  wheel  810685 Nov 22 16:53 
/usr/X11R6/lib/libkonqueror_main.so

Your position for getting this sort of fix into the KDE sources is much better 
than mine. NetBSD a.out is almost a distant memory - all platforms are now 
ELF in the latest release.

Feel free to take the patches from NetBSD pkgsrc and makes noises with the KDE 
people. http://www.netbsd.org/Documentation/software/packages.html

Nick


___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool

Re: [Fink-devel] Re: libtool "module" behavior and darwin

[David]

-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160


>Feel free to take the patches from NetBSD pkgsrc and makes noises with 
the KDE
people. http://www.netbsd.org/Documentation/software/packages.html


No need to make noise with the KDE people, I am reading this list 
*grins* If you have a patch against HEAD I will merge the patches into 
HEAD after the code Freeze which is still in effect for 3.1

If I cannot merge it myself, I will clarify it with the respective 
coders.

Nick


---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
___
Fink-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/fink-devel

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

iD8DBQE94f/diW/Ta/pxHPQRAwB8AJ0f5g5pvfwVRDgYZvi3zt1Fzv3WTQCfVLtu
NIOcTU0uOrFWegKX2csY+aI=
=r2pW
-END PGP SIGNATURE-



___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool

Re: libtool "module" behavior and darwin

[Guido Draheim]

Ooops, so I did not read the patch too closely - thanks for
the clarification. IOW, there are now two dummy binaries,
one is the system executable, the other is the dlopen-able
module, and both depend on a single system lib*.la - cute!

just to check back with the darwin'ers: a dlopen().so can
link with a .dylib and everything gets resolved nicely?

cheers, -- guido


Nick Hudson wrote:

On Monday 25 November 2002 10:04 am, Guido Draheim wrote:


It's the correct solution AFAICS - from the same sources two
libtool libraries are built - one is a system library that
gets linked to the system binary. And the module libtool
archive is separate from that. Both .la will be able to pick
up the same .lo being compiled along, so it is nothing more
than a single extra link stage in the make process. IOW, on
linux/solaris this would be
  LINK *.lo -o kbackgammon.so
  LINK *.lo -o libkbackgammon.so
on systems like darwin it would boil down into
  LINK *.lo -o kbackgammon.so
  LINK *.lo -o libkbackgammon.dylib

Getting back to the question that followed from the original
link problem: I am not sure whether the user-binary called
"kbackgammon" does actually need a shared library to be
built from. In the setup above, there would still need to
be installed _two_ libraries into the target system, plus
the dummy binary. Binding the '-module' kbackgammon.la as
'-static' would still push two copies of the same .lo's into
the system.



Here's what happends... The bulk of the code ends up in the shared library 
libkbackgammon_main.la. The kbackgammon.la module and the kbackgammon are 
both very small (a single function called main that calls kdemain) and they 
both depend on this dynamic library.


It seems the original author did want to avoid having two
copies of the program's library objects around, and this is
in fact possible in most elf systems. The rpath will guide
the system loader to find its -module so-library, whereever
that one will end up. It is in fact a dependency on some
system characteristics that are portable among modern
systems being mostly elf based - but breaks when trying to
port kde somewhere else. (btw, does that link-to-module
work with cygwin?)



I wtill think the original stuff was plain messy.





___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool

Wrong path at linking

[Szekely Izabella]

Hy!

I use libtool 1.4.2, automake 1.4-p5, autoconf 2.13 on RedHat linux 7.3.

The is the folowing error ...:

PREPROCESSING ...
/bin/sh ../../libtool --mode=link c++  -g -O0 -L/usr/X11R6/lib -rdynamic
-L/usr/local/omniORB/lib/i586_linux_2.0_glibc2.1
-L../../COMMON/lib/LINUX2.4 -L../../COMMON/lib -L../../THC/lib
-L../../COMMON/lib/LINUX2.0 -rpath
/usr/local/omniORB/lib/i586_linux_2.0_glibc2.1:/usr/local/lib:/usr/local
/lib :/usr/local/lib:/home/thc/NQMS-R.2/THC/lib -o DeviceDriver
DeviceDriver.o NqmsCORBAServer.o NqmsCORBAServerDyn.o TestResult.o
TestResultDyn.o SysConfig.o SysConfigDyn.o tserver.o tserverDyn.o
resource.o FileUpload.o StatusServer.o SysConfig_wrap.o
CStatusProvider.o CStatusAttribute.o CNotifySupplier.o CFileUpload.o
CFileCksum.o CDeviceDriver.o CDriver.o CCSCDriver.o CCSCEchoRTD.o
CCSCModemDriver.o dsp.o pamsdll.o pamsdsp.o pamsio.o pamsmod.o
CAISDNDriver.o Capimsg.o CommonAISDNHandler.o CTestResult.o
CTestResultProvider.o CCorbaMain.o main.o -lNqmsCommonTHC -lini -lmcrypt
-lcrypt  -lomniDynamic3 -ltcpwrapGK -lomniORB3 -lomnithread  -lACE
-lmcrypt -lcrypt  -lmp3lame -lshout -lpthread -lcapi201 -lcapi20
-lstdc++ -lm -lc 
c++ -g -O0 -rdynamic -o .libs/DeviceDriver DeviceDriver.o 
c++NqmsCORBAServer.o NqmsCORBAServerDyn.o TestResult.o TestResultDyn.o
SysConfig.o SysConfigDyn.o tserver.o tserverDyn.o resource.o
FileUpload.o StatusServer.o SysConfig_wrap.o CStatusProvider.o
CStatusAttribute.o CNotifySupplier.o CFileUpload.o CFileCksum.o
CDeviceDriver.o CDriver.o CCSCDriver.o CCSCEchoRTD.o CCSCModemDriver.o
dsp.o pamsdll.o pamsdsp.o pamsio.o pamsmod.o CAISDNDriver.o Capimsg.o
CommonAISDNHandler.o CTestResult.o CTestResultProvider.o CCorbaMain.o
main.o  -L/usr/X11R6/lib
-L/usr/local/omniORB/lib/i586_linux_2.0_glibc2.1
-L/home/iszekely/My_rpm/BUILD/NQMS-R.2/COMMON/lib/LINUX2.4
-L/home/iszekely/My_rpm/BUILD/NQMS-R.2/COMMON/lib
-L/home/iszekely/My_rpm/BUILD/NQMS-R.2/THC/lib
-L/home/iszekely/My_rpm/BUILD/NQMS-R.2/COMMON/lib/LINUX2.0
/home/iszekely/My_rpm/BUILD/NQMS-R.2/THC/lib/libNqmsCommonTHC.so -lini
-lmcrypt -lcrypt -lomniDynamic3 -ltcpwrapGK -lomniORB3 -lomnithread
-lACE -lmcrypt -lcrypt /usr/local/lib/.libs/libmp3lame.so
/usr/local/lib/.libs/libshout.so -lpthread -lcapi201
/usr/lib/libcapi20.so -lstdc++ -lm -lc -Wl,--rpath
-Wl,/home/iszekely/My_rpm/BUILD/NQMS-R.2/THC/lib -Wl,--rpath
-Wl,/usr/local/lib -Wl,--rpath
-Wl,/usr/local/omniORB/lib/i586_linux_2.0_glibc2.1:/usr/local/lib:/usr/l
ocal/lib:/usr/local/lib:/home/thc/NQMS-R.2/THC/lib
c++: /usr/local/lib/.libs/libmp3lame.so: No such file or directory
c++: /usr/local/lib/.libs/libshout.so: No such file or directory

Why try it to found the libmp3lame.so under /usr/local/lib/.libs?? It is
under /usr/local/lib/ and -rpath is /usr/local/lib/ ...

Under Debian 2.2 with libtool 1.3.3 with the same Makefiles,
configure.in ... It is OK!!
Any suggestions?

Regards,
Izabella



___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool

Re: Wrong path at linking

[Guido Draheim]

**
do you have a /usr/local/lib/.libs/ directory ?
**

Szekely Izabella wrote:

Hy!

I use libtool 1.4.2, automake 1.4-p5, autoconf 2.13 on RedHat linux 7.3.

The is the folowing error ...:

PREPROCESSING ...
/bin/sh ../../libtool --mode=link c++  -g -O0 -L/usr/X11R6/lib -rdynamic
-L/usr/local/omniORB/lib/i586_linux_2.0_glibc2.1
-L../../COMMON/lib/LINUX2.4 -L../../COMMON/lib -L../../THC/lib
-L../../COMMON/lib/LINUX2.0 -rpath
/usr/local/omniORB/lib/i586_linux_2.0_glibc2.1:/usr/local/lib:/usr/local
/lib :/usr/local/lib:/home/thc/NQMS-R.2/THC/lib -o DeviceDriver
DeviceDriver.o NqmsCORBAServer.o NqmsCORBAServerDyn.o TestResult.o
TestResultDyn.o SysConfig.o SysConfigDyn.o tserver.o tserverDyn.o
resource.o FileUpload.o StatusServer.o SysConfig_wrap.o
CStatusProvider.o CStatusAttribute.o CNotifySupplier.o CFileUpload.o
CFileCksum.o CDeviceDriver.o CDriver.o CCSCDriver.o CCSCEchoRTD.o
CCSCModemDriver.o dsp.o pamsdll.o pamsdsp.o pamsio.o pamsmod.o
CAISDNDriver.o Capimsg.o CommonAISDNHandler.o CTestResult.o
CTestResultProvider.o CCorbaMain.o main.o -lNqmsCommonTHC -lini -lmcrypt
-lcrypt  -lomniDynamic3 -ltcpwrapGK -lomniORB3 -lomnithread  -lACE
-lmcrypt -lcrypt  -lmp3lame -lshout -lpthread -lcapi201 -lcapi20
-lstdc++ -lm -lc 
c++ -g -O0 -rdynamic -o .libs/DeviceDriver DeviceDriver.o 
c++NqmsCORBAServer.o NqmsCORBAServerDyn.o TestResult.o TestResultDyn.o
SysConfig.o SysConfigDyn.o tserver.o tserverDyn.o resource.o
FileUpload.o StatusServer.o SysConfig_wrap.o CStatusProvider.o
CStatusAttribute.o CNotifySupplier.o CFileUpload.o CFileCksum.o
CDeviceDriver.o CDriver.o CCSCDriver.o CCSCEchoRTD.o CCSCModemDriver.o
dsp.o pamsdll.o pamsdsp.o pamsio.o pamsmod.o CAISDNDriver.o Capimsg.o
CommonAISDNHandler.o CTestResult.o CTestResultProvider.o CCorbaMain.o
main.o  -L/usr/X11R6/lib
-L/usr/local/omniORB/lib/i586_linux_2.0_glibc2.1
-L/home/iszekely/My_rpm/BUILD/NQMS-R.2/COMMON/lib/LINUX2.4
-L/home/iszekely/My_rpm/BUILD/NQMS-R.2/COMMON/lib
-L/home/iszekely/My_rpm/BUILD/NQMS-R.2/THC/lib
-L/home/iszekely/My_rpm/BUILD/NQMS-R.2/COMMON/lib/LINUX2.0
/home/iszekely/My_rpm/BUILD/NQMS-R.2/THC/lib/libNqmsCommonTHC.so -lini
-lmcrypt -lcrypt -lomniDynamic3 -ltcpwrapGK -lomniORB3 -lomnithread
-lACE -lmcrypt -lcrypt /usr/local/lib/.libs/libmp3lame.so
/usr/local/lib/.libs/libshout.so -lpthread -lcapi201
/usr/lib/libcapi20.so -lstdc++ -lm -lc -Wl,--rpath
-Wl,/home/iszekely/My_rpm/BUILD/NQMS-R.2/THC/lib -Wl,--rpath
-Wl,/usr/local/lib -Wl,--rpath
-Wl,/usr/local/omniORB/lib/i586_linux_2.0_glibc2.1:/usr/local/lib:/usr/l
ocal/lib:/usr/local/lib:/home/thc/NQMS-R.2/THC/lib
c++: /usr/local/lib/.libs/libmp3lame.so: No such file or directory
c++: /usr/local/lib/.libs/libshout.so: No such file or directory

Why try it to found the libmp3lame.so under /usr/local/lib/.libs?? It is
under /usr/local/lib/ and -rpath is /usr/local/lib/ ...

Under Debian 2.2 with libtool 1.3.3 with the same Makefiles,
configure.in ... It is OK!!
Any suggestions?

Regards,
Izabella



___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool





___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool

Re: Wrong path at linking

[Guido Draheim]

To clarify a bit - the link-line does not have a -L for some .libs.
Any .libs of a -L is searched automatically. If that is not the
case then the next guess comes at some .la to be copied manually
around instead of being installed. May be libmp3lame.la and
libshout.la are somewhere around? - notice, all these are problems
in the installation outside of your current project, and even
subsequent proposals to help you will 99,% not be asking for
actual trouble in libtool et co. It'd be all wild guessing at
what has been done beyond the normal mode of `make && make install`
and before you ever touched your current project. Perhaps some
sharedlib has an `ldd` dependency on .libs/ part, like being
copied manually from a build dir to /usr/local, perhaps something
else has gone the wrong path. It's hard to guess from remote..


Szekely Izabella wrote:

No, I don't have!!!


**
do you have a /usr/local/lib/.libs/ directory ?
**

Szekely Izabella wrote:


Hy!

I use libtool 1.4.2, automake 1.4-p5, autoconf 2.13 on RedHat linux 
7.3.

The is the folowing error ...:

PREPROCESSING ...
/bin/sh ../../libtool --mode=link c++  -g -O0 -L/usr/X11R6/lib 
-rdynamic -L/usr/local/omniORB/lib/i586_linux_2.0_glibc2.1
-L../../COMMON/lib/LINUX2.4 -L../../COMMON/lib -L../../THC/lib 
-L../../COMMON/lib/LINUX2.0 -rpath 
/usr/local/omniORB/lib/i586_linux_2.0_glibc2.1:/usr/local/lib:/usr/loc
al
/lib :/usr/local/lib:/home/thc/NQMS-R.2/THC/lib -o DeviceDriver
DeviceDriver.o NqmsCORBAServer.o NqmsCORBAServerDyn.o TestResult.o
TestResultDyn.o SysConfig.o SysConfigDyn.o tserver.o tserverDyn.o
resource.o FileUpload.o StatusServer.o SysConfig_wrap.o
CStatusProvider.o CStatusAttribute.o CNotifySupplier.o CFileUpload.o
CFileCksum.o CDeviceDriver.o CDriver.o CCSCDriver.o CCSCEchoRTD.o
CCSCModemDriver.o dsp.o pamsdll.o pamsdsp.o pamsio.o pamsmod.o
CAISDNDriver.o Capimsg.o CommonAISDNHandler.o CTestResult.o
CTestResultProvider.o CCorbaMain.o main.o -lNqmsCommonTHC -lini

-lmcrypt


-lcrypt  -lomniDynamic3 -ltcpwrapGK -lomniORB3 -lomnithread  -lACE
-lmcrypt -lcrypt  -lmp3lame -lshout -lpthread -lcapi201 -lcapi20
-lstdc++ -lm -lc
c++ -g -O0 -rdynamic -o .libs/DeviceDriver DeviceDriver.o
c++NqmsCORBAServer.o NqmsCORBAServerDyn.o TestResult.o TestResultDyn.o
SysConfig.o SysConfigDyn.o tserver.o tserverDyn.o resource.o 
FileUpload.o StatusServer.o SysConfig_wrap.o CStatusProvider.o 
CStatusAttribute.o CNotifySupplier.o CFileUpload.o CFileCksum.o 
CDeviceDriver.o CDriver.o CCSCDriver.o CCSCEchoRTD.o CCSCModemDriver.o



dsp.o pamsdll.o pamsdsp.o pamsio.o pamsmod.o CAISDNDriver.o Capimsg.o 
CommonAISDNHandler.o CTestResult.o CTestResultProvider.o CCorbaMain.o 
main.o  -L/usr/X11R6/lib 
-L/usr/local/omniORB/lib/i586_linux_2.0_glibc2.1
-L/home/iszekely/My_rpm/BUILD/NQMS-R.2/COMMON/lib/LINUX2.4
-L/home/iszekely/My_rpm/BUILD/NQMS-R.2/COMMON/lib
-L/home/iszekely/My_rpm/BUILD/NQMS-R.2/THC/lib
-L/home/iszekely/My_rpm/BUILD/NQMS-R.2/COMMON/lib/LINUX2.0
/home/iszekely/My_rpm/BUILD/NQMS-R.2/THC/lib/libNqmsCommonTHC.so -lini



-lmcrypt -lcrypt -lomniDynamic3 -ltcpwrapGK -lomniORB3 -lomnithread 
-lACE -lmcrypt -lcrypt /usr/local/lib/.libs/libmp3lame.so
/usr/local/lib/.libs/libshout.so -lpthread -lcapi201 
/usr/lib/libcapi20.so -lstdc++ -lm -lc -Wl,--rpath 
-Wl,/home/iszekely/My_rpm/BUILD/NQMS-R.2/THC/lib -Wl,--rpath 
-Wl,/usr/local/lib -Wl,--rpath 
-Wl,/usr/local/omniORB/lib/i586_linux_2.0_glibc2.1:/usr/local/lib:/usr
/l
ocal/lib:/usr/local/lib:/home/thc/NQMS-R.2/THC/lib
c++: /usr/local/lib/.libs/libmp3lame.so: No such file or directory
c++: /usr/local/lib/.libs/libshout.so: No such file or directory

Why try it to found the libmp3lame.so under /usr/local/lib/.libs?? It 
is under /usr/local/lib/ and -rpath is /usr/local/lib/ ...

Under Debian 2.2 with libtool 1.3.3 with the same Makefiles, 
configure.in ... It is OK!! Any suggestions?

Regards,
Izabella



___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool






___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool






___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool

RE: Wrong path at linking

[Szekely Izabella]

No, I don't have!!!

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of
Guido Draheim
Sent: Monday, November 25, 2002 12:20 PM
To: Szekely Izabella
Cc: [EMAIL PROTECTED]
Subject: Re: Wrong path at linking


**
do you have a /usr/local/lib/.libs/ directory ?
**

Szekely Izabella wrote:
> Hy!
> 
> I use libtool 1.4.2, automake 1.4-p5, autoconf 2.13 on RedHat linux 
> 7.3.
> 
> The is the folowing error ...:
> 
> PREPROCESSING ...
> /bin/sh ../../libtool --mode=link c++  -g -O0 -L/usr/X11R6/lib 
> -rdynamic -L/usr/local/omniORB/lib/i586_linux_2.0_glibc2.1
> -L../../COMMON/lib/LINUX2.4 -L../../COMMON/lib -L../../THC/lib 
> -L../../COMMON/lib/LINUX2.0 -rpath 
> /usr/local/omniORB/lib/i586_linux_2.0_glibc2.1:/usr/local/lib:/usr/loc
> al
> /lib :/usr/local/lib:/home/thc/NQMS-R.2/THC/lib -o DeviceDriver
> DeviceDriver.o NqmsCORBAServer.o NqmsCORBAServerDyn.o TestResult.o
> TestResultDyn.o SysConfig.o SysConfigDyn.o tserver.o tserverDyn.o
> resource.o FileUpload.o StatusServer.o SysConfig_wrap.o
> CStatusProvider.o CStatusAttribute.o CNotifySupplier.o CFileUpload.o
> CFileCksum.o CDeviceDriver.o CDriver.o CCSCDriver.o CCSCEchoRTD.o
> CCSCModemDriver.o dsp.o pamsdll.o pamsdsp.o pamsio.o pamsmod.o
> CAISDNDriver.o Capimsg.o CommonAISDNHandler.o CTestResult.o
> CTestResultProvider.o CCorbaMain.o main.o -lNqmsCommonTHC -lini
-lmcrypt
> -lcrypt  -lomniDynamic3 -ltcpwrapGK -lomniORB3 -lomnithread  -lACE
> -lmcrypt -lcrypt  -lmp3lame -lshout -lpthread -lcapi201 -lcapi20
> -lstdc++ -lm -lc
> c++ -g -O0 -rdynamic -o .libs/DeviceDriver DeviceDriver.o
> c++NqmsCORBAServer.o NqmsCORBAServerDyn.o TestResult.o TestResultDyn.o
> SysConfig.o SysConfigDyn.o tserver.o tserverDyn.o resource.o 
> FileUpload.o StatusServer.o SysConfig_wrap.o CStatusProvider.o 
> CStatusAttribute.o CNotifySupplier.o CFileUpload.o CFileCksum.o 
> CDeviceDriver.o CDriver.o CCSCDriver.o CCSCEchoRTD.o CCSCModemDriver.o

> dsp.o pamsdll.o pamsdsp.o pamsio.o pamsmod.o CAISDNDriver.o Capimsg.o 
> CommonAISDNHandler.o CTestResult.o CTestResultProvider.o CCorbaMain.o 
> main.o  -L/usr/X11R6/lib 
> -L/usr/local/omniORB/lib/i586_linux_2.0_glibc2.1
> -L/home/iszekely/My_rpm/BUILD/NQMS-R.2/COMMON/lib/LINUX2.4
> -L/home/iszekely/My_rpm/BUILD/NQMS-R.2/COMMON/lib
> -L/home/iszekely/My_rpm/BUILD/NQMS-R.2/THC/lib
> -L/home/iszekely/My_rpm/BUILD/NQMS-R.2/COMMON/lib/LINUX2.0
> /home/iszekely/My_rpm/BUILD/NQMS-R.2/THC/lib/libNqmsCommonTHC.so -lini

> -lmcrypt -lcrypt -lomniDynamic3 -ltcpwrapGK -lomniORB3 -lomnithread 
> -lACE -lmcrypt -lcrypt /usr/local/lib/.libs/libmp3lame.so
> /usr/local/lib/.libs/libshout.so -lpthread -lcapi201 
> /usr/lib/libcapi20.so -lstdc++ -lm -lc -Wl,--rpath 
> -Wl,/home/iszekely/My_rpm/BUILD/NQMS-R.2/THC/lib -Wl,--rpath 
> -Wl,/usr/local/lib -Wl,--rpath 
> -Wl,/usr/local/omniORB/lib/i586_linux_2.0_glibc2.1:/usr/local/lib:/usr
> /l
> ocal/lib:/usr/local/lib:/home/thc/NQMS-R.2/THC/lib
> c++: /usr/local/lib/.libs/libmp3lame.so: No such file or directory
> c++: /usr/local/lib/.libs/libshout.so: No such file or directory
> 
> Why try it to found the libmp3lame.so under /usr/local/lib/.libs?? It 
> is under /usr/local/lib/ and -rpath is /usr/local/lib/ ...
> 
> Under Debian 2.2 with libtool 1.3.3 with the same Makefiles, 
> configure.in ... It is OK!! Any suggestions?
> 
> Regards,
> Izabella
> 
> 
> 
> ___
> Libtool mailing list
> [EMAIL PROTECTED]
> http://mail.gnu.org/mailman/listinfo/libtool
> 
> 



___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool



___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool

Re: Wrong path at linking

[Earnie Boyd]

Szekely Izabella wrote:

Hy!

I use libtool 1.4.2, automake 1.4-p5, autoconf 2.13 on RedHat linux 7.3.



You should at least try it with newest released versions of these softwares.

Earnie.



___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool

Re: [Fink-devel] Re: libtool "module" behavior and darwin

[Nick Hudson]

On Monday 25 November 2002 10:47 am, David wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: RIPEMD160
> 
> 
> > Feel free to take the patches from NetBSD pkgsrc and makes noises with 
> > the KDE people. http://www.netbsd.org/Documentation/software/packages.html
> >
> No need to make noise with the KDE people, I am reading this list 
> *grins* If you have a patch against HEAD I will merge the patches into 
> HEAD after the code Freeze which is still in effect for 3.1
> 
> If I cannot merge it myself, I will clarify it with the respective 
> coders.

That's great news. I cannot, however, promise to have these available anytime 
soon. I would appreciate help. Anyone?

Nick



___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool

Re: [Fink-devel] Re: libtool "module" behavior and darwin

[Benjamin Reed]

That's great news. I cannot, however, promise to have these available 
anytime
soon. I would appreciate help. Anyone?

I can certainly help out with this.  While waiting for more input on 
this thread, I actually ended up coming up with the same solution last 
night.  I woke up this morning to find my kdelibs build done, and your 
(Nick's) response in my inbox telling me to do the same thing.  

If the netbsd patches aren't up-to-date with head, I will clean them up 
until they are, and help out in getting everything back into KDE HEAD.  
I've got commit access to KDE, although I try not to use it since it 
seems like I screw everything up every time I try to commit to their 
tree.  =)

So I guess the outcome of this is that yes, KDE is doing the wrong 
thing, but on most platforms it doesn't matter.  Maybe libtool should 
instead give a warning when linking against a .la that was compiled 
with -module about not being portable, instead of coming up with some 
elaborate hack?  I'm not sure if that's a "good enough" solution or 
not, but it would at least be something...



___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool

DESTDIR installs

[Philip Willoughby]

I have the following in a Makefile.am:

pkglib_LTLIBRARIES=libapttlog.la
libapttlog_la_SOURCES=aptt/log/log.c
AM_CPPFLAGS=@INCLTDL@ -I$(top_srcdir)/src -I$(top_builddir)/src
libapttlog_la_LIBADD=@LIBLTDL@

lib_LTLIBRARIES=libaptttest.la
libaptttest_la_SOURCES=aptt/test/test.c
libaptttest_la_LIBADD=libapttlog.la @LTLIBINTL@

If I run:

./configure [Configure args]
make
make install

everything installs OK, however, if I run:

./configure [Configure args]
make
make DESTDIR=/var/tmp/aptt-0.0.1-1-root/ install

which I need to work to build an rpm cleanly, I get:

/bin/sh ../mkinstalldirs /var/tmp/aptt-0.0.1-1-root/usr/lib
/bin/sh ../libtool --mode=install /usr/bin/install -c  libapttlog.la
/var/tmp/aptt-0.0.1-1-root/usr/lib/libapttlog.la
/usr/bin/install -c .libs/libapttlog.so.0.0.0
/var/tmp/aptt-0.0.1-1-root/usr/lib/libapttlog.so.0.0.0
(cd /var/tmp/aptt-0.0.1-1-root/usr/lib && rm -f libapttlog.so.0 && ln -s
libapttlog.so.0.0.0 libapttlog.so.0)
(cd /var/tmp/aptt-0.0.1-1-root/usr/lib && rm -f libapttlog.so && ln -s
libapttlog.so.0.0.0 libapttlog.so)
/usr/bin/install -c .libs/libapttlog.lai
/var/tmp/aptt-0.0.1-1-root/usr/lib/libapttlog.la
/usr/bin/install -c .libs/libapttlog.a
/var/tmp/aptt-0.0.1-1-root/usr/lib/libapttlog.a
ranlib /var/tmp/aptt-0.0.1-1-root/usr/lib/libapttlog.a
chmod 644 /var/tmp/aptt-0.0.1-1-root/usr/lib/libapttlog.a
libtool: install: warning: remember to run `libtool --finish /usr/lib'
 /bin/sh ../libtool --mode=install /usr/bin/install -c  libaptttest.la
/var/tmp/aptt-0.0.1-1-root/usr/lib/libaptttest.la
libtool: install: warning: relinking `libaptttest.la'
(cd /homes/pgw99/rpm-devel/BUILD/aptt-0.0.1/src; /bin/sh ../libtool
--mode=relink gcc -O2 -march=i586 -o libaptttest.la -rpath /usr/lib
aptt/test/test.lo libapttlog.la)
gcc -shared  aptt/test/test.lo  -L/usr/lib -lapttlog   -Wl,-soname
-Wl,libaptttest.so.0 -o .libs/libaptttest.so.0.0.0
/usr/i486-suse-linux/bin/ld: cannot find -lapttlog
collect2: ld returned 1 exit status
libtool: install: error: relink `libaptttest.la' with the above command
before installing it
libtool: install: warning: remember to run `libtool --finish /usr/lib'

Is there any sensible way around this?

Regards,

Philip Willoughby

Systems Programmer, Department of Computing, Imperial College, London, UK
-- 
echo [EMAIL PROTECTED] | tr "bizndfohces" "pwgd9ociaku"

Why reinvent the wheel? . . . . . . . . . Because we can make it rounder...


___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool

gcc -m* & libtool

[Bob Friesenhahn]

A week ago I popped this into development libtool:

2002-11-18  Bob Friesenhahn  <[EMAIL PROTECTED]>

* ltmain.in: When using gcc, pass -mfoo to the linker
via $compiler_flags in order to pass architecture information to
the linker (e.g. 32 vs 64-bit). This may also be accomplished via
-Wl,-mfoo but this is not reliable with gcc because gcc may use
-mfoo to select a different linker, different libraries, etc, while
-Wl,-mfoo simply passes -mfoo to the linker. If there is a better
solution, please let me know what it is.

Note that this passes -mfoo arguments to the compiler at link-time to
ensure/allow a consistent ABI to be requested across the compile and
link phases.  This scheme works well with Autoconf since the user can
configure a project like

  ./configure CFLAGS=-mfoo LDFLAGS=-mfoo

and everything works.

It is just as easy to pop this update out of libtool as it was to pop
it in, so if there is a better way to accomplish this that works
reliably across an entire project built with GCC, Autoconf, and
libtool, please let me know.

Thanks,

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



___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool

Re: DESTDIR installs

[mlist . gnu . libtool]

==> "pw" == Philip Willoughby <[EMAIL PROTECTED]> writes:

pw> I have the following in a Makefile.am:
pw> pkglib_LTLIBRARIES=libapttlog.la
pw> libapttlog_la_SOURCES=aptt/log/log.c AM_CPPFLAGS=@INCLTDL@
pw> -I$(top_srcdir)/src -I$(top_builddir)/src
pw> libapttlog_la_LIBADD=@LIBLTDL@

pw> lib_LTLIBRARIES=libaptttest.la
pw> libaptttest_la_SOURCES=aptt/test/test.c
pw> libaptttest_la_LIBADD=libapttlog.la @LTLIBINTL@

pw> If I run:

pw> ./configure [Configure args] make make install

pw> everything installs OK, however, if I run:

pw> ./configure [Configure args] make make
pw> DESTDIR=/var/tmp/aptt-0.0.1-1-root/ install

pw> which I need to work to build an rpm cleanly, I get:

I've always felt that this is a deficiency in the way libtool does
its installs.  Then again, I use a very old version of libtool,
and this may have been fixed by now...

The problem is, the target install directory in libapptlog.la
(${pkglibdir}, I suppose) is used to link libapptest.la, but at
install time, libtool looks in

  ${pkglibdir}

only, and not in

  $DESTDIR${pkglibdir}

also, like it should.

I see two solutions here.  One is to fix libtool so that it
adds -L$DESTDIR${dir} for each -L${dir} found in a dependent
LTLIBRARY.  I'm a little wary of patching libtool, so I usually
use a shell script that pretends to be 'gcc', but adds the
desired $DESTDIR link path support.

The other solution, that I use in RPM spec files, is to seed
the environment from within the spec file:

  %install

  LIBRARY_PATH=${LIBRARY_PATH+":"}$DESTDIR${libdir}
  # add other directories as appropriate
  export LIBRARY_PATH

  make DESTDIR=$RPM_BUILD_ROOT install

Carl



___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool

Re: DESTDIR installs

[Guido Draheim]

[EMAIL PROTECTED] wrote:

==> "pw" == Philip Willoughby <[EMAIL PROTECTED]> writes:

pw> I have the following in a Makefile.am:
pw> pkglib_LTLIBRARIES=libapttlog.la
pw> libapttlog_la_SOURCES=aptt/log/log.c AM_CPPFLAGS=@INCLTDL@
pw> -I$(top_srcdir)/src -I$(top_builddir)/src
pw> libapttlog_la_LIBADD=@LIBLTDL@

pw> lib_LTLIBRARIES=libaptttest.la
pw> libaptttest_la_SOURCES=aptt/test/test.c
pw> libaptttest_la_LIBADD=libapttlog.la @LTLIBINTL@

pw> If I run:

pw> ./configure [Configure args] make make install

pw> everything installs OK, however, if I run:

pw> ./configure [Configure args] make make
pw> DESTDIR=/var/tmp/aptt-0.0.1-1-root/ install

pw> which I need to work to build an rpm cleanly, I get:

I've always felt that this is a deficiency in the way libtool does
its installs.  Then again, I use a very old version of libtool,
and this may have been fixed by now...

The problem is, the target install directory in libapptlog.la
(${pkglibdir}, I suppose) is used to link libapptest.la, but at
install time, libtool looks in

  ${pkglibdir}

only, and not in

  $DESTDIR${pkglibdir}

also, like it should.

I see two solutions here.  One is to fix libtool so that it
adds -L$DESTDIR${dir} for each -L${dir} found in a dependent
LTLIBRARY.  I'm a little wary of patching libtool, so I usually
use a shell script that pretends to be 'gcc', but adds the
desired $DESTDIR link path support.

The other solution, that I use in RPM spec files, is to seed
the environment from within the spec file:

  %install

  LIBRARY_PATH=${LIBRARY_PATH+":"}$DESTDIR${libdir}
  # add other directories as appropriate
  export LIBRARY_PATH

  make DESTDIR=$RPM_BUILD_ROOT install

Carl



I had the same problem - libtool does not like destdir-install
with two libraries being interdependent. I had a look through
the sources how to pass it down to libtool - but the automake
generated install-line for the .la will now pass an extra
argument. Without help from automake, I assume it would be
too hard to do.

Anyway, here's my solution - about the same trick but not
touching a global variable that might have defects on
subportions of the compilation:

--- snip ---
%setup
# fixing relink problems during install
LDFLAGS="-L%buildroot%_libdir" \
CFLAGS="$RPM_OPT_FLAGS" \
sh configure --prefix=%{_prefix} --enable-shared

%build
make

%install
rm -rf $RPM_BUILD_ROOT
make install DESTDIR=%buildroot
--- snip 

There goes another question, however: the libtool-install
for the .la will know the target directory. In most cases,
the two interdependent libraries get installed in the same
target place (atleast for my problem it was/is the case).
May be auto-add an -L for the target directory implicitly?



___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool

Re: DESTDIR installs

[Guido Draheim]

Carl D. Roth wrote:

I had the same problem - libtool does not like destdir-install
with two libraries being interdependent. I had a look through
the sources how to pass it down to libtool - but the automake
generated install-line for the .la will now pass an extra
argument. Without help from automake, I assume it would be
too hard to do.

Anyway, here's my solution - about the same trick but not
touching a global variable that might have defects on
subportions of the compilation:

--- snip ---
%setup
# fixing relink problems during install
LDFLAGS="-L%buildroot%_libdir" \
CFLAGS="$RPM_OPT_FLAGS" \
sh configure --prefix=%{_prefix} --enable-shared

%build
make

%install
rm -rf $RPM_BUILD_ROOT
make install DESTDIR=%buildroot
--- snip 

There goes another question, however: the libtool-install
for the .la will know the target directory. In most cases,
the two interdependent libraries get installed in the same
target place (atleast for my problem it was/is the case).
May be auto-add an -L for the target directory implicitly?



The desired behavior is for the flag to be added to the link-line
when the library is installed/built by rpm, but we don't want
the DESTDIR to be embedded in the .la file that is finally shipped...
You would need to make sure that touching LDFLAGS won't cause the
.la file to be altered...

It's true that LIBRARY_PATH is gcc-specific, but I'm pretty sure it won't
break other features of the build ;-)  Since the spec file is
architecture-specific, I didn't see that as a problem.


Aaargh, thank you, I did miss this one - yes, it gets coded into the
.la infofile, what a pity :-(

| # The name of the static archive.
| old_library='libxmlpcre.a'

| # Libraries that this one depends upon.
| dependency_libs=' -L/my/rpm/tmp/xmlg-0.6.1/usr/lib /usr/lib/libxmlglib.la /usr/lib/libpcre.la /usr/lib/libglib-2.0.la'



Another approach (usable in a patched libtool or in a wrapper script for
the compiler) is to test for the DESTDIR prefix dynamically:

  for each -L${DIR} switch in LDFLAGS
if $DESTDIR${DIR} is also a valid directory
  prepend $DESTDIR${DIR} to LDFLAGS

This way the .la files come out clean.



However, here we add "magic" that shouldn't be there. There should be some
explicit thing to be done. If we'd use this magic then it should be atleast
get configured right in with something like --destdir=$DESTDIR as to tell
./libtool *explicitly* that this prefix is temporary and about to be
relocated.


BTW, install-time linking has always been a problem - an rpm build has to
clean it up with some chrpath step on the library files.

Thinking it over again - changing a CC variable might be compiler specific,
what about using up another variable that is libtool specific and that
tells ./libtool to add these LIBTOOL_LDFLAGS to the relink-line? And
thereby not to put these extras into the .la? aaargh, phantasies... the
base problem is installtime relinking...






___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool

Re: [Fink-devel] libtool "module" behavior and darwin

[Max Horn]

An alternate solution might be to change the kbackgammon exectuable 
to load the kbackgammon.so, too, instead of linking against it. Or is 
there anything else that needs to link against these loadable modules?


Max
--
---
Max Horn
Software Developer

email: 
phone: (+49) 6151-494890


___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool

DESTDIR installs

[Charles Wilson]

Ummm, if I understand your problem, this has been fixed in CVS HEAD:

http://mail.gnu.org/pipermail/libtool-patches/2002-November/002159.html 
 and following thread.

However, it was never committed on the 1.4.x branch, even though it was 
submitted prior to the 1.4.3 release.  Unfortunately, 1.4.x is now 
officially dead, so if you're using that series you'll need to patch 
your libtool yourself, using Ossama's patch from

http://mail.gnu.org/pipermail/libtool-patches/2002-July/002061.html

--Chuck




___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool

no AIX 5 support? I've got some idea what's needed.

[Gary Kumfert]

Hi, 

I've found no support for AIX 5 in automake, autoconf, 
or libtool (not even config.guess!).  

Any libtool developer interested in teaming up to add 
AIX 5.x support to libtool?  I have a handful 
of settings that I tweeked by hand to get things working 
right.  I can just describe what settings are ultimately needed,
or try to hack the changes into scripts and send the diffs.

I'd be willing to work with someone to refine the code 
if I'm the only one with access to an AIX 5.x box.

Regards, 

Gary


  Gary Kumfert, Ph.D.   <[EMAIL PROTECTED]>
  Center for Applied Scientific Computing  phone: 925-424-2580
  Lawrence Livermore National Laboratory   fax:   925-423-9338
  P.O. Box 808,L-551
  Livermore, CA 94551-0808




___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool

Re: no AIX 5 support? I've got some idea what's needed.

[Robert Boehne]

Gary:

Have you tried CVS?  Libtool has support for IA64 AIX which
only comes in version 5 of AIX.

Robert

Gary Kumfert wrote:
> 
> Hi,
> 
> I've found no support for AIX 5 in automake, autoconf,
> or libtool (not even config.guess!).
> 
> Any libtool developer interested in teaming up to add
> AIX 5.x support to libtool?  I have a handful
> of settings that I tweeked by hand to get things working
> right.  I can just describe what settings are ultimately needed,
> or try to hack the changes into scripts and send the diffs.
> 
> I'd be willing to work with someone to refine the code
> if I'm the only one with access to an AIX 5.x box.
> 
> Regards,
> 
> Gary
> 
> 
>   Gary Kumfert, Ph.D.   <[EMAIL PROTECTED]>
>   Center for Applied Scientific Computing  phone: 925-424-2580
>   Lawrence Livermore National Laboratory   fax:   925-423-9338
>   P.O. Box 808,L-551
>   Livermore, CA 94551-0808
> 
> ___
> Libtool mailing list
> [EMAIL PROTECTED]
> http://mail.gnu.org/mailman/listinfo/libtool


___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool

Re: no AIX 5 support? I've got some idea what's needed.

[Gary Kumfert]

Rob, 

Nope.  Haven't tried CVS yet.  Figured someone would 
let me know if AIX 5 support is already there.  

What about AIX 5 on rs6000? PowerPC?  Those are really
my platforms of interest at the moment. 

Gary

On Mon, 25 Nov 2002, Robert Boehne wrote:

> Gary:
> 
> Have you tried CVS?  Libtool has support for IA64 AIX which
> only comes in version 5 of AIX.
> 
> Robert
> 
> Gary Kumfert wrote:
> > 
> > Hi,
> > 
> > I've found no support for AIX 5 in automake, autoconf,
> > or libtool (not even config.guess!).
> > 
> > Any libtool developer interested in teaming up to add
> > AIX 5.x support to libtool?  I have a handful
> > of settings that I tweeked by hand to get things working
> > right.  I can just describe what settings are ultimately needed,
> > or try to hack the changes into scripts and send the diffs.
> > 
> > I'd be willing to work with someone to refine the code
> > if I'm the only one with access to an AIX 5.x box.
> > 
> > Regards,
> > 
> > Gary
> > 
> > 
> >   Gary Kumfert, Ph.D.   <[EMAIL PROTECTED]>
> >   Center for Applied Scientific Computing  phone: 925-424-2580
> >   Lawrence Livermore National Laboratory   fax:   925-423-9338
> >   P.O. Box 808,L-551
> >   Livermore, CA 94551-0808
> > 
> > ___
> > Libtool mailing list
> > [EMAIL PROTECTED]
> > http://mail.gnu.org/mailman/listinfo/libtool
> 

-- 

  Gary Kumfert, Ph.D.   <[EMAIL PROTECTED]>
  Center for Applied Scientific Computing  phone: 925-424-2580
  Lawrence Livermore National Laboratory   fax:   925-423-9338
  P.O. Box 808,L-551
  Livermore, CA 94551-0808





___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool