Re: Using libtool for linking

[Benoit SIGOURE]

On Aug 17, 2007, at 8:42 PM, Jason Curl wrote:


Peter O'Gorman wrote:

On Fri, 2007-08-17 at 13:29 +0200, Jason Curl wrote:

As for testing the situation, AC_CHECK_LIB makes me believe it  
will work. But it only works in a subset of cases (i.e. static  
only). I have another implementation that I can compile in but at  
the moment there is no indication I should use my own internal  
implementation (I'd rather use an external implementation where  
possible in the belief it's probably been better debugged).


So, ideas how to work around this problem to achieve my goal?

Why not import the libiberty sources into your project and build a
convenience libiberty.


I'd rather use what's already installed.


This topic was already raised on this ML (although it was more  
Windows [Cygwin] centered):

http://lists.gnu.org/archive/html/libtool/2007-03/msg00022.html

I don't know the details but it looks like libiberty is very special  
and it seems troublesome to link a library against an installed  
version of libiberty so you should probably reconsider shipping a  
copy of libiberty with your sources (which is what is encouraged by  
the manual of libiberty) or not use libiberty at all.


http://lists.gnu.org/archive/html/libtool/2007-03/msg00024.html
"It is always built static by default even on ELF systems, for
the same reason as libiberty - it is not expected to expose anything
resembling a stable or maintained ABI.  And its maintainers do not want
the burden of having to maintain an ABI given its history of not being
designed as such."

http://gcc.gnu.org/onlinedocs/libiberty/Using.html
"To date, libiberty is generally not installed on its own. It has  
evolved over years but does not have its own version number nor  
release schedule."

which seems to confirm what's been said in the above reply.

Cheers,

--
Benoit Sigoure aka Tsuna
EPITA Research and Development Laboratory




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

Re: Libtool woes

[Ralf Wildenhues]

Hello Jason, Brian, all,

* Jason Curl wrote on Mon, Aug 20, 2007 at 11:41:03AM CEST:
> Brian Dessent wrote:
>>
[ snip nice, concise and well-written explanations ]
>>
> Brian - thanks for the concise description. Ralf - any way to may be
> add an addendum to the libtool docs for this, just for info?

Here's your (and by this I intend to address both of you alike ;-)
chance to get involved in Libtool development -- check out CVS Libtool
as explained on , read on how to
, and start turning
it into a chapter of the manual.

For short platform-specific configuration notes, see the node "Configure
notes" with sources in doc/notes.texi.  Longer stuff could be put under
"Platform quirks" in doc/libtool.texi; I would not mind if there were a
new section about w32-specific issues.

Expect to have to revise your patch a couple of times.  ;-)

Cheers,
Ralf


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

Re: Creating ONLY static libraries

[Mike Frysinger]

On Monday 20 August 2007, Omri Azencot wrote:
> Hello
> I am using libtool 1.5.23 during the building process, I am also using
> autoconf(2.61) to create the configure file.
> in configure.ac I used the macro AC_DISABLE_SHARED, and in the log I got
> the following line:
>
> checking whether to build shared libraries... no
>
>
> but, after "make install" the package did installed in the installation
> folder files of the type *.la *.dll.a.
>
> My goal is to create only static libraries of this module, am I missing
> something ?

why do you think something is wrong ?  neither *.la nor *.a are shared 
libraries
-mike


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

Creating ONLY static libraries

[Omri Azencot]

Hello
I am using libtool 1.5.23 during the building process, I am also using
autoconf(2.61) to create the configure file.
in configure.ac I used the macro AC_DISABLE_SHARED, and in the log I got the
following line:

checking whether to build shared libraries... no


but, after "make install" the package did installed in the installation
folder files of the type *.la *.dll.a.

My goal is to create only static libraries of this module, am I missing
something ?

thanks in advance

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

Re: Libtool woes

[Jason Curl]

Brian Dessent wrote:

.dll.a is the import library.  .dll is the actual library.  Both should
be produced.  The import library is used when linking against the
library, but it is not needed at runtime and contains no code.  It's
typically distributed in the same context as headers -- it is needed by
developers who want to build against your library, but not users who
simply want to run software that uses your library.  In some cases it is
also named just "libfoo.a", or perhaps "foo.lib" if you want
compatibility with users of the MS toolchain.  As its name suggests this
is actaully an "ar" archive.

It looks like you may be getting confused because the linker outputs a
message along the lines of "creating file libfoo.dll.a" when the
--out-implib linker switch is used, but this really means "in addition
to the normal output libfoo.dll I'm also producing an import library
libfoo.dll.a as a side effect of creating the library" not that the
library would actually be named libfoo.dll.a.

The concept of an import library is a bit of a hold-back to days past. 
Using the GNU linker at least, you can link directly to a DLL without

any import library.  However, there is one function of an import library
that cannot be duplicated otherwise, and that is the ability to provide
aliases for symbol names.  This allows you to do things like rename
functions in the actual library without affecting callers/users that use
the old name.  It also comes in very handy when reconciling differences
in stdcall function decoration when trying to mix code between different
vendors' toolchains.

PE has no means of explicit symbol versioning.  Shared library
versioning works on the basis of choosing an appropriate filename for
the library, i.e. libfoo-n.dll.  This should happen automatically when
you use -version-info appropriately.

The import library thus also provides one further function that makes it
very handy -- it functions analogously to the "foo.so -> foo.so.1"
symlink on POSIX systems.  The import library is always named just
libfoo.dll.a without any version numbers, and so the linker finds it
when you specify -lfoo.  However, the actual name of the library may be
libfoo-2.dll (or cygfoo-2.dll if you're using Cygwin) and hence the
import library is the thing that selects which version of the library to
link against.

For example on Cygwin:

$ ls -l /usr/bin/cygintl* /usr/lib/libintl*
-rwxr-x---+ 1 brian Users 22K Dec 13  2001 /usr/bin/cygintl-1.dll
-rwxr-x---+ 1 brian Users 37K Aug 10  2003 /usr/bin/cygintl-2.dll
-rwxr-x---+ 1 brian Users 31K Nov 19  2005 /usr/bin/cygintl-3.dll
-rwxr-x---+ 1 brian Users 31K Oct 22  2006 /usr/bin/cygintl-8.dll
-rwxr-x---+ 1 brian Users 48K Oct 22  2006 /usr/lib/libintl.a
-rwxr-x---+ 1 brian Users 30K Oct 22  2006 /usr/lib/libintl.dll.a
-rwxr-x---+ 1 brian Users 800 Oct 22  2006 /usr/lib/libintl.la

Here you see that there are four versions of the libintl library
installed, however there is just the one import library.  The name of
the DLL is encoded into the import library, so this means any new code
that is compiled today with -lintl will find /usr/lib/libintl.dll.a
which internally specifies the filename corresponding to ABI version 8
of the library.  But the other versions can still exist on disk for the
sake of supporting existing binary packages of the previous ABI
versions.  So this works just like the symlink on POSIX that selects
which version of the library all new binaries should link against (which
is almost always the newest.)

  
Brian - thanks for the concise description. Ralf - any way to may be add 
an addendum to the libtool docs for this, just for info?

Brian

  




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