Re: [Mingw-users] Re: libbfd, libtool & Win32
David Olofson wrote: > > That brings up another interesting point: If impgen was to be compiled > when installing libtool, wouldn't that result in the same problem? I > mean, impgen should only build when you're installing libtool for a cross > compiler - and then you're in that darn cross compiler environment again! > *heh* > > How would one get around that? > Having impgen be installed for the host system would work as long as the target is kept in mind. So, your impgen would be built to execute on Linux but target binary libraries for Win32. Much the same way GCC does it now. You could use dlltool to create the same files as impgen so that impgen isn't needed AFAIK. I could see keeping impgen if it is possible to code it to target a different system other than Win32. Earnie. ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: [Mingw-users] Re: libbfd, libtool & Win32
On Monday 23 September 2002 15:30, Earnie Boyd wrote: > David Olofson wrote: > > However, it's still a very bad idea to compile tools as part of the > > application build process. ;-) > > Right, if you want to install implib as part of distributable resource > when target == some win32 platform (Cygwin, MinGW, MSVC, etc.) fine, > but don't create it in every .libs/ directory. Anything that doesn't force me to explain to libtool which compiler to use for this single special case - only to find out it blows up anyway, for other reasons. :-) I still think the only safe way is to compile impgen.c entirely outside the scope of a project build. The problems I've been having occur even if impgen is compiled first thing when the project's configure.in is executed, if I'm cross compiling. That brings up another interesting point: If impgen was to be compiled when installing libtool, wouldn't that result in the same problem? I mean, impgen should only build when you're installing libtool for a cross compiler - and then you're in that darn cross compiler environment again! *heh* How would one get around that? //David Olofson --- Programmer, Reologica Instruments AB .- Coming soon from VaporWare Inc.... | The Return of Audiality! Real, working software. Really! | | Real time and off-line synthesis, scripting, MIDI, LGPL...| `---> (Public Release RSN) -' .- M A I A -. |The Multimedia Application Integration Architecture| `> http://www.linuxdj.com/maia -' .- David Olofson ---. | Audio Hacker - Open Source Advocate - Singer - Songwriter | `-> http://olofson.net -' ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: [Mingw-users] Re: libbfd, libtool & Win32
David Olofson wrote: > > However, it's still a very bad idea to compile tools as part of the > application build process. ;-) > Right, if you want to install implib as part of distributable resource when target == some win32 platform (Cygwin, MinGW, MSVC, etc.) fine, but don't create it in every .libs/ directory. Earnie. ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: [Mingw-users] Re: libbfd, libtool & Win32
On Monday 23 September 2002 13:00, David Olofson wrote: > On Friday 20 September 2002 22:31, Guido Draheim wrote: [...] > > In > > fact, we have a set of function names for a given lib - in its > > symbol table. > > In an export table, I would say, as most clean Win32 DLLs don't export > symbols at all... Can't rely on symbol tables, that is. (And either > way, it now seems that these tables only tell us what to look for; not > how to use it... :-/ ) Oh, and I'm still wondering whether or not 'objdump -syms' should dump the *exports* when used on Win32 DLLs. :-) //David Olofson --- Programmer, Reologica Instruments AB .- Coming soon from VaporWare Inc.... | The Return of Audiality! Real, working software. Really! | | Real time and off-line synthesis, scripting, MIDI, LGPL...| `---> (Public Release RSN) -' .- M A I A -. |The Multimedia Application Integration Architecture| `> http://www.linuxdj.com/maia -' .- David Olofson ---. | Audio Hacker - Open Source Advocate - Singer - Songwriter | `-> http://olofson.net -' ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: [Mingw-users] Re: libbfd, libtool & Win32
On Friday 20 September 2002 22:31, Guido Draheim wrote: > David Olofson wrote: [...] > > How about building import libs from headers? (You need the headers to > > compile anyway...) > > Ahhm, not quite - some functions are exported only on a case-by-case > basis, and there are quite some different ways to get at the CFLAGS > needed for that. And you can play some catchme with distributing > functions across a number of headers and a number of libraries. Yeah, but of course, you'll have to make sure that whatever digs that info out sees the *exact* same world as the linker - which seems to suggest (to me at least) that this is definitely a job for ld. It's the only tool in the chain that normally sees both the information generated by the compiler (which in turn contains the data we need, extracted from the headers that belong to the DLLs), and the actual DLLs. > In > fact, we have a set of function names for a given lib - in its > symbol table. In an export table, I would say, as most clean Win32 DLLs don't export symbols at all... Can't rely on symbol tables, that is. (And either way, it now seems that these tables only tell us what to look for; not how to use it... :-/ ) > >>You also need to consider DATA symbols, > >>and the special tricks required to import data, particularly arrays > >>and structs, using --enable-auto--import. The extensions to > >>--enable-auto-import for arrays and structs (Egor Duda's work ) > >>require both binutils support (a modified linker script, for a start) > >>and runtime support (in the pipe for cygwin, not for mingw) > > > > Ouch. > > > > Well, as far as my projects are concerned, I consider exporting > > anything but functions non-portable, and usually a bad idea for other > > reasons. Would be nice if it could be made to work somehow, but I > > probably won't make use of that feature myself. > > Just my point. It's nice that cygwin wants to emulate the unix > behaviour to a degree that even data-symbols are im/exported in the > usual manner, that's different with mingw-software where I do take the > burden to make it ready to run in crippled environment, just to make it > more "native". That's the whole point of it anyway... and therefore, > making software windows-ready means to look for the difference in > datasymbol export (and to not use them, actually). I won't make use of > that cygwin feature since I know of problems with compiling the dll > sources with msvc and borland and watcom - and I am quite sure they > don't have the same scheme of wrapping the unixish stuff in DLLs, like > exported data symbols. Right. Either we emulate Un*x on Win32, or we have our tools support "official" Win32 features only. The latter seems more sane to me. If you want Un*x, you don't run Windows, IMHO. If you want portability, you don't develop for Un*x, but rather for an imaginary environment with a feature set that's available on all platforms you're interested in. However, it's still a very bad idea to compile tools as part of the application build process. ;-) //David Olofson --- Programmer, Reologica Instruments AB .- Coming soon from VaporWare Inc.... | The Return of Audiality! Real, working software. Really! | | Real time and off-line synthesis, scripting, MIDI, LGPL...| `---> (Public Release RSN) -' .- M A I A -. |The Multimedia Application Integration Architecture| `> http://www.linuxdj.com/maia -' .- David Olofson ---. | Audio Hacker - Open Source Advocate - Singer - Songwriter | `-> http://olofson.net -' ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: [Mingw-users] Re: libbfd, libtool & Win32
Guido Draheim wrote: > > Just my point. It's nice that cygwin wants to emulate the unix behaviour > to a degree that even data-symbols are im/exported in the usual manner, > that's different with mingw-software where I do take the burden to make > it ready to run in crippled environment, just to make it more "native". > That's the whole point of it anyway... and therefore, making software > windows-ready means to look for the difference in datasymbol export (and > to not use them, actually). I won't make use of that cygwin feature > since I know of problems with compiling the dll sources with msvc and > borland and watcom - and I am quite sure they don't have the same scheme > of wrapping the unixish stuff in DLLs, like exported data symbols. > Hmm... Well, the gcc source is the same for both Cygwin and MinGW, AFAIK, at least that's what I get out of Danny Smith and Chris Faylor posts. So, what works for Cygwin should work for MinGW. Now, interoperation between MSVC, Watcom, Borland, etc, and GCC; is it doable, and if doable, is it worth it? Earnie. ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: [Mingw-users] Re: libbfd, libtool & Win32
David Olofson wrote: > On Wednesday 18 September 2002 22:37, Danny Smith wrote: > [...] > > >>>or does that mean we >>>either have to make assumptions, or just *require* import libs to be >>>present? >> >>The latter is certainly safer. > > > Yeah, but it doesn't work if you can't get an import lib that works with > your compiler... that's the stateofart in the windows world - if you have another compiler that the given importlib is not compatible with then you will be forced to run implib.exe in a seperate step. That's what our impgen is all about - doing that automatically since unix software does not need such bu**s**t of compiler-specific importlibs. > > How about building import libs from headers? (You need the headers to > compile anyway...) Ahhm, not quite - some functions are exported only on a case-by-case basis, and there are quite some different ways to get at the CFLAGS needed for that. And you can play some catchme with distributing functions across a number of headers and a number of libraries. In fact, we have a set of function names for a given lib - in its symbol table. > > > >>You also need to consider DATA symbols, >>and the special tricks required to import data, particularly arrays >>and structs, using --enable-auto--import. The extensions to >>--enable-auto-import for arrays and structs (Egor Duda's work ) >>require both binutils support (a modified linker script, for a start) >>and runtime support (in the pipe for cygwin, not for mingw) > > > Ouch. > > Well, as far as my projects are concerned, I consider exporting anything > but functions non-portable, and usually a bad idea for other reasons. > Would be nice if it could be made to work somehow, but I probably won't > make use of that feature myself. > Just my point. It's nice that cygwin wants to emulate the unix behaviour to a degree that even data-symbols are im/exported in the usual manner, that's different with mingw-software where I do take the burden to make it ready to run in crippled environment, just to make it more "native". That's the whole point of it anyway... and therefore, making software windows-ready means to look for the difference in datasymbol export (and to not use them, actually). I won't make use of that cygwin feature since I know of problems with compiling the dll sources with msvc and borland and watcom - and I am quite sure they don't have the same scheme of wrapping the unixish stuff in DLLs, like exported data symbols. ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: [Mingw-users] Re: libbfd, libtool & Win32
On Wednesday 18 September 2002 22:37, Danny Smith wrote: [...] > > > All the names should have stdcall decoration, but don't. > > > > Ok... Is that information at all available in a DLL, > > No. Ok. (Then I didn't miss it in the spec because of blindness...) > > or does that mean we > > either have to make assumptions, or just *require* import libs to be > > present? > > The latter is certainly safer. Yeah, but it doesn't work if you can't get an import lib that works with your compiler... How about building import libs from headers? (You need the headers to compile anyway...) > You also need to consider DATA symbols, > and the special tricks required to import data, particularly arrays > and structs, using --enable-auto--import. The extensions to > --enable-auto-import for arrays and structs (Egor Duda's work ) > require both binutils support (a modified linker script, for a start) > and runtime support (in the pipe for cygwin, not for mingw) Ouch. Well, as far as my projects are concerned, I consider exporting anything but functions non-portable, and usually a bad idea for other reasons. Would be nice if it could be made to work somehow, but I probably won't make use of that feature myself. //David Olofson --- Programmer, Reologica Instruments AB .- Coming soon from VaporWare Inc.... | The Return of Audiality! Real, working software. Really! | | Real time and off-line synthesis, scripting, MIDI, LGPL...| `---> (Public Release RSN) -' .- M A I A -. |The Multimedia Application Integration Architecture| `> http://www.linuxdj.com/maia -' .- David Olofson ---. | Audio Hacker - Open Source Advocate - Singer - Songwriter | `-> http://olofson.net -' ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: [Mingw-users] Re: libbfd, libtool & Win32
--- David Olofson <[EMAIL PROTECTED]> wrote: > On Wednesday 18 September 2002 12:29, Danny Smith wrote: > [...] > > > > A gotcha with this is that some exported names in dll are aliases, > > > > the prime culprit being stdcall names. > > > > > > Uh oh. Why would that be an issue with ld, if it isn't with > > > impgen.c...? > > > > It is an issue with impgen. Try: > > % impgen c:/winnt/system32/user32.dll > > > > All the names should have stdcall decoration, but don't. > > Ok... Is that information at all available in a DLL, No. or does that mean we > either have to make assumptions, or just *require* import libs to be > present? The latter is certainly safer. You also need to consider DATA symbols, and the special tricks required to import data, particularly arrays and structs, using --enable-auto--import. The extensions to --enable-auto-import for arrays and structs (Egor Duda's work ) require both binutils support (a modified linker script, for a start) and runtime support (in the pipe for cygwin, not for mingw) Danny > > > //David Olofson --- Programmer, Reologica Instruments AB > > .- M A I A -. > | Multimedia Application Integration Architecture | > | A Free/Open Source Plugin API for Professional Multimedia | > `> http://www.linuxdj.com/maia -' > .- David Olofson ---. > | Audio Hacker - Open Source Advocate - Singer - Songwriter | > `-> http://olofson.net -' > > > --- > This SF.NET email is sponsored by: AMD - Your access to the experts > on Hammer Technology! Open Source & Linux Developers, register now > for the AMD Developer Symposium. Code: EX8664 > http://www.developwithamd.com/developerlab > ___ > MinGW-users mailing list > [EMAIL PROTECTED] > > You may change your MinGW Account Options or unsubscribe at: > https://lists.sourceforge.net/lists/listinfo/mingw-users http://mobile.yahoo.com.au - Yahoo! Messenger for SMS - Always be connected to your Messenger Friends ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: [Mingw-users] Re: libbfd, libtool & Win32
On Wednesday 18 September 2002 12:29, Danny Smith wrote: [...] > > > A gotcha with this is that some exported names in dll are aliases, > > > the prime culprit being stdcall names. > > > > Uh oh. Why would that be an issue with ld, if it isn't with > > impgen.c...? > > It is an issue with impgen. Try: > % impgen c:/winnt/system32/user32.dll > > All the names should have stdcall decoration, but don't. Ok... Is that information at all available in a DLL, or does that mean we either have to make assumptions, or just *require* import libs to be present? //David Olofson --- Programmer, Reologica Instruments AB .- M A I A -. | Multimedia Application Integration Architecture | | A Free/Open Source Plugin API for Professional Multimedia | `> http://www.linuxdj.com/maia -' .- David Olofson ---. | Audio Hacker - Open Source Advocate - Singer - Songwriter | `-> http://olofson.net -' ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: [Mingw-users] Re: libbfd, libtool & Win32
--- David Olofson <[EMAIL PROTECTED]> wrote: > On Wednesday 18 September 2002 11:46, Danny Smith wrote: > > --- David Olofson <[EMAIL PROTECTED]> wrote: > On Tuesday 17 > > > > I'm a bit late catching up with this thread. No one has mentioned the > > code in ld/pe-dll.c, function pe_implied_import_dll (filename) which > > extract def file from dll. Is that what you are trying to do? > > Yes. Is that's the code that's engaged when having gcc link directly with > a DLL? Dunno' what the exact problem with that is, but it was suggested > that it would be a good idea not to rely on it entirely just yet. > It's pretty much the same code, but but uses bfd-isms (eg bfd_seek, bfd_bread) as wrappers for unistd.h/io.h functions > > > A gotcha with this is that some exported names in dll are aliases, the > > prime culprit being stdcall names. > > Uh oh. Why would that be an issue with ld, if it isn't with impgen.c...? > It is an issue with impgen. Try: % impgen c:/winnt/system32/user32.dll All the names should have stdcall decoration, but don't. Danny http://mobile.yahoo.com.au - Yahoo! Messenger for SMS - Always be connected to your Messenger Friends ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: [Mingw-users] Re: libbfd, libtool & Win32
On Wednesday 18 September 2002 11:46, Danny Smith wrote: > --- David Olofson <[EMAIL PROTECTED]> wrote: > On Tuesday 17 > > September 2002 20:33, Guido Draheim wrote: > > [...] > > > > > On another e-mail, you said to have some idea of the `objdump -p` > > > output of an export table. If someone could work that out with a > > > portable shell program (sh/sed/etc), then we can let that impgen.sh > > > be created in the $builddir instead of an impgen.exe, and have it > > > run through extract_expsyms_cmd. That would atleast fix our > > > crosscompile problem. > > > > That could work, but I'm not sure how much we can rely on the format > > of that output. Either way, it generates *a lot* of data that we need > > to throw away. Not a major issue, I guess, but it doesn't feel > > right... > > I'm a bit late catching up with this thread. No one has mentioned the > code in ld/pe-dll.c, function pe_implied_import_dll (filename) which > extract def file from dll. Is that what you are trying to do? Yes. Is that's the code that's engaged when having gcc link directly with a DLL? Dunno' what the exact problem with that is, but it was suggested that it would be a good idea not to rely on it entirely just yet. > A gotcha with this is that some exported names in dll are aliases, the > prime culprit being stdcall names. Uh oh. Why would that be an issue with ld, if it isn't with impgen.c...? //David Olofson --- Programmer, Reologica Instruments AB .- M A I A -. | Multimedia Application Integration Architecture | | A Free/Open Source Plugin API for Professional Multimedia | `> http://www.linuxdj.com/maia -' .- David Olofson ---. | Audio Hacker - Open Source Advocate - Singer - Songwriter | `-> http://olofson.net -' ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: [Mingw-users] Re: libbfd, libtool & Win32
--- David Olofson <[EMAIL PROTECTED]> wrote: > On Tuesday 17 September 2002 20:33, Guido Draheim wrote: > [...] > > On another e-mail, you said to have some idea of the `objdump -p` > > output of an export table. If someone could work that out with a > > portable shell program (sh/sed/etc), then we can let that impgen.sh be > > created in the $builddir instead of an impgen.exe, and have it run > > through extract_expsyms_cmd. That would atleast fix our crosscompile > > problem. > > That could work, but I'm not sure how much we can rely on the format of > that output. Either way, it generates *a lot* of data that we need to > throw away. Not a major issue, I guess, but it doesn't feel right... > I'm a bit late catching up with this thread. No one has mentioned the code in ld/pe-dll.c, function pe_implied_import_dll (filename) which extract def file from dll. Is that what you are trying to do? A gotcha with this is that some exported names in dll are aliases, the prime culprit being stdcall names. Danny http://mobile.yahoo.com.au - Yahoo! Messenger for SMS - Always be connected to your Messenger Friends ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: [Mingw-users] Re: libbfd, libtool & Win32
On Wednesday 18 September 2002 11:08, David Olofson wrote:
[...]
> Indeed, it seems that the export section is *not* really a symbol
> table, which is why some DLLs can have symbols ('-syms'), while most
> DLLs don't. (In fact, I think clean DLLs *shouldn't* have the kind of
> symbol table that 'objdump -syms' would print.)
On second thoughts, what's the point in having 'objdump -syms' output
what seems to be useless garbage in a native PE environment...? Shouldn't
'objdump -syms' just output all imports (and exports?), because *that's*
what a PE loader actually sees as "symbols"...?
Or rather, what's the '-syms' option *really* meant to do, on say, an ELF
system?
//David Olofson --- Programmer, Reologica Instruments AB
.- M A I A -.
| Multimedia Application Integration Architecture |
| A Free/Open Source Plugin API for Professional Multimedia |
`> http://www.linuxdj.com/maia -'
.- David Olofson ---.
| Audio Hacker - Open Source Advocate - Singer - Songwriter |
`-> http://olofson.net -'
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
Re: [Mingw-users] Re: libbfd, libtool & Win32
On Tuesday 17 September 2002 20:33, Guido Draheim wrote:
[...]
> On another e-mail, you said to have some idea of the `objdump -p`
> output of an export table. If someone could work that out with a
> portable shell program (sh/sed/etc), then we can let that impgen.sh be
> created in the $builddir instead of an impgen.exe, and have it run
> through extract_expsyms_cmd. That would atleast fix our crosscompile
> problem.
That could work, but I'm not sure how much we can rely on the format of
that output. Either way, it generates *a lot* of data that we need to
throw away. Not a major issue, I guess, but it doesn't feel right...
> Still, I think that the correct solution is in the objdump
> itself, giving it another option to spit out the export table in .def
> style format.
Would that be "Win32 DLL .def format", or some GNU standard format?
(Seems like other platforms have different formats for their .def
files...)
Anyway, I looked into that yesterday.
Good news:
There is code in libbfd that can find and parse
the exports (".edata") section of a Win32 DLL.
Bad news:
objdump does this when you specify '-p':
static void
dump_bfd_private_header (abfd)
bfd *abfd;
{
bfd_print_private_bfd_data (abfd, stdout);
}
And yes, it's just as bad as it looks; the PE/pei implementation of
bfd_print_private_bfd_data() is just a big function that, among other
things, calls a static function that parses and prints out the export
table... That code cannot be reached in any other way through the libbfd
API. It's all or nothing, and it's all hardcoded.
Indeed, it seems that the export section is *not* really a symbol table,
which is why some DLLs can have symbols ('-syms'), while most DLLs don't.
(In fact, I think clean DLLs *shouldn't* have the kind of symbol table
that 'objdump -syms' would print.)
So, there appears to be no clean way of getting at this information by
hacking objdump. I might be missing something, but I've found no trace of
export table parsing anywhere else in the pei code of libbfd, so I have
to conclude that libbfd must be hacked as well.
I could do that, but I'd need guidelines from the binutils folks, as I
can't seem to figure out where such a feature should go, with respect to
the BFD API.
Another way would be to do what that private data printing function does,
but inside objdump (libbfd supports messing with raw section data...),
but to me at least, that makes throwing impgen into binutils look like a
good idea...
> Looking at that later thing I'd say that I could even
> live with a quickhack of a impgen.sh that works for most projects, and
> those projects with trickier stuff must upgrade their binutils to a
> recent version. How does that sound?
That could work. Dunno' about the reliability or portability of fitering
'objdump -p' output, but if it works for most people for now, it can at
least avoid strictly forcing every cross gcc'er to upgrade.
//David Olofson --- Programmer, Reologica Instruments AB
.- M A I A -.
| Multimedia Application Integration Architecture |
| A Free/Open Source Plugin API for Professional Multimedia |
`> http://www.linuxdj.com/maia -'
.- David Olofson ---.
| Audio Hacker - Open Source Advocate - Singer - Songwriter |
`-> http://olofson.net -'
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
Re: [Mingw-users] Re: libbfd, libtool & Win32
David Olofson wrote:
> On Tuesday 17 September 2002 13:05, Max Bowsher wrote:
> [...]
>
>>I think the correct approach is to use a libfoo.dll.a if it is present,
>
>
> Agreed.
it should be ATM.
>
>
>
>>and do funny impgen stuff if it is not.
>
>
> Just not as funny as the current approach. This "compile at library build
> time using HOST_CC" must *really* die, IMO.
>
> For some strange reason, I managed to get libtool to use the right CC,
> but that didn't help, as gcc sent incorrect flags to as. Still don't know
> why this happens.
>
> For now, I've compiled and installed impgen manually, and hacked
> libtool.m4 to just run it. Works great.
see below...
>
> Somehow, I can't see why having:
>
> 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'
>
>
> (sorry 'bout the wrapping...) in libtool.m4, when you could build impgen
> during the installation, and then use something like:
>
> extract_expsyms_cmds='impgen $dir/$soroot >$output_objdir/$soname-def'
>
>
> Right, it's not a great idea to fix something the wrong way - but then
> again, we're talking about something that's *really* broken, inconcistent
> (any one else cares about HOST_CC...?), and a major PITA for a great
> number of users. (I might be the first, but even the established
> workarounds failed on my setup...)
>
> And now I'm not even sure if anyone knows what the correct solution would
> be... What now?
>
>
On another e-mail, you said to have some idea of the `objdump -p` output
of an export table. If someone could work that out with a portable shell
program (sh/sed/etc), then we can let that impgen.sh be created in the
$builddir instead of an impgen.exe, and have it run through extract_expsyms_cmd.
That would atleast fix our crosscompile problem. Still, I think that the
correct solution is in the objdump itself, giving it another option to
spit out the export table in .def style format. Looking at that later thing
I'd say that I could even live with a quickhack of a impgen.sh that works
for most projects, and those projects with trickier stuff must upgrade their
binutils to a recent version. How does that sound?
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
Re: [Mingw-users] Re: libbfd, libtool & Win32
Max Bowsher wrote: > Earnie Boyd wrote: > >>Guido Draheim wrote: >> >>>hmm, perhaps, the LD can now link with dlls directly, and that should >> >>Yes, indeed it can, and will search for it in the LIBRARY_PATH. If it >>can't find libfoo.dll.a or libfoo.a it will look for libfoo.dll when >>-lfoo is given. > > > Unfortunately, libtool doesn't know about this (I don't think), and will not > pass -l options to the compiler, preferring to resolve them to files itself. > which can be changed... and should be when known that the compiler will handle all the linking steps alone. But... (next post)... ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: [Mingw-users] Re: libbfd, libtool & Win32
On Tuesday 17 September 2002 13:05, Max Bowsher wrote:
[...]
> I think the correct approach is to use a libfoo.dll.a if it is present,
Agreed.
> and do funny impgen stuff if it is not.
Just not as funny as the current approach. This "compile at library build
time using HOST_CC" must *really* die, IMO.
For some strange reason, I managed to get libtool to use the right CC,
but that didn't help, as gcc sent incorrect flags to as. Still don't know
why this happens.
For now, I've compiled and installed impgen manually, and hacked
libtool.m4 to just run it. Works great.
Somehow, I can't see why having:
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'
(sorry 'bout the wrapping...) in libtool.m4, when you could build impgen
during the installation, and then use something like:
extract_expsyms_cmds='impgen $dir/$soroot >$output_objdir/$soname-def'
Right, it's not a great idea to fix something the wrong way - but then
again, we're talking about something that's *really* broken, inconcistent
(any one else cares about HOST_CC...?), and a major PITA for a great
number of users. (I might be the first, but even the established
workarounds failed on my setup...)
And now I'm not even sure if anyone knows what the correct solution would
be... What now?
//David Olofson --- Programmer, Reologica Instruments AB
.- M A I A -.
| Multimedia Application Integration Architecture |
| A Free/Open Source Plugin API for Professional Multimedia |
`> http://www.linuxdj.com/maia -'
.- David Olofson ---.
| Audio Hacker - Open Source Advocate - Singer - Songwriter |
`-> http://olofson.net -'
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
Re: [Mingw-users] Re: libbfd, libtool & Win32
Earnie Boyd wrote: > Guido Draheim wrote: > > hmm, perhaps, the LD can now link with dlls directly, and that should > > Yes, indeed it can, and will search for it in the LIBRARY_PATH. If it > can't find libfoo.dll.a or libfoo.a it will look for libfoo.dll when > -lfoo is given. Unfortunately, libtool doesn't know about this (I don't think), and will not pass -l options to the compiler, preferring to resolve them to files itself. Max. ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: [Mingw-users] Re: libbfd, libtool & Win32
Guido Draheim wrote:
> I am not that knowing about the actual backgrounds, but to me
> it did look as if one can not be sure about the dll.a format,
> so that one does not trust it. Unlike cygwin, it is much more
> likely that mingw binds with dlls *not* compiled by mingw gcc
> but from another compiler. Since mingw is on the same
> augenhoehe ("eye height", here: being-level) other than cygwin's
> posixisch environment which is another layer atop the basic
> operating system services. And damn, we want to bind with
> other dlls for which we have no dll.a available. About all the
> other win32 compilers come with some kind of implib.exe that
> one can use to make an importlib from any dll that was not
> shipped along with that compiler. That is, in another step,
> before linking. That's not the gcc/unix way I say, where we
> are even used that LD link lines look always somewhat like
> -L. -lz, other than the plethora of w32 compilers, IIRC.
>
> Personally, I do not have a problem with having libtool to do
> some automatics, to call some implib.exe if the importlib
> is not availabe - or when one does not trust that the imp.lib
> is up to date with the lib in parallel that (the dll versioning
> scheme is not quite like that one unix systems, and dlls get
> often replaced, while unix sharedlibs are not and get a cousin
> in parallel). Anyway, for having libtool to do some automatics
> successfully... there has to be an implib.exe-like step that
> can be done and trusted.
I think the correct approach is to use a libfoo.dll.a if it is present, and do
funny impgen stuff if it is not.
Max.
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
