Libtool question

Hi folks,

I’m still working on getting my own libtool implementation and
SDL running together (since I need it for sysroot’ed building).

What I did not yet understand is:

How is libtool been told, whether a library shall be built or
linked-against statically vs. dynamically ?

Could anyone help ?

cu–

Enrico Weigelt == metux IT service

phone: +49 36207 519931 www: http://www.metux.de/
fax: +49 36207 519932 email: contact at metux.de
cellphone: +49 174 7066481

– DSL ab 0 Euro. – statische IP – UUCP – Hosting – Webshops –

I do not know exactly what you want, but

./libtool --help --mode=link

may give a hint (or look directly at the source).

Regards,
Johannes

< http://libufo.sourceforge.net > The OpenGL GUI ToolkitOn Tuesday 20 September 2005 21:54, Enrico Weigelt wrote:

I’m still working on getting my own libtool implementation and
SDL running together (since I need it for sysroot’ed building).

What I did not yet understand is:

How is libtool been told, whether a library shall be built or
linked-against statically vs. dynamically ?

Could anyone help ?

  • Johannes Schmidt wrote:

I’m still working on getting my own libtool implementation and
SDL running together (since I need it for sysroot’ed building).

What I did not yet understand is:

How is libtool been told, whether a library shall be built or
linked-against statically vs. dynamically ?

Could anyone help ?

I do not know exactly what you want, but

Well, I’ll try to explain this a little bit:

SDL.so consists of many smaller libs, these are first build one
by one and then linked together. These (partial) libs are not
installed, just SDL.so (AFAIK).

When they get linked together to libSDL, they’re in "uninstalled"
state (created by --link, but not yet installed with --install),
so I assumed “uninstalled” libs imported by other libs are linked
statically. Now I’ve got some packages (ie. glib or gtk), where
this is obviously NOT the case: several libs are linked together,
but these are installed too, so we can link dynamically.

BTW: this is not just waste of space, but also can lead to problems
with duplicate symbols and global variables.

So I have to find out, how libtool decides whether it links one
lib against another statically vs. dynamically.

./libtool --help --mode=link

may give a hint

not really. the offical documentation also doesn’t say anything
about this.

(or look directly at the source).

if this is a joke, it’s not really funny …

cu> On Tuesday 20 September 2005 21:54, Enrico Weigelt wrote:


Enrico Weigelt == metux IT service

phone: +49 36207 519931 www: http://www.metux.de/
fax: +49 36207 519932 email: contact at metux.de
cellphone: +49 174 7066481

– DSL ab 0 Euro. – statische IP – UUCP – Hosting – Webshops –

[…]

SDL.so consists of many smaller libs, these are first build one
by one and then linked together. These (partial) libs are not
installed, just SDL.so (AFAIK).

When they get linked together to libSDL, they’re in "uninstalled"
state (created by --link, but not yet installed with --install),
so I assumed “uninstalled” libs imported by other libs are linked
statically. Now I’ve got some packages (ie. glib or gtk), where
this is obviously NOT the case: several libs are linked together,
but these are installed too, so we can link dynamically.

BTW: this is not just waste of space, but also can lead to problems
with duplicate symbols and global variables.

So I have to find out, how libtool decides whether it links one
lib against another statically vs. dynamically.

Libtool does not decide it at all.
These temporary libs are marked as noinst libraries in their corresponding
automake makefiles (Makefile.am) and as “libadd” in the top-level makefile.

It may work if you replace the “noinst_LTLIBRARIES” with “lib_LTLIBRARIES” and
remove them from libSDL_la_LIBADD.

./libtool --help --mode=link

may give a hint

not really. the offical documentation also doesn’t say anything
about this.

The man pages as well as “./libtool --help” state that.

(or look directly at the source).

if this is a joke, it’s not really funny …

Sorry, but it shouldn’t be a joke.
Almost everything I know about libtool is from the sources.

Regards,
Johannes

< http://libufo.sourceforge.net > The OpenGL GUI ToolkitOn Monday 26 September 2005 02:47, Enrico Weigelt wrote:

  • Johannes Schmidt wrote:
> Libtool does not decide it at all. > These temporary libs are marked as noinst libraries in their corresponding > automake makefiles (Makefile.am) and as "libadd" in the top-level makefile. > > It may work if you replace the "noinst_LTLIBRARIES" with "lib_LTLIBRARIES" and > remove them from libSDL_la_LIBADD.

After hours and hours of deeply hacking, I’ve now found it out.
The noinst-libs do not get an rpath passed to libtool, and so it links
statically against it.

Quite myterious.

(or look directly at the source).

if this is a joke, it’s not really funny …

Sorry, but it shouldn’t be a joke.
Almost everything I know about libtool is from the sources.

I better dont ask how much time this costed …

BTW: i’ve now got a quite clean implementation …

cu–

Enrico Weigelt == metux IT service

phone: +49 36207 519931 www: http://www.metux.de/
fax: +49 36207 519932 email: contact at metux.de
cellphone: +49 174 7066481

– DSL ab 0 Euro. – statische IP – UUCP – Hosting – Webshops –

  • Johannes Schmidt <@Johannes_Schmidt> wrote:

Libtool does not decide it at all.
These temporary libs are marked as noinst libraries in their
corresponding automake makefiles (Makefile.am) and as “libadd” in the
top-level makefile.

It may work if you replace the “noinst_LTLIBRARIES” with
"lib_LTLIBRARIES" and remove them from libSDL_la_LIBADD.

After hours and hours of deeply hacking, I’ve now found it out.
The noinst-libs do not get an rpath passed to libtool, and so it links
statically against it.

Quite myterious.

Well, the rpath argument specifies the run path for installed libraries.
At least on Unix style systems, rpath is required to build shared libraries.

If you just want to create a static archive with libtool, use the -static or
-all-static flag (don’t know how this fits in automake; autoconf has its
AC_ENABLE_SHARED, AC_ENABLE_STATIC macros,
but this is a global change).
See also:
http://www.gnu.org/software/libtool/manual.html#Link-mode

[…]

Almost everything I know about libtool is from the sources.

I better dont ask how much time this costed …

Heh :slight_smile:
I know just enough to create dynamic libraries on all
systems I have access to.

BTW: i’ve now got a quite clean implementation …

Hmm, open source?
I wouldn’t mind a link :slight_smile:

Anyway, we are getting offtopic.
Perhaps we should continue privately.

Regards,
Johannes

< http://libufo.sourceforge.net > The OpenGL GUI ToolkitOn Tuesday 04 October 2005 01:23, Enrico Weigelt wrote:

P? Thu, 06 Oct 2005 11:49:20 +0200, skrev Johannes Schmidt
:

Well, the rpath argument specifies the run path for installed libraries.
At least on Unix style systems, rpath is required to build shared
libraries.

No. It’s not required in Linux, at least.

  • Gerry

Argl, yes, you’re right.
I’m still on this libtool trip where you need an rpath argument (for libtool)
to create “normal” shared libs (in contrast to libtool convenience
libraries).

http://www.gnu.org/software/libtool/manual.html#Static-libraries

Regards,
Johannes

< http://libufo.sourceforge.net > The OpenGL GUI ToolkitOn Thursday 06 October 2005 14:10, Gerry JJ wrote:

P? Thu, 06 Oct 2005 11:49:20 +0200, skrev Johannes Schmidt

<@Johannes_Schmidt>:

Well, the rpath argument specifies the run path for installed libraries.
At least on Unix style systems, rpath is required to build shared
libraries.

No. It’s not required in Linux, at least.