Re: [gentoo-user] Re: static-libs
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
[gentoo-user] Re: static-libs
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.
Re: [gentoo-user] Re: static-libs
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 signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] Re: static-libs
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
Re: [gentoo-user] Re: static-libs
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
Re: [gentoo-user] Re: static-libs
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
Re: [gentoo-user] Re: static-libs
* Andrea Conti a...@alyf.net wrote: 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. Not necessarily. But it can't be shared at runtime anymore, since the dynamic loader has to change the codepages for each process. (well, there *is* a way ... back in a.out times libraries hat been compiled/linked to specific address spaces, but obviously that's quite complex to manage and not advisable outside speficic embedded environments) 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). You can (apache did it once, aeons ago), but it's quite tricky, and it's hard to get the pages shared between processes. Not the recommended way. cu -- -- Enrico Weigelt, metux IT service -- http://www.metux.de/ phone: +49 36207 519931 email: weig...@metux.de mobile: +49 151 27565287 icq: 210169427 skype: nekrad666 -- Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme --
[gentoo-user] Re: static-libs
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?
[gentoo-user] Re: static-libs
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?
Re: [gentoo-user] Re: static-libs
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
