synce few days, I have a message of portage suggestiung me to use the "static-
libs" USE flag for media-libs/jpeg-6b.

What may be the consequence ? Please be gentle with explaining this sorte of
things, as I have not the knowledges to understand the full compile process,
otherwise I am a little bit familiar with it !

Thanks
--
Stéphane Guedon
page web : http://www.22decembre.eu/
carte de visite : http://www.22decembre.eu/downloads/Stephane-Guedon.vcf
clé publique gpg : http://www.22decembre.eu/downloads/Stephane-Guedon.asc

On 09/11/2010 02:13 AM, Stéphane Guedon wrote:

synce few days, I have a message of portage suggestiung me to use the "static-
libs" USE flag for media-libs/jpeg-6b.

What may be the consequence ? Please be gentle with explaining this sorte of
things, as I have not the knowledges to understand the full compile process,
otherwise I am a little bit familiar with it !


I have jpeg-8b, so I can't be sure about 6b. I just turned on the static-libs
USE flag and re-installed jpeg. The only difference is that the 'static' lib
"/usr/lib/libjpeg.a" wasn't there before and it is now, that's all.

Is your system trying to upgrade jpeg to a newer version? I notice that 6b
doesn't use any USE flags, and the newer versions do use the static-libs flag.
(Just re-installing 6b shouldn't complain about USE flags because the package
doesn't look for them.)

Any program that uses the dynamic libjpeg.so would need to be re-compiled if
the version of jpeg changes. If the static library is used instead, the
program no longer needs libjpeg.so because the static library is linked into
the binary executable at compile-time. The price you pay is a larger binary
executable, but you never need to worry about future jpeg version changes.

I don't know how portage chooses between static and dynamic libs while building
a package. Anyone else know?

On 09/11/2010 01:52 PM, walt wrote:


I don't know how portage chooses between static and dynamic libs while building
a package.


Aha! Grepping through /usr/portage/eclass/* for 'static' taught me something:

xorg-2.eclass: myopts+=" $(use_enable static-libs static)"

So there is a "static" useflag in addition to "static-libs", which I'd never
noticed before.

I haven't actually tried the experiment yet, but I'm speculating that the
difference between 'static' and 'static-libs' is something like this:

Many packages install libraries so that other packages can use them. The
'static-libs' useflag tells a package to build and install the static version
of its own libraries *in addition to* the dynamic ones.

The 'static' useflag tells portage to build a package and link it against the
static versions of libraries that were installed by *other* packages.

Quiz for sober people: (That excludes moi

What happens if portage builds a 'static' package that links against a library
that was installed without the 'static-libs' useflag being set?

> What happens if portage builds a 'static' package that links against a
> library
> that was installed without the 'static-libs' useflag being set?

http://tldp.org/HOWTO/Program-Library-HOWTO/introduction.html writes:

"DL libraries aren't really a different kind of library format (both
static and shared libraries can be used as DL libraries);"

If I understand this at all, the term "static library" is a litle misleading.

* Libraries would be shared (in memory) and unshared.
* Executables would link static or dynamic (against both types).

The term "static library" would refer to unshared libraries, because
are typically linked statically (but must not).

Please correct me if I am wrong. I am new in the field.

Al

> "DL libraries aren't really a different kind of library format (both
> static and shared libraries can be used as DL libraries);"

Library archives (.a) and shared objects (.so) differ in several ways.
Roughly speaking:

From a file format perspective, .a files are simple collections (man ar)
of independent compiled objects, while .so files are complete libraries
produced by the linker and contain additional information which tell the
dynamic linker (ld.so) how to load and share the code.

More importantly, code which is intended to be used in shared objects
must be compiled with specific options as position-independent code,
whereas code in an archive needs not.

You can't link dynamically against a library archive, so all DL code on
Linux must be compiled as a shared object, whether it's actually shared
or not (think plugins).

As for the static use-flag: don't use it, unless you have very good
reasons to do so. It will result in a system with larger binaries and in
many cases you will *not* get true statically-linked binaries (e.g. most
of the things which link against glibc). As for dynamic linking breakage
following upgrades, IMO portage and revdep-rebuild give good enough
support for fixing that.

andrea

On 09/11/2010 12:13 PM, Stéphane Guedon wrote:

synce few days, I have a message of portage suggestiung me to use the "static-
libs" USE flag for media-libs/jpeg-6b.

What may be the consequence ? Please be gentle with explaining this sorte of
things, as I have not the knowledges to understand the full compile process,
otherwise I am a little bit familiar with it !


Enabling this flag will install a static version of libjpeg alongside
the dynamic one. You do not need to worry; other programs will continue
using the dynamic version, since this is the default. The static
version will only be used by programs that specifically demand it and
would otherwise not work.


So there are no consequences at all in enabling this USE flag.

Le Saturday 11 September 2010 22:52:09, walt a écrit :
> On 09/11/2010 02:13 AM, Stéphane Guedon wrote:
> > synce few days, I have a message of portage suggestiung me to use the
> > "static- libs" USE flag for media-libs/jpeg-6b.
> >
> > What may be the consequence ? Please be gentle with explaining this sorte
> > of things, as I have not the knowledges to understand the full compile
> > process, otherwise I am a little bit familiar with it !
>
> I have jpeg-8b, so I can't be sure about 6b. I just turned on the
> static-libs USE flag and re-installed jpeg. The only difference is that
> the 'static' lib "/usr/lib/libjpeg.a" wasn't there before and it is now,
> that's all.
>
> Is your system trying to upgrade jpeg to a newer version? I notice that 6b
> doesn't use any USE flags, and the newer versions do use the static-libs
> flag. (Just re-installing 6b shouldn't complain about USE flags because
> the package doesn't look for them.)
>
> Any program that uses the dynamic libjpeg.so would need to be re-compiled
> if the version of jpeg changes. If the static library is used instead,
> the program no longer needs libjpeg.so because the static library is
> linked into the binary executable at compile-time. The price you pay is a
> larger binary executable, but you never need to worry about future jpeg
> version changes.
>
> I don't know how portage chooses between static and dynamic libs while
> building a package. Anyone else know?

In fact, static-libs is for jpeg-8b , but Imade a mistake when write the
mail...

So I can use the flag without worrying. Good !
Thanks !

--
Stéphane Guedon
page web : http://www.22decembre.eu/
carte de visite : http://www.22decembre.eu/downloads/Stephane-Guedon.vcf
clé publique gpg : http://www.22decembre.eu/downloads/Stephane-Guedon.asc

> You can't link dynamically against a library archive, so all DL code on

Don't you contradict
http://tldp.org/HOWTO/Program-Library-HOWTO/introduction.html with
this?

Practically you never do. But could, if you really wanted?

AFAIK you need PIC only to share libs in memory. The rest is already
covered by MMU.

So why shouldn't you be able to load an unshared lib (without PIC)
dynamically? Sure there still would be some additional steps.

Al

> So why shouldn't you be able to load an unshared lib (without PIC)
> dynamically? Sure there still would be some additional steps.

I am not talking specifically about PIC/non-PIC code here. PIC is
relevant because when you're doing dynamic loading you generally cannot
predict at what (virtual) address in the process space the loaded object
will end up at.
That said, whether you can dynamically load non-PIC code depends on the
specific architecture (e.g. on x86 you can have non-PIC code in shared
objects, albeit at the price of the dynamic linker having to patch all
relocations in the loaded object, while on amd64 you can't because the
ABI allows certain kinds of relocations in non-PIC code which cannot be
handled this way.).

What I am saying is that there is no way to dynamically load code from a
.a file, at least not with the system tools, period.

There are reasons for this: first, a .a is not a "real" library but a
collection of independent compiled objects (building a .a does not
entail any kind of linking: it's about the same as tar'ing .o files
together). Moreover, the dynamic linker (ld.so) needs a certain amount
of information about the contents of any object it has to load: this
information is stored in specific ELF sections and is computed and
written by the "standard" linker (ld) when it builds the shared object
from its components.

andrea

>
> What I am saying is that there is no way to dynamically load code from a
> .a file, at least not with the system tools, period.
>

O.K. so we have to stress the term archive in your statement.

Al