libtool-patches
[Top][All Lists]
Advanced

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

Re: [patch #6448] [MSVC 7/7] Add MSVC Support


From: Ralf Wildenhues
Subject: Re: [patch #6448] [MSVC 7/7] Add MSVC Support
Date: Wed, 13 Aug 2008 07:56:32 +0200
User-agent: Mutt/1.5.18 (2008-05-17)

* Peter Rosin wrote on Wed, Aug 06, 2008 at 09:47:28AM CEST:
> Ralf Wildenhues skrev:
>> * Peter Rosin wrote on Tue, Aug 05, 2008 at 10:38:14AM CEST:
>>> Peter Rosin skrev:
>>>   16: duplicate_conv.at:25 duplicate convenience archive names
>>> MS link doesn't have reloadable objects (i.e. like "ld -r").
>>
>> Should be fixed by at-file support I hope.
>
> Unfortunately not, the test tries to link with "-o cee.$OBJEXT" which
> triggers some different code path using -r. I don't think's it's
> possible to have link.exe output an object file.

Ah yes, I didn't look at the test.  In this case, the test should just
be skipped for systems where reload_cmds does not work.  Speaking of
which, I think you should set reload_cmds to 'false' or so, so that it's
clear things fail.  That could then be tested for as a SKIP criterion in
the testsuite.

> Side note, the mainfest could perhaps be used to support some version
> of hardcode_libdir?

I guess.  Patches welcome, as they say.  ;-)

>>>   30: static.at:357      ccache -all-static
>>> cl.exe spews out a banner on stderr which isn't [ignore]d
>>
>> I think that banner should just be ignored.
>
> Me too.

Is the patch below sufficient?

>>>   46: lt_dladvise.at:28  lt_dlopenadvise library loading
>>> -avoid-version causes the names of the import lib and the static
>>> lib to be the same. But something else<TM> also seems bad...
>>
>> Several issues:
>> - the test is somewhat broken (also on other systems)
>> - maybe we need to forbid enabling both static and shared at the same
>>   time
>
> - Or come up with a naming scheme that doesn't conflict with itself,
>   but I don't know if that's possible...

Not sure whether I understand this.

> But pdemo still fails due to an exported variable. Sigh. Why does each and
> every damn test (well, almost) have to export a variable when that's listed
> as not portable in the docs?

Because it can be done on most systems, and w32 is not supported anyway
for many packages.

> Seems masochistic to me...

Well, the testsuite is intended to test each possible code path.  That
doesn't mean things have to be tested more often than necessary, but
there could be for example a bug with exporting variables in the ltmain
code that is exercises by pdemo.

> From my point of view, you may push the ltmain part of the patch. I'll test
> any improved m4 code when you have settled on how to enable it. However,
> your idea to check the help output will not work, dumpbin -? doesn't
> indicate any support whatsoever for @.

Oh, I didn't mean to try 'dumpbin -?'  Sorry, I should have been
clearer: GNU binutils nm understands @FILE since fairly recently; more
precisely, all binutils tools understand this syntax since version 2.17.
It would be nice to also enable this for binutils.  That would enable
most real-world uses of 'ld -r' for good.  Proposed patch below.

However, we need to avoid enabling this for older GNU binutils.  That
could be done with a feature check or a check of --help output.
Probably a feature check is more reliable.

Part of my confusion here stemmed from the fact that, while on unixy
systems, at-file support is a per-tool thing, on Windows it is actually
a system feature (at least I think that it is that way).

Proposed patch below.  I changed my mind again and moved the
nm_file_list_spec setting out from LT_PATH_NM.  OK?

Cheers,
Ralf

2008-08-13  Ralf Wildenhues  <address@hidden>

        * tests/static.at (ccache -all-static): Ignore compiler stderr.
        Reported by Peter Rosin.

diff --git a/tests/static.at b/tests/static.at
index b5e9946..08b202f 100644
--- a/tests/static.at
+++ b/tests/static.at
@@ -370,7 +370,7 @@ AT_DATA([a.c],
 [[int main(void) { return 0; }
 ]])
 
-AT_CHECK([$CC $CPPFLAGS $CFLAGS -c a.c], [], [ignore])
+AT_CHECK([$CC $CPPFLAGS $CFLAGS -c a.c], [], [ignore], [ignore])
 AT_CHECK([$LIBTOOL --mode=link --tag=CC ./ccache $CC $CFLAGS $LDFLAGS 
-all-static a.$OBJEXT -o a],
         [], [ignore], [ignore])
 


2008-08-13  Ralf Wildenhues  <address@hidden>

        * libltdl/m4/libtool.m4 (LT_PATH_NM): Move setting of
        nm_file_list_spec ...
        (_LT_CMD_GLOBAL_SYMBOLS): ... here.  Also enable for GNU nm if
        supported.

diff --git a/libltdl/m4/libtool.m4 b/libltdl/m4/libtool.m4
index 7ceec66..9129896 100644
--- a/libltdl/m4/libtool.m4
+++ b/libltdl/m4/libtool.m4
@@ -3344,13 +3344,6 @@ AC_CACHE_CHECK([the name lister ($NM) interface], 
[lt_cv_nm_interface],
     lt_cv_nm_interface="MS dumpbin"
   fi
   rm -f conftest*])
-
-if test "$lt_cv_nm_interface" = "MS dumpbin"; then
-  nm_file_list_spec='@'
-fi
-
-_LT_DECL([], [nm_file_list_spec], [1],
-    [Specify filename containing input files for $NM])
 ])# LT_PATH_NM
 
 # Old names:
@@ -3628,6 +3621,14 @@ else
   AC_MSG_RESULT(ok)
 fi
 
+# Response file support.
+if test "$lt_cv_nm_interface" = "MS dumpbin"; then
+  nm_file_list_spec='@'
+fi
+if $NM --help 2>/dev/null | grep 'address@hidden' >/dev/null; then
+  nm_file_list_spec='@'
+fi
+
 _LT_DECL([global_symbol_pipe], [lt_cv_sys_global_symbol_pipe], [1],
     [Take the output of nm and produce a listing of raw symbols and C names])
 _LT_DECL([global_symbol_to_cdecl], [lt_cv_sys_global_symbol_to_cdecl], [1],
@@ -3638,6 +3639,8 @@ _LT_DECL([global_symbol_to_c_name_address],
 _LT_DECL([global_symbol_to_c_name_address_lib_prefix],
     [lt_cv_sys_global_symbol_to_c_name_address_lib_prefix], [1],
     [Transform the output of nm in a C name address pair when lib prefix is 
needed])
+_LT_DECL([], [nm_file_list_spec], [1],
+    [Specify filename containing input files for $NM])
 ]) # _LT_CMD_GLOBAL_SYMBOLS
 
 




reply via email to

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