Re: dll cross-compile, .libs/impgen is a win-exe, not a linux-binary
On Wed, Jun 20, 2001 at 03:23:18AM +0200, Guido Draheim wrote: > What is HOST_CC ? It has no default, and cross-gcc is the wrong cc. It's meant to point to a native compiler in precisely this situation to solve the problem of impgen getting cross-compiled and so being useless. > Did now try with HOST_CC=/usr/bin/cc to get a working impgen. > Did not work either - look for the ".libs/.libs" part in the > output which is clearly wrong. The HOST_CC patch was from me, and it worked when applied. Looks like something has changed since and stopped it working. > HOST_CC is only used with impgen, no other reference. IIRC, there > are plans to have more binary compile-tools, which leasd to the > question whether there are plans for automatic support of HOST_CC > (whatever that is anyway) HOST_CC is also refered to in config.status, and apparently comes from gcc's bootstrapping process. The name CC_FOR_BUILD is preferable - see the discussion stemming from the first url below - perhaps libtool ought to change to this? I did also produce an autoconf macro for probing for HOST_CC. Ideally this should be triggered automatically by AM_PROG_LIBTOOL when cross-compiling to windows is detected, but I don't think it got incorporated into libtool or autoconf (it's actually of general use for compiling build-time tools when cross-compiling). You can find the macro here: http://sources.redhat.com/ml/autoconf/1999-07/msg00089.html There's also an entirely different macro for testing CC_FOR_BUILD here: http://www.gnu.org/software/ac-archive/Cross_Compilation/ac_prog_cc_for_build.html This one sets CFLAGS_FOR_BUILD, etc but seems to rely on the user setting CC_FOR_BUILD whereas mine actually has a reasonable stab at find a native compiler by itself. Cheers, Olly ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: dll cross-compile, .libs/impgen is a win-exe, not a linux-binary
moin moin, Olly, Olly Betts wrote: > > On Wed, Jun 20, 2001 at 03:23:18AM +0200, Guido Draheim wrote: > > What is HOST_CC ? It has no default, and cross-gcc is the wrong cc. > > It's meant to point to a native compiler in precisely this situation to > solve the problem of impgen getting cross-compiled and so being useless. Yep, that was my guess, but it looked a bit stranded as there's nothing else around that knows who he is... > > > Did now try with HOST_CC=/usr/bin/cc to get a working impgen. > > Did not work either - look for the ".libs/.libs" part in the > > output which is clearly wrong. > > The HOST_CC patch was from me, and it worked when applied. Looks like > something has changed since and stopped it working. *sigh*, okay then, I'll see if I can catch enough of the scheme to fix that too. > > > HOST_CC is only used with impgen, no other reference. IIRC, there > > are plans to have more binary compile-tools, which leasd to the > > question whether there are plans for automatic support of HOST_CC > > (whatever that is anyway) > > HOST_CC is also refered to in config.status, and apparently comes from gcc's > bootstrapping process. The name CC_FOR_BUILD is preferable - see the > discussion stemming from the first url below - perhaps libtool ought to > change to this? Just as you noted in your post, one will usually try to get away with some "interesting" shell/sed/awk-macros, and it seems that we were pretty much able to do that up to now. Especially most of the dll import/export stuff is done with tricky productions on objdump output, and otherwise it has somehow gotten to be integrated in the famous "dlltool" - and just as PavelRoskin has stated back then, it is allowed to simply `require` (pre-)existance of a fairly uptodate dlltool/dllwrap pair that knows a "dlltool --impgen" mode. Have ye talked to those guys, Olly? > > I did also produce an autoconf macro for probing for HOST_CC. Ideally this > should be triggered automatically by AM_PROG_LIBTOOL when cross-compiling to > windows is detected, but I don't think it got incorporated into libtool or > autoconf (it's actually of general use for compiling build-time tools when > cross-compiling). > > You can find the macro here: > > http://sources.redhat.com/ml/autoconf/1999-07/msg00089.html Thanks for the reference, a nice thread on the topic, and easy macro too. > > There's also an entirely different macro for testing CC_FOR_BUILD here: > > http://www.gnu.org/software/ac-archive/Cross_Compilation/ac_prog_cc_for_build.html > > This one sets CFLAGS_FOR_BUILD, etc but seems to rely on the user setting > CC_FOR_BUILD whereas mine actually has a reasonable stab at find a native > compiler by itself. > wooohohowow, this is tricky stuff for an ac-macro, now I know why TomTromey did mention a generic push/pop-compiler ac-operation back then. This does even more push me to say, that the impgen-rule should better get integrated into dlltool/dllwrap, - and barf out at anyone who does not have an uptodate version of it. Anyway, libtool.m4 and libtool-content are out of sync in this case, it is clearly buggy, don't you think Gary? ;-) cheers, -- guido Edel sei der Mensch, hilfreich und gut 31:GCS/E/S/P C++$ ULHS L++w- N++@ d(+-) s+a- h.r(*@)>+++ y++ 5++X- ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
spec-files ?
hi, could anyone write an specfile for libtool ? ~-n _ meTUX IT + Communication Services Enrico Weigelt www: www.metux.de email: [EMAIL PROTECTED] phone: +49 36207 51833 cellphone: +49 174 7066481 _ ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: dll cross-compile, .libs/impgen is a win-exe, not a linux-binary
On Wednesday 20 June 2001 10:58 am, Guido Draheim wrote: > > Anyway, libtool.m4 and libtool-content are out of sync in this case, > it is clearly buggy, don't you think Gary? ;-) The last time I used the impgen code in libtool, it worked fine for me. However, I must admit that I didn't test cygwin builds at all for release 1.4, and had planned a quick 1.4.1 release if I subsequently found any problems. As you probably know, the MLB merge is taking most of my attention at the moment, though I will happily add any patches to the queue if you find a solution. The twisty turny code for cygwin was written back in the days of b19, and patched to continue working as new cygwin releases came along. After DJ Delorie's linker patches made it into cygwin-1.0 (IIRC) I tried to remove the whole impgen gubbins from libtool, but got flamed by people who needed libtool to continue working with b19. Thanks to Paul Sokolovsky's new ld patches, we no longer need the majority of libtool's Windows hacks -- so at some point in the not-too-distant future I plan to remove the current mess in favour of Robert Collins' streamlined version. People who like the beta era of Cygwin can continue to use libtool-1.3.5. Cheers, Gary. -- ())_. Gary V. Vaughan gary@(oranda.demon.co.uk|gnu.org) ( '/ Research Scientist http://www.oranda.demon.co.uk,_()) / )= GNU Hacker http://www.gnu.org/software/libtool \' `& `(_~)_ Tech' Authorhttp://sources.redhat.com/autobook=`---d__/ ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: dll cross-compile, .libs/impgen is a win-exe, not a linux-binary
"Gary V. Vaughan" wrote: > > On Wednesday 20 June 2001 10:58 am, Guido Draheim wrote: > > > > Anyway, libtool.m4 and libtool-content are out of sync in this case, > > it is clearly buggy, don't you think Gary? ;-) > > The last time I used the impgen code in libtool, it worked fine for me. > However, I must admit that I didn't test cygwin builds at all for release > 1.4, and had planned a quick 1.4.1 release if I subsequently found any > problems. As you probably know, the MLB merge is taking most of my attention > at the moment, though I will happily add any patches to the queue if you find > a solution. Hmm, I am currently in the last series of debugging rounds, atleast everything compiles now easily - the problem with the doubled ".libs/.libs" was due the fact that I said "-Lwhatever/.libs" to get to the relevant libraries, but the current libtool adds $objdir blindly. I am not sure how to fix that as it would require a more global view why it was assumed to add .libs just the blind way. uuuhhhm The other thing is about impgen.c itself - well, I did patch the libtool so that it will first try a "$DLLTOOL --export-def " in the generation line for the implib-deffile. Yep, there is no such dlltool-option but actually I made it to exist - just renamed the original dlltool to some dlltool-main, and wrote a wrapper-script that will detect the call as mode="--export-def", and it will then call an installed version of dlltool-impgen - yes, the compiled one from impgen.c. And so, basically, impgen gets required to be pre-installed in the development environment ;-) BTW, my dlltool --version speaks 19990818, so I have to check where dlltool is maintained, and if the impgen code is supported already, and if not, hmm, hey it's time for another patch-round, isn't it 8-) So to sum it up, I raise my hand to move this kind of code out of libtool and into dlltool, and that's it. I'll cc you on the progress in that matter, let's see what there comes of it... A side note, I am suspicous about that implib-generation was not upated when the actual library at the other side did change, has anyone thought about creating a makefile-snippet for some dll-specials to remake their objects? Or just go again, updating the implib? I am not sure - probably the current script can not know if the local implib is generated from a local makefile, so may be we should add a check that some linked implib is generated via impgen and should be remade on each link-call that has it as a -l-reference. But don't ask me how to make a patch for that one, hm cheers, -- guido http://guidod.4t.com P.S. :OT here: if you're interested in patches, well, I'd like to talk to the guy that invented the mac-os-x support - it doesn't have mach'dylib support but does some elf'so magic, and even that did not work without the patch that I sent you for reference... ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: dll cross-compile, .libs/impgen is a win-exe, not a linux-binary
On Jun 20, 2001, Olly Betts <[EMAIL PROTECTED]> wrote:
> The name CC_FOR_BUILD is preferable - see the discussion stemming
> from the first url below - perhaps libtool ought to change to this?
I'd approve any reasonable patch that fixed this :-)
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicampoliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist*Please* write to mailing lists, not to me
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
Re: spec-files ?
On Jun 20, 2001, Enrico Weigelt <[EMAIL PROTECTED]> wrote:
> could anyone write an specfile for libtool ?
Sure. In fact, a number of people already did. Just pick your
preferred RPM-based GNU/Linux distribution and get the spec file from
the libtool source RPM package.
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicampoliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist*Please* write to mailing lists, not to me
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
