libtool-patches
[Top][All Lists]
Advanced

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

MSYS+MSVC for libtool branch-2-0, take 7


From: Peter Ekberg
Subject: MSYS+MSVC for libtool branch-2-0, take 7
Date: Fri, 22 Jul 2005 09:37:47 +0200

Hello!

I'm back with another gigantic mail. Sorry about that,
but this time I've tried to keep some structure.

I'm now at a point where I would like to see some
Commits :-). This works great for me, and it was a
gaz to e.g. use the Visual Studio debugger to single-
step to the offending LoadLibrary call in the
mdemo-exec test. I'm just not friends with gdb and
the various GUI frontends to it (I know of several
frontends that I have not tested though)...

I'm now going to split up this monster patch, and
feed the bits and pieces with changelog entries, so
any comments on the details is perhaps best saved
until there is a more resonably sized patch to comment
on. That way the discussion can be less entangled
and perhaps faster than it has been up to this point.

I'm just sending this mail to state where I'm at.


Fixed tests between v6 and 7 of the patch
=========================================

sh.test
-------

func_msvc_dashL_to_LINK fixed to not use this banned
construct:
"foo `bar \"foobar barfoo\"`".


mdemo-dryrun.test
-----------------

ls -l on MSYS sometimes prints the year instead of the
time for really fresh files. I added a couple of sleep 1
calls in the test, which incidentlly fixes the bug
for MinGW as well.


*-inst.test after *-nofast.test
-------------------------------

LINK set for compile _and_ finalize during program
linking.


mdemo-exec.test
---------------

Zap pesky dialog popup from failed LoadLibrary call
in libltdl (fixes the same problem for MinGW as well).

Making cl work as a C++ compiler (see below) revealed
a linking bug in libltdl (libltdl was not built as
a DLL since configure disabled shared libs when it
was falsely deduced that the C++ compiler could not
build them).

The problem is as follows. When libltdl is built as a
convenience lib (libltdlc) the LT_SCOPE define is set
to "__declspec(dllexport)" for Win32. In ltdl.c the
variable preloaded_symbols (or maybe I should say
lt_ltdlc_LTX_preloaded_symbols) is tagged with
LT_SCOPE. But the preloaded symbols should not be
exported from ltdl.c, they should be exported from
the generated ltdlcS.c. Anyway, the linker is
confused with these two definitions of
lt_ltdlc_LTX_preloaded_symbols and either selects
the first one it sees or selects the dllexported one.
Whatever algorithm it uses to select which of the
two to use, it of course selects the wrong one in
the libltdlc case. So, the used one is blank (all
zeros) which means that the name member of the first
entry in lt_ltdlc_LTX_preloaded_symbols ends up
being NULL which causes a segfault during lt_dlinit
(libltdl/loaders/preopen.c:322, the call to streq).

To prevent this, I exchanged the offending LT_SCOPE
for a plain extern in ltdl.c, which incidentally
fixes the bug for MinGW as well.


pdemo-*.test
------------

Uses command file for lib.exe to generate full list
of symbols.
Uses command file for lib.exe to generate archive.
(both activated when cmd line len is exceeded and
when not using gcc on mingw/cygwin, the test should
probably be for an archiver that understands command
files instead...)


*-relink.test
-------------

Fixed by setting shlibpath_overrides_runpath=yes
as is done on MinGW.
There is still a pesky dialog poping up when trying
to execute a binary that sees a faulty dll, but that
happens on MinGW as well. Is there a way to change
the error mode of the shell?


demo-noinst-link.test
---------------------

$make is empty when the test is executed, so hell
is executed instead of the intended build.
Changed to $MAKE, is that in some way wrong?


tagdemo-*.test
--------------

Apart from a bunch of shared lib description variables,
I have also made a dirty change. Without it C++ fails
miserably for MSVC. cl.exe only detects .cpp and
.cxx files as C++ source files. If you have source
files e.g. foo.cc and bar.cc, you have to say:
  cl -Tp foo.cc -Tp bar.cc
or
  cl -Tpfoo.cc -Tpbar.cc
and so on for each file that is a C++ source file.
Otherwise, cl simply forwards the file to the linker...

So, I made this dirty change:
ac_ext=cpp
instead of
ac_ext=cc

(the same is true for C source files, which has to
 be named .c, or you have to use the -Tc option.
 But who does not name C source files .c?)

With the above dirty change, it works.

Also, since MSVC uses @ and ? in C++ symbols (it also
uses @ for __fastcall C symbols for that matter) I'm
unsure of how ltdlopen (and preopen) will work...



Other fixes
===========

* Support for NM="dumpbin -symbols" as the name lister.

* stat(2) support for MSVC in the cwrappersource.

* Properly eliminate ": @PROGRAM@ " line.

* Make sure skipped_export is set to colon if _some_
  cmd of export_symbols_cmds is too long.

* Remove duplicate "creating reloadable object files..."
  message.

* Saying F77=: to configure disables the fortran tests
  in the testsuite.



Testsuite
=========

Here's the output from make check, when configured with:
configure CC=cl CFLAGS=-MD CXX=cl CXXFLAGS=-MD LD=link AR=lib STRIP=:
NM="dumpbin -symbols" F77=:

This is my environment:

cl is:
Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 12.00.8804 for
80x86
Copyright (C) Microsoft Corp 1984-1998. All rights reserved.

link is:
Microsoft (R) Incremental Linker Version 6.00.8447
Copyright (C) Microsoft Corp 1992-1998. All rights reserved.

lib is:
Microsoft (R) Library Manager Version 6.00.8447
Copyright (C) Microsoft Corp 1992-1998. All rights reserved.

dumpbin is:
Microsoft (R) COFF Binary File Dumper Version 6.00.8447
Copyright (C) Microsoft Corp 1992-1998. All rights reserved.

Making check in .
make[1]: Entering directory
`/c/cygwin/home/peda/libtool/2-0/libtool/msvc4'
make  check-TESTS
make[2]: Entering directory
`/c/cygwin/home/peda/libtool/2-0/libtool/msvc4'
PASS: tests/link.test
PASS: tests/link-2.test
PASS: tests/nomode.test
PASS: tests/objectlist.test
PASS: tests/quote.test
PASS: tests/sh.test
PASS: tests/suffix.test
SKIP: tests/tagtrace.test
PASS: tests/cdemo-static.test
PASS: tests/cdemo-make.test
PASS: tests/cdemo-exec.test
PASS: tests/demo-static.test
PASS: tests/demo-make.test
PASS: tests/demo-exec.test
PASS: tests/demo-inst.test
PASS: tests/demo-unst.test
PASS: tests/depdemo-static.test
PASS: tests/depdemo-make.test
PASS: tests/depdemo-exec.test
PASS: tests/depdemo-inst.test
PASS: tests/depdemo-unst.test
PASS: tests/mdemo-static.test
PASS: tests/mdemo-make.test
PASS: tests/mdemo-exec.test
PASS: tests/mdemo-inst.test
PASS: tests/mdemo-unst.test
PASS: tests/cdemo-conf.test
PASS: tests/cdemo-make.test
PASS: tests/cdemo-exec.test
PASS: tests/demo-conf.test
PASS: tests/demo-make.test
PASS: tests/demo-exec.test
PASS: tests/demo-inst.test
PASS: tests/demo-unst.test
FAIL: tests/demo-deplibs.test
PASS: tests/depdemo-conf.test
PASS: tests/depdemo-make.test
PASS: tests/depdemo-exec.test
PASS: tests/depdemo-inst.test
PASS: tests/depdemo-unst.test
PASS: tests/mdemo-conf.test
PASS: tests/mdemo-make.test
PASS: tests/mdemo-exec.test
PASS: tests/mdemo-inst.test
PASS: tests/mdemo-unst.test
PASS: tests/mdemo-dryrun.test
PASS: tests/mdemo2-conf.test
PASS: tests/mdemo2-make.test
PASS: tests/mdemo2-exec.test
PASS: tests/pdemo-conf.test
PASS: tests/pdemo-make.test
PASS: tests/pdemo-exec.test
PASS: tests/pdemo-inst.test
PASS: tests/demo-nofast.test
PASS: tests/demo-make.test
PASS: tests/demo-exec.test
PASS: tests/demo-inst.test
PASS: tests/demo-unst.test
PASS: tests/depdemo-nofast.test
PASS: tests/depdemo-make.test
PASS: tests/depdemo-exec.test
PASS: tests/depdemo-inst.test
PASS: tests/depdemo-unst.test
PASS: tests/demo-pic.test
PASS: tests/demo-make.test
PASS: tests/demo-exec.test
PASS: tests/demo-nopic.test
PASS: tests/demo-make.test
PASS: tests/demo-exec.test
PASS: tests/cdemo-shared.test
PASS: tests/cdemo-make.test
PASS: tests/cdemo-exec.test
PASS: tests/demo-shared.test
PASS: tests/demo-make.test
PASS: tests/demo-exec.test
PASS: tests/demo-inst.test
FAIL: tests/demo-hardcode.test
PASS: tests/demo-relink.test
PASS: tests/demo-noinst-link.test
PASS: tests/demo-unst.test
PASS: tests/depdemo-shared.test
PASS: tests/depdemo-make.test
PASS: tests/depdemo-exec.test
PASS: tests/depdemo-inst.test
PASS: tests/depdemo-relink.test
PASS: tests/depdemo-unst.test
PASS: tests/mdemo-shared.test
PASS: tests/mdemo-make.test
PASS: tests/mdemo-exec.test
PASS: tests/mdemo-inst.test
PASS: tests/mdemo-unst.test
PASS: tests/cdemo-undef.test
PASS: tests/cdemo-make.test
PASS: tests/cdemo-exec.test
PASS: tests/duplicate_members.test
PASS: tests/tagdemo-static.test
PASS: tests/tagdemo-make.test
PASS: tests/tagdemo-exec.test
PASS: tests/tagdemo-conf.test
PASS: tests/tagdemo-make.test
PASS: tests/tagdemo-exec.test
PASS: tests/tagdemo-shared.test
PASS: tests/tagdemo-make.test
PASS: tests/tagdemo-exec.test
PASS: tests/tagdemo-undef.test
PASS: tests/tagdemo-make.test
PASS: tests/tagdemo-exec.test
====================================
2 of 106 tests failed
(1 tests were not run)
Please report to address@hidden
====================================
make[2]: *** [check-TESTS] Error 1
make[2]: Leaving directory
`/c/cygwin/home/peda/libtool/2-0/libtool/msvc'
make[1]: *** [check-am] Error 2
make[1]: Leaving directory
`/c/cygwin/home/peda/libtool/2-0/libtool/msvc'
make: *** [check-recursive] Error 1


Remaining FAILures
==================

demo-deplibs
------------

Rule from Automake which invokes $AR (without
$AR_SEP and with $ARFLAGS, not $AR_FLAGS).


demo-hardcode
-------------

After changing the test to invoke
$(LIBTOOL) --tag=CC --mode=link $(CC) etc
instead of just
$(CC) etc
I get this output near the end:

------8<------
demo-hardcode.test: ===  Finding libtool.m4's guesses at hardcoding
values
= Searching for hardcoded library directories in each program
.libs was hardcoded in `hc-direct', which fooled libtool
.libs was hardcoded in `hc-libflag', as libtool expected
`hc-libpath' was not linked properly, as libtool expected
.libs was hardcoded in `hc-minusL', which fooled libtool
FAIL: tests/demo-hardcode.test
------8<------

Various variables from the generated libtool script:
hardcode_libdir_flag_spec=" "
hardcode_libdir_flag_spec_ld=""
hardcode_libdir_separator=""
hardcode_direct=no
hardcode_minus_L=no
hardcode_shlibpath_var=unsupported
hardcode_automatic=no

With the above change the test scans the wrapper scripts for
the path, where it should have scanned the binaries. The change
to use libtool to link the binaries also breaks the test for
MinGW and Cygwin...

The problem here is that you can't use $CC directly from the
Makefile, you have to wrap it in the magic provided by
libtool (or revert to the cccl script), but the test isn't
written to handle linking with libtool, and I don't know
how to change it so that it does.


Wishlist
========

* Find a way to eliminate objdump, the only remaining
  required tool from binutils. If that is done, it
  should be possible to just install MSYS and GNU make
  to use MSVC with libtool.

* Make LT_PATH_LD look for link.exe. If that and the
  above is done, the holy graal is achieved.
  (i.e. "configure; make" works)

* A way to set the error mode during the runs of the
  *.relink.test tests, so that you don't have to kill
  the pesky dialog every time (would also fix the
  problem for MinGW and Cygwin).


Cheers,
Peter

Attachment: msys_msvc-7.patch
Description: msys_msvc-7.patch


reply via email to

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