Is she satisfied enough with you in bed? HnfIUbSx

We Gua-ran-tee you will have: - Permanent Mem.ber grow"th by at least 1-3 inch"es for ALL men - More pleasurable org!asm unlike you've felt before - Increased se{xual control that your partner will love - Larger thicker Johns.on your partner will love - Rock hard erect_ions that YOU can control

multi part library?

Hi, how to build a multi part library? i.e. source is in A1/ A2/ and B/. libA1 is meant to be built from A1/* and B/*, libA2 is meant to be built from A2/* and B/*. what people do is this: B/Makefile.am: noinst_LIBRARIES = libB.a libB_a_SOURCES = ... A1/Makefile.am: lib_LTLIBRARIES = libA1.la li

Re: Linking with relocated libraries

On Thu, 2004-02-05 at 19:18, [EMAIL PROTECTED] wrote: Sorry about the late reply, but here goes... > I have a situation where I'm constructing a filesystem image, and I need > to use the contents of that image to build new packages to be installed > in the image. For example, I have $ROOT, which

Re: Linking order

On Wed, 2004-01-28 at 18:05, Matthew Zeits wrote: > I am working on a project that should compile both globally--with prefix > unset so install goes to /usr/local/ and with prefix set to an arbitrary > directory. When the program links, even if I define an -L or an rpath, > it looks to /usr/lo

Re: libtool & crosscompile problem

On Thu, 2004-02-12 at 17:08, Pieter Grimmerink wrote: > I have a strange situation with libtool (version 1.4.3), I'm wondering what I > could do to make it work. > This is yet another result of the bug that Libtool would ignore the -L option for non-libtool libraries, and instead pick a library

Re: Crosscompiling again...

On Thu, 2004-03-04 at 12:17, Tietz Fabian (AA/ESW1) wrote: > Im trying to crosscompile a c++ shared Library for a Mips target > System using libtool. > Unfortunately linking fails, because of libtool trying > to link against "/usr/lib/libstdc++.so", which is the X86 Version > of the Library, not t

Re: more on serial

On Sun, 2004-03-07 at 22:23, Patrick Welche wrote: > LT_INIT is defined using AC_DEFUN_ONCE. There is no documentation for > this macro in autoconf.texi, and aclocal doesn't know about it, or at > least, it doesn't pick up the fact that as LT_INIT appears in configure.ac, > it should include m4/li

Re: libtool: link: warning: '[.la file]' seems to be moved

On Fri, 2004-02-13 at 20:07, Albert Chin wrote: > ltmain.in prints out a warning when it thinks the .la file isn't in > $libdir: > if test "$absdir" != "$libdir"; then > $echo "$modename: warning: \`$deplib' seems to be moved" 1>&2 > fi > > However, if $absdir has "..", and it resolves to

Re: no serial number?

On Wed, 2004-03-10 at 16:48, Gary V. Vaughan wrote: > Patrick Welche wrote: > | libtool.m4 contains: > | > | # serial 49 AC_PROG_LIBTOOL > | AC_DEFUN_ONCE([LT_INIT], > | AU_DEFUN([AC_PROG_LIBTOOL], [LT_INIT]) > | AU_DEFUN([AM_PROG_LIBTOOL], [LT_INIT]) > | > |>From the above, libtoo

Re: Another stable release?

On Sun, 2004-03-14 at 14:51, Peter O'Gorman wrote: I'll probably have some free time toward the end of this month, and am volunteering to roll a release of branch-1-5 if nobody has any objections. Would that be 1.5.4 or 1.5.3? 1.5.4 :-) Just to note that due to a bug that I need to fix, and a ho

Re: multi part library?

Andreas Jellinghaus <[EMAIL PROTECTED]> writes: Hi Andreas, > if I change B/Makefile.am to > noinst_LTLIBRARIES=libB.la > libtool/automake will do what i want. > libB.a has the non PIC code, .libs/libB.al has the PIC code. Correct. > but if I change A1/Makefile.am to > libA1_la_LIBA