This is the mail archive of the
gcc-help@gcc.gnu.org
mailing list for the GCC project.
RE: Extract static object from dynamic one
- From: "Duft Markus" <Markus dot Duft at salomon dot at>
- To: Thomas Köppe <t dot koeppe at ed dot ac dot uk>, <gcc-help at gcc dot gnu dot org>
- Cc: "Tom Browder" <tom dot browder at gmail dot com>
- Date: Tue, 4 Dec 2007 15:47:10 +0100
- Subject: RE: Extract static object from dynamic one
Hi!
At least on windows some information that would have been included in a static library is processed and after that discarded by the linker. For example, in a release link of a DLL there are no more symbol names (except for those that are exported - and that only when not importing by ordinal numbers), so it would be impossible to come up again with the signature for a particular (internal) function.
I believe ELF keeps symbol names somewhere, but i'm not sure. Anyway i don't think, that a shared library contains all information a static library has. (for example at least the names of the objects containing the various functions are discarded.)
Cheers, Markus
Thomas Köppe <> wrote:
> Brian Dessent wrote:
> >
> > Tom Browder wrote:
> >
> >> On Dec 3, 2007 5:21 PM, Thomas Köppe <t.koeppe@ed.ac.uk> wrote:
> >>
> >>> [...]
> >>>
> >>> Suppose I have a dynamic C library libfoo.so (or foo.dll) along
> with >>> headers in foo.h. Is it possible to build from the binary a
> static >>> library libfoo.a?
> >>
> >> I believe GNU libtool can be used to do that.
> >> [...]
> >
> > Libtool is useful for creating both shared and static at the same
> > (build) time, but it won't let you create a static library from an
> > already linked shared library. There is no way to do that, as far
> as I > know. You need to recompile from source.
> >
> > Brian
>
> I agree that libtool does not deal with binary files in that way;
> that's why I was thinking about something from binutils.
>
> But is there a reason that it should be impossible in principle to
> reconstruct a statically linkable object from a shared library? After
> all, the code is there, I know the function signatures, and
> relocatable addresses can be resolved to fixed addresses at link time.
>
> Is there an obstruction in principle (that some vital information is
> lost in the shared library), or is it simply that no such tool has
> been written?
>
> Many thanks,
>
> Thomas
--
5. Dezember 2007
Salomon Automation am Schweizer Forum für Logistik, Lausanne, CH
Salomon Automation GmbH - Friesachstrasse 15 - A-8114 Friesach bei Graz
Sitz der Gesellschaft: Friesach bei Graz
UID-NR:ATU28654300 - Firmenbuchnummer: 49324 K
Firmenbuchgericht: Landesgericht für Zivilrechtssachen Graz