[Top][All Lists]

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

Re: MSVC Support

From: Ralf Wildenhues
Subject: Re: MSVC Support
Date: Mon, 22 May 2006 09:33:34 +0200
User-agent: Mutt/1.5.11

* Brendon Costa wrote on Mon, May 22, 2006 at 08:52:10AM CEST:
> > Surely that is very helpful.  Is there a reason you're not contributing
> > them to cccl though? 

> The wrappers I have created work well enough for me in some regards,
> they are just small modifications to the original cccl wrapper plus
> wrappers for a few other things like lib.exe
> I will look at contributing them to cccl if I get somewhere with them
> and find them useful, though the state they are in at the moment is
> just a "testing/development" state which I don't think people would
> yet be interested in.
> I have to find some time to look into it further, but currently the
> libltdl configure script fails when using the wrappers.

Please post the output so we can see how it fails.  (Even if you fix it
yourself; it helps to re-recognize something as the same issue when it
happens again, in a couple of years.)

> I will try to have a look at the patch later on tonight (If I get some
> time after work). If it is just regressions that need to be tested and
> there is an appropriate set of tests then I can run it on Windows
> using MSVC, and MinGW and on NetBSD and Linux using GCC, but I am
> unable to test any other platforms which are probably the ones that
> really need to be tested.

It's regressions that need to be fixed.  Also, the code does need a
cleanup.  So really it can't go in the way it is there.

> > If OTOH your wrappers are good enough to wrap all libtool-needed
> > functionality in a way such that it looks like GCC, well, then Libtool
> > may just work out of the box with it.  :-)
> > But that would be a lot of work to put in such a wrapper, seriously.
> > 
> I don't know how feasible it will be to have libtool work with these
> wrappers straight out of the box.

Completely: no.  Simply because MSVC doesn't have the magic auto import
"feature" that GCC does.

> But currently I am able to use
> libtool to successfully create static libraries and applications that
> use those static libraries without any mods.

Well, that's good to hear.

> I noticed that the libtool script has a few variables like AR, CC, LD,
>  objext, libext ... Is there any way to provide those on the command
> line, or am I best for now just to edit those in the libtool script
> directly?

With a libtoolized package, it should work to
  ./configure AR=ar CC=cc LD=...

but Libtool may munge with $LD (e.g., add -m elf_x86_64).

> Also what does libtool use the following variables variables for:
>       nm
>       strip
>       file
>       dlltool
>       objdump
>       as

> Does it actually make use of these programs and would I need to wrap
> them as well to get libtool to work with wrappers alone? If so i think
> there may be a better way of doing this :-)

Peter has added support for the LIB resp. "LINK -lib" and the DUMPBIN
commands, at least (a good part of Peter's work has already been applied
to CVS Libtool, the patch pointed out is the remaining work).  So no,
there is no need to cater for nm, ar, unless you want to do so for
purposes unrelated to Libtool.  I don't think $AS and $DLLTOOL are
currently used in Libtool, their declaration is provided for backward
compatibility.  "objdump" may serve func_win32_libid (in ltmain) to
detect the library type, also "file".  It's probably a good long-term
idea to make that work better when these are not present.

Hope that helps.


reply via email to

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