| 1 |
* Al <oss.elmar@××××××××××.com> wrote: |
| 2 |
|
| 3 |
> While porting to cygwin I can be happy when they use it. For my first |
| 4 |
> impression those libraries are more easy to port. They produce |
| 5 |
> libraries with a *.dll.a suffix like the native libraries of Cygwin. |
| 6 |
|
| 7 |
Just a few years ago, autotools (especially w/ libtool) was totally |
| 8 |
unusable for any kind of isolated (not just crosscompiling), |
| 9 |
based on completely stupid assumptions and practically undebuggable. |
| 10 |
|
| 11 |
All the functionality could be easily done w/ shell functions |
| 12 |
instead of syntactically unstable m4 macros. I've started a little |
| 13 |
bit of hacking @ zlib (see oss-qm repo) how that could look like. |
| 14 |
|
| 15 |
> The other example is libz. AFAIK it has a manually written configure |
| 16 |
> script. It generates libz.so. bzip2 ends up in error messages until I |
| 17 |
> build it statically. |
| 18 |
|
| 19 |
AFAIK zlib properly builds shared library as well as static one |
| 20 |
(at least on unixoid targets). Win32 targets are still a bit messy, |
| 21 |
but there's work ongoing on that. |
| 22 |
|
| 23 |
> I still try to understand the relation of shared libraries and dynamic |
| 24 |
> libraries. I read that dynamic libraries are linked at runtime. I also |
| 25 |
> read, that you can dynamically link againgst a shared as well as |
| 26 |
> against a normal library. |
| 27 |
> |
| 28 |
> But isn't a normal library also shared when multiple programs link it |
| 29 |
> at runtime or does shared library mean it is shared in memory (PIC)? |
| 30 |
|
| 31 |
Well, static libraries are essentially an archive of plain object |
| 32 |
files (maybe with an additional symbol table for faster lookup). |
| 33 |
They essentially get linked in at build time just like plain objects. |
| 34 |
|
| 35 |
Shared libraries are different: they really get linked together, |
| 36 |
certain sections (especially symbol tables) are merged, local |
| 37 |
references resolved. An shared library actually is one big object |
| 38 |
file (that's why they're also called shared object). Now these |
| 39 |
objects are loaded and linked-in at the process startup phase |
| 40 |
(or later using dlopen()). At this point, "shared" means that |
| 41 |
multiple programs can use the very same code from one shared |
| 42 |
object file. |
| 43 |
|
| 44 |
Another level of sharing is at runtime, by using shared pages by |
| 45 |
the MMU. This is a bit more complex: you need to construct the |
| 46 |
binary code in a way that multiple processes can map it into |
| 47 |
separate address offsets (historical systems require the addresses |
| 48 |
to be defined at compile time, which obviously is impractical). |
| 49 |
At that point -fPIC comes into play: the code is generated in a |
| 50 |
way that it's position in process's address space doesnt matter |
| 51 |
anymore (at least on page-granularity). So calling processes |
| 52 |
can directly map the shared object's text segments into quite |
| 53 |
arbitraty offsets without touching the actual code pages, and |
| 54 |
the MMU only has to maintain one physical copy of them. |
| 55 |
|
| 56 |
PIC tends to be a little bit larger and slower than non-PIC |
| 57 |
(more indirect addressing), but on most today's machines |
| 58 |
the impact on real workloads is questionable. |
| 59 |
|
| 60 |
|
| 61 |
cu |
| 62 |
-- |
| 63 |
---------------------------------------------------------------------- |
| 64 |
Enrico Weigelt, metux IT service -- http://www.metux.de/ |
| 65 |
|
| 66 |
phone: +49 36207 519931 email: weigelt@×××××.de |
| 67 |
mobile: +49 151 27565287 icq: 210169427 skype: nekrad666 |
| 68 |
---------------------------------------------------------------------- |
| 69 |
Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme |
| 70 |
---------------------------------------------------------------------- |
Archives