[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: HOST_CC, crossgcc, mingw32, again/summarized - Re: confusionwith h

From: Guido Draheim
Subject: Re: HOST_CC, crossgcc, mingw32, again/summarized - Re: confusionwith host,build,target
Date: Mon, 07 Jan 2002 15:25:53 +0100

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.
> 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.

 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 
 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

     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}.

 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                          
GCS/E/S/P C++$++++ ULHS L++w- N++@ d(+-) s+a- r+@>+++ y++ 5++X- (geekcode)

reply via email to

[Prev in Thread] Current Thread [Next in Thread]