Es schrieb Robert Collins:
> >
> > and note that there are quite some other people on this list who would
> > love to see the things get sorted out once and for all. It just needs
> > someone with time enough to exchange the three dozen e-mails it will
> > take (atleast!) to get things right. Just go ahead and try to get to
> > the minds of people who have the mana to do it... be sure that a lot
> > of the people around here will back you if anyone asks on what grounds
> > your request are built. So far, anyone to whom I've talked said that
> > it is right to put the impgen.c functionality into dlltool.. where it
> > rightfully belongs but no one of us has rights enough to modify it. And
> > be sure that the impgen.c code gets rejected since it does not use
> > any code from libbfd as it should - it's a working hack and thousands
> > of people in the world use it, even for production (incl. libsdl.org??)
>
> Guido, can you succintely describe what impgen does - particularly in a
> cross- environment.
>
short explanation:
impgen.exe is the first part of an implib.exe - it scans a given dll for
exported symbols and creates an .exp-def file - then the (cross)gcc is used
to create a binary import-library. Usage: to bind the zlib, you give a
"-lz" on the command line to libtool - libtool will find the .dll (IIRC it
will prefer a prebuilt import lib) - scan the export table, create an
binary import lib, and give it to the linker so that it can be bound to
the .dll currently under creation.
long explanation:
that's part of the problem - I have a rather coarse knowlede of the dll
format and the scheme to create a dll that has a dependency on another
dll. The impgen does create an output.def not unlike the output of
`dlltool -z output.def --export-all-symbols myown.dll` however it should
not read "all-symbols" but "--dynamic-symbols" - all-symbols will also
list imports of the dll. I had a look at the current dlltool/libbfd to
see how to check for symbols and their characteristics in order to get
at a list of exported-symbols with it - but I failed. The list was always
longer than the one of impgen.exe (or close to nothing). To me, it looks
like the impgen.exe does fetch another (!!) symbol-table from the dll than
the libbfd/pe code does.
cross-environment:
the impgen is a C-language binary - I am not sure if we could make a series
of shell/sed scripts that can take the output of "dlltool -z --whatever" to
create the list of exported-symbols. In the current libtool, the impgen.c
file is compiled on the fly into an impgen.exe so that it can be used right
away to get at the export-table. However, in a cross-environent it shall
not be called impgen.exe but it should be in build-OS binary format so that
it can run right away - the CC setting is set to a crosscompiler which would
create a target-OS binary. This makes the *only* place in libtool where we
need a HOST_CC setting since it is the *only* place we need to compile a
program to buildmachine-format on the fly.
The point in question lives in libtool.m4 - under the topic of cygwin|mingw|pw32
a variable "extract_expsyms_cmds" gets set. If it would not be a w32pe-target
then it would be set to $lt_extract_expsyms_cmds which is usually nothing or
a call to objdump with some filters attached. Here is a copy with extra
identation to get a bit more readable
extract_expsyms_cmds='
test -f $output_objdir/impgen.c || \
sed -e "/^# \/\* impgen\.c starts here \*\//
,/^# \/\* impgen.c ends here \*\//
{ s/^# //;s/^# *$//; p; }"
-e d < $''0 > $output_objdir/impgen.c ~
test -f $output_objdir/impgen.exe \
|| (cd $output_objdir && \
if test "x$HOST_CC" != "x" ; then $HOST_CC -o impgen impgen.c ; \
else $CC -o impgen impgen.c ; fi) ~
$output_objdir/impgen $dir/$soroot > $output_objdir/$soname-def'
and libtool.texi says
@defvar old_archive_from_expsyms_cmds
If a static library must be created from the export symbol list in order to
correctly link with a shared library, @samp{old_archive_from_expsyms_cmds}
contains the commands needed to create that static library. When these
commands are executed, the variable @var{soname} contains the name of the
shared library in question, and the @var{$objdir/$newlib} contains the
path of the static library these commands should build. After executing
these commands, libtool will proceed to link against @var{$objdir/$newlib}
instead of @var{soname}.
conclusion:
the expsyms_cmds seems to be targetting the special implib handling of
.dll-based libtool-targets - it could be made over completly if it would
be beneficial. The extract_syms_cmds should be a simple call to a helper
tool like a prebuilt dlltool-impgen - or a "dlltool -z x --dynamic-symbols",
so it is simple shell-script and not compilation request. The rest of the
steps in current libtool will ensure that the -def file gets converted into
an importlib (.lib in win32 jargon???) and bound to the new dll being in
the works. Native compilation has no problems with the current setup since
HOST_CC == CC - nobody recognizes consiously that a buildtool is compiled
on the fly and invoked immediately.
HTH, cheers,
-- guido http://freespace.sf.net/guidod
GCS/E/S/P C++$++++ ULHS L++w- N++@ d(+-) s+a- r+@>+++ y++ 5++X- (geekcode)
_______________________________________________
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
