Re: interdependancies between libraries
On Tue, Jan 16, 2001 at 01:50:57PM +1100, Brian May wrote: > Oh, another observation: installing the libraries in their non-final > location (as required for Debian packaging tools, probably Redhat too) > simply does not work, as shown below. I think some of the required -L > options to the linker might be missing. > > > (It took me awhile to notice that errors occurred, shouldn't it stop > straight away? Maybe thats my fault for using CVS versions of autoconf > and automake). I concure that this is a huge issue, and I already submitted a patch on Oct 22 /2000 that fixed this for linux. I don't know why the libtool team didn't fix it up (I probably broke other OSes with it) and include it as it resolves this. I've reattached my patch to this email, but don't know if it will still apply to the current CVS head, but try it and see if it solves your packaging problem. What I've been doing for debs with inter-depends is having a local copy of ltmain.sh in my debian packages with the patch applied for building my project. Then it adds the right -L options. If the patch fails, I can send you the ltmain.sh I use in private. Good luck. -- Wesley W. Terpstra <[EMAIL PROTECTED]> Javien Canada Inc. - Linux Developer libtool-fix-prefixed-install-relink.diff.gz PGP signature
Separate Source Directories
Dear Libtoolers, How do you build a library using Libtool from source files that are located in different directories? For example moduleA/sourceA1.c moduleA/sourceA2.c moduleA/... moduleB/sourceB1.c moduleB/sourceB2.c moduleB/... moduleB/libmodule.la where libmodule.la would contain all object files from the moduleA and moduleB directories. I know Libtool doesn't currently support this feature but surely there are some software distributions out there that already do something like this? Thanks, Eric. ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: Separate Source Directories
Eric Lemings wrote: > > Dear Libtoolers, > > How do you build a library using Libtool from source files that are > located in different directories? I use VPATH to tell GNU make to look in other directories. For example, one of my Makefile.am's has this definition: VPATH = @srcdir@ : \ @top_srcdir@/drv/Geom : @top_srcdir@/src/Geom: \ @top_srcdir@/drv/TColGeom : @top_srcdir@/src/TColGeom: \ @top_srcdir@/drv/GeomAdaptor : @top_srcdir@/src/GeomAdaptor: \ @top_srcdir@/drv/AdvApprox : @top_srcdir@/src/AdvApprox: \ @top_srcdir@/drv/GeomLProp : @top_srcdir@/src/GeomLProp: \ @top_srcdir@/drv/Adaptor3d : @top_srcdir@/src/Adaptor3d: \ @top_srcdir@/src/TKG2d You need to have @srcdir@ in there, the other directories are where any other files make needs to know about, such as source. On some platforms the native 'make' does not support VPATH, but it is simple enough to install GNU make to fix that. Robert Boehne Software Engineer Ricardo Software Chicago Technical Center TEL: (630)789-0003 x. 238 FAX: (630)789-0127 email: [EMAIL PROTECTED] ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: Separate Source Directories
> "Eric" == Eric Lemings <[EMAIL PROTECTED]> writes: Eric> I know Libtool doesn't currently support this feature but Eric> surely there are some software distributions out there that Eric> already do something like this? You can use convenience libraries... Current versions of libtool are broken (from my experience) in that you PIC code is used for static libraries. I read something in this mailing list about solving this problem, so hopefully it has already been fixed, at least in the CVS repository for version 1.4, but I have not yet tested this. You create a convenience library in Makefile.am (assuming you use automake) with something like: noinst_LTLIBRARIES = libvers.la libvers_la_SOURCES = print_version.c and link libvers.la into the main library. libtool should take care of the rest (this sample taken from Heimdal). (oh, before my patch the upstream version also had: libvers_la_LDFLAGS = -static which meant non-PIC code was compiled in the shared libraries. I didn't like this, so removed it). -- Brian May <[EMAIL PROTECTED]> ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: interdependancies between libraries
> On Tue, Jan 16, 2001 at 01:50:57PM +1100, Brian May wrote: > > Oh, another observation: installing the libraries in their non-final > > location (as required for Debian packaging tools, probably Redhat too) > > simply does not work, as shown below. I think some of the required -L > > options to the linker might be missing. > > > > Some Debian libtool packages (eg. libgtk1.2) seem to get away with ./configure --prefix=/usr but then overriding that for the install make prefix=`pwd`/debian/tmp/usr install ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: interdependancies between libraries
> "Kevin" == Kevin Ryde <[EMAIL PROTECTED]> writes: >> On Tue, Jan 16, 2001 at 01:50:57PM +1100, Brian May wrote: > >> Oh, another observation: installing the libraries in their >> non-final > location (as required for Debian packaging tools, >> probably Redhat too) > simply does not work, as shown below. I >> think some of the required -L > options to the linker might be >> missing. > > Kevin> Some Debian libtool packages (eg. libgtk1.2) seem to get Kevin> away with Kevin> ./configure --prefix=/usr Kevin> but then overriding that for the install Kevin> make prefix=`pwd`/debian/tmp/usr install No - that is what causes this problem. Libraries get installed in `pwd`/debian/tmp, not /usr, where the linker (during "make install") can't find them. (Ok, I may have messed up my example :-(, but the same thing happens, I tried it too). -- Brian May <[EMAIL PROTECTED]> ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: interdependancies between libraries
> "Brian" == Brian May <[EMAIL PROTECTED]> writes: > "Kevin" == Kevin Ryde <[EMAIL PROTECTED]> writes: >>> On Tue, Jan 16, 2001 at 01:50:57PM +1100, Brian May wrote: > >>> Oh, another observation: installing the libraries in their >>> non-final > location (as required for Debian packaging tools, >>> probably Redhat too) > simply does not work, as shown below. I >>> think some of the required -L > options to the linker might be >>> missing. > > Kevin> Some Debian libtool packages (eg. libgtk1.2) seem to get Kevin> away with Kevin> ./configure --prefix=/usr Kevin> but then overriding that for the install Kevin> make prefix=`pwd`/debian/tmp/usr install > No - that is what causes this problem. Libraries get installed in > `pwd`/debian/tmp, not /usr, where the linker (during "make install") > can't find them. The correct way to do this is actually ./configure --prefix=/usr make install DESTDIR=`pwd`/debian/tmp Ganesan -- R. Ganesan ([EMAIL PROTECTED]) | Ph: 91-80-5721856 Ext: 2149 Novell India Development Center. | #include ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: interdependancies between libraries
> "Ganesan" == Ganesan Rajagopal <[EMAIL PROTECTED]> writes: Ganesan> The correct way to do this is actually ./configure Ganesan> --prefix=/usr Ganesan> make install DESTDIR=`pwd`/debian/tmp Hmmm. didn't know this. Lets try it: [624] [snoopy:bam] ~/source/cvs/libtool/depdemo >configure --prefix=/usr [...] [628] [snoopy:bam] ~/source/cvs/libtool/depdemo >make clean [...] [629] [snoopy:bam] ~/source/cvs/libtool/depdemo >make [...] [633] [snoopy:bam] ~/source/cvs/libtool/depdemo >make install DESTDIR=`pwd`/debian/tmp Making install in l1 make[1]: Entering directory `/home/bam/source/cvs/libtool/depdemo/l1' make[2]: Entering directory `/home/bam/source/cvs/libtool/depdemo/l1' /bin/sh ../../mkinstalldirs /home/bam/source/cvs/libtool/depdemo/debian/tmp/usr/lib mkdir /home/bam/source/cvs/libtool/depdemo/debian/tmp/usr mkdir /home/bam/source/cvs/libtool/depdemo/debian/tmp/usr/lib /bin/sh ../libtool --mode=install /usr/bin/install -c libl1.la /home/bam/source/cvs/libtool/depdemo/debian/tmp/usr/lib/libl1.la /usr/bin/install -c .libs/libl1.so.0.0.0 /home/bam/source/cvs/libtool/depdemo/debian/tmp/usr/lib/libl1.so.0.0.0 (cd /home/bam/source/cvs/libtool/depdemo/debian/tmp/usr/lib && rm -f libl1.so.0 && ln -s libl1.so.0.0.0 libl1.so.0) (cd /home/bam/source/cvs/libtool/depdemo/debian/tmp/usr/lib && rm -f libl1.so && ln -s libl1.so.0.0.0 libl1.so) /usr/bin/install -c .libs/libl1.lai /home/bam/source/cvs/libtool/depdemo/debian/tmp/usr/lib/libl1.la /usr/bin/install -c .libs/libl1.a /home/bam/source/cvs/libtool/depdemo/debian/tmp/usr/lib/libl1.a ranlib /home/bam/source/cvs/libtool/depdemo/debian/tmp/usr/lib/libl1.a chmod 644 /home/bam/source/cvs/libtool/depdemo/debian/tmp/usr/lib/libl1.a libtool: install: warning: remember to run `libtool --finish /usr/lib' make[2]: Nothing to be done for `install-data-am'. make[2]: Leaving directory `/home/bam/source/cvs/libtool/depdemo/l1' make[1]: Leaving directory `/home/bam/source/cvs/libtool/depdemo/l1' Making install in l2 make[1]: Entering directory `/home/bam/source/cvs/libtool/depdemo/l2' make[2]: Entering directory `/home/bam/source/cvs/libtool/depdemo/l2' /bin/sh ../../mkinstalldirs /home/bam/source/cvs/libtool/depdemo/debian/tmp/usr/lib /bin/sh ../libtool --mode=install /usr/bin/install -c libl2.la /home/bam/source/cvs/libtool/depdemo/debian/tmp/usr/lib/libl2.la libtool: install: warning: relinking `libl2.la' cd /home/bam/source/cvs/libtool/depdemo/l2; /bin/sh ../libtool --mode=relink gcc -g -O2 -o libl2.la -rpath /usr/lib l2.lo ../l1/libl1.la gcc -shared l2.lo -L/usr/lib -ll1 -Wl,-soname -Wl,libl2.so.0 -o .libs/libl2.so.0.0.0 /usr/bin/ld: cannot find -ll1 collect2: ld returned 1 exit status libtool: install: error: relink `libl2.la' with the above command before installing it libtool: install: warning: remember to run `libtool --finish /usr/lib' [...] No, it doesn't work. -- Brian May <[EMAIL PROTECTED]> ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: interdependancies between libraries
> "Wesley" == Wesley W Terpstra <[EMAIL PROTECTED]> writes: Wesley> What I've been doing for debs with inter-depends is having Wesley> a local copy of ltmain.sh in my debian packages with the Wesley> patch applied for building my project. Then it adds the Wesley> right -L options. That seems to help the 2nd problem, Thanks. Any ideas on the first problem? -- Brian May <[EMAIL PROTECTED]> ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
