Re: impgen.c again / Re: Linux/Win32 cross and DLLs

[David Olofson]

On Monday 16 September 2002 12:54, Guido Draheim wrote:
> http://ac-archive.SF.net/Installed_Packages/patch_libtool_to_add_host_c
>c.html

Tried that (as well as other approaches to do the same thing), but it 
just results in the same situation that I can now get without it; the 
right gcc is used, but it passes System V specific bogus flags to as.

It seems to me that setting up the path for the cross compiler screws 
things up for the native compiler. Maybe the wrapper scripts I'm using 
are incorrect? (They came from a rather old cross compiler setup, I 
think...)


> This thing is unresolved for years. A number of people did try to get
> someone with with DLL-mana to fix it, and there are dozens and dozens
> of mails to libtool-ML to be found around this problem, please
> check the mailinglist-archives (again) for the details.

Found some, but no explanation to what I'm seeing... (The "works with 
other libs" part, mostly. I can probably sort things out to actually 
build DLLs, but I got the impression that it should "Just Work(TM)" if I 
set things up like other, similar packages do.)

Anyway, I'll restrict google to your domain and see if I can find what 
I'm looking for.


> Sorry, 'I don't
> have much time at the moment, but -no-undefined is definitly not the
> problem,

I know - it just happens to clearly demonstrate that it's all about 
importing symbols from another DLL. (Which we all knew anyway, I guess.)


> the real cause is that your CC is a crosscompiler, and
> impgen.c gets compiled on the fly and executed immediatly to create an
> importlib from a DLL found in the sytem, but that does not work of
> course since the CC did create a impgen.exe. Add the above macro to
> your conigure.ac, and see that impgen.c will be compiled with HOST_CC
> instead of CC.

I know - but that didn't fix it. I still can't keep the native gcc from 
passing a '-Qy' (IIRC) flag to as... (Tried setting ASFLAGS to "", as 
seen in some lib's configure.in, but that didn't change anything.)

Also, I still can't figure out why other libraries cross compile into 
DLLs just fine... They don't patch libtool, and in fact, they don't seem 
to be using libimp at all, and thus avoid the cross compiler problem with 
that.

I'll have a closer look at my cross compiler setup, though... Seems to me 
that libimp *should* be used (whenever you can't scan the library 
headers...?), and that the issue is about getting it to work with cross 
compilers.


> And yes, the name is a bit misleading, it's just many
> years old, and why should one fix something that is wrong in the first
> place. There should be an implib helper along dlltool, i.e.
> preinstalled in the build environment,

Yeah...

Am I missing something when I think that this is basically about having 
the libtool build/install scripts compiling libimp.c as a native tool, 
configured for the desired target platform? (I mean, that's basically 
what is done - only it's done at the wrong time, possibly with the wrong 
compiler and environment, and not installed... Right?)


> it should not be compiled on the
> fly anyway, so the whole stuff of buildcc .vs. crossgcc is bad bad bad
> anyway. You have some 30 hours time to spare for communications and
> e-mails? I'd love to get someone again to try to fix the situation...

Well, I've wasted more than that already, trying to sort it out...

OTOH, I hardly know enough about shell scripting, m4 and autotools to 
hack basic tests and stuff. (C, low level, real time and audio/video is 
my sort of stuff, really.)

Either way, if I can get some sort of "overview" of the intended proper 
design, I might as well give it a try. Seems like I'll have to mess with 
this a great deal anyway, so I might as well try to spend the time doing 
something worthwile, rather than yet another kludge.


> (btw, where's the crossgcc faq gone? I crafted it, it was planned to
> show up on mingw.org and I posted it to the sdl-mailinglist a number
> of the times.. hmm... may be these thing get forgotten too quickly...)

Well, if there is one, I've managed to miss it... :-)


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