Re: MSVC Support

[Brendon Costa]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

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

Well i downloaded the patch, and did a checkout of libtool from CVS as
of the date: 2005/11/19 (Which from what i could tell was close to the
date of the CVS workspace from which the patch was created). However as
it stands that checkout of libtool from CVS does not compile even before
i apply the patch and any date after that point in time the patch fails
to apply. So for the moment i have given up on that path. Anyhow I have
also checked out the latests CVS (HEAD) of libtool and it seems from a
cursory glance that things are very different between the two versions
anyway.


After getting libtool working correctly with MinGW, i logged all the
output commands that libtool was making, and realized that writing a
wrapper script for gcc will not be feasible (Most features are easy but
some would require changing libtool anyway). In particular there was one
command used for making a DLOpened module where the gcc command line
looked like:


g++ -shared -nostdlib /mingw/lib/dllcrt2.o
C:/MinGW/bin/../lib/gcc/mingw32/3.4.2/crtbegin.o
c:/dev/BJC_old2/System/build/BJC_temp/src/plugins/LTDLOpened/.libs/LTDLOpened.o
- -LC:/MinGW/bin/../lib/gcc/mingw32/3.4.2 -LC:/MinGW/bin/../lib/gcc
- -L/mingw/lib/gcc/mingw32/3.4.2
- -LC:/MinGW/bin/../lib/gcc/mingw32/3.4.2/../../../../mingw32/lib
- -L/mingw/lib/gcc/mingw32/3.4.2/../../../../mingw32/lib -L/mingw/lib
- -LC:/MinGW/bin/../lib/gcc/mingw32/3.4.2/../../..
- -L/mingw/lib/gcc/mingw32/3.4.2/../../.. -lstdc++ -lmingw32 -lgcc
- -lmoldname -lmingwex -lmsvcrt -luser32 -lkernel32 -ladvapi32 -lshell32
- -lmingw32 -lgcc -lmoldname -lmingwex -lmsvcrt
C:/MinGW/bin/../lib/gcc/mingw32/3.4.2/crtend.o -o
c:/dev/BJC_old2/System/build/BJC_temp/src/plugins/LTDLOpened/.libs/LTDLOpened-0.dll
- -Wl,--enable-auto-image-base -Xlinker --out-implib -Xlinker
c:/dev/BJC_old2/System/build/BJC_temp/src/plugins/LTDLOpened/.libs/LTDLOpened.dll.a


A number of the options specified in that command seem to be MinGW
specific, i.e. dllcrt2.o, crtbegin.o crtend.o mingwex etc. With the
exception of this particular command, i think the wrappers could convert
all other commands that were emitted by libtool across easily enough. I
still have not yet looked at whether MSVC will compile the code for
libltdl, and the exeS.c files generated by libtool for dlpreopened
applications. I think iw ill also give up on this path for a while too.

I have had a brief look at the source for the cvs HEAD of libtool. I
don't understand the inner workings of libtool and was unsure where to
start looking. Are the files: libltdl/m4/libtool.m4 and
libltdl/m4/ltdl.m4 the best place for me to start looking? If so what
areas of thosefiles would people recommend i look at first? Is there
anything that may help in terms of documentation that i could read
(besides the maintaining section of the docs on the website)?

I will have a better look at the MSVC patch mentioned before when i
better understand how libtool operates.


I guess i am asking you people with more experience, is this a
reasonable path to be taking? Also i am almost certain others could do a
much better job than i could on this. Is there anyone else that is
actively working on a port of libtool for use with MSVC (Like the person
that created the original patch mentioned before)? I.e. should i just
sit back and wait for a MSVC port of libtool to come into existence? I
am willing to help if someone already has a plan in mind.

Thanks,
Brendon.


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (MingW32)

iD8DBQFEioqKLSWCuZeiyS0RAuYpAKCdLucBA+u7yw9iHoyWKDsVmbH7uQCeM1c/
cXuNY3gD0AweX+q77o5r844=
=K4QN
-----END PGP SIGNATURE-----