Re: pr-msvc-support: building .DLLs with symbols
Den 2009-09-22 02:15 skrev Christopher Hulbert: On Mon, Sep 21, 2009 at 2:47 PM, Peter Rosin p...@lysator.liu.se wrote: Den 2009-09-21 12:35 skrev Christopher Hulbert: Apart from that, your suggestion will litter dependency_libs with -LIBPATH: and it will not work for absolute paths (unless you're using identity mounts, but that's cheating). That could perhaps be fixed but I think you will have trouble converting back to a posix path for dependency_libs in case of -L/absolute/path - -LIBPATH:c:/some/mount/absolute/path. There's no api for that in MSYS (that I know of). I assume you mean the dependency_libs that gets written to the .la file? My dependency_libs in Linux has a number of -L, but I'm not sure if it is my patches. It seems to be in other packages that I have downloaded and built as well, so I suspect that is the normal behavior. Yes it is normal with a bunch of -L options in dependency_libs. What I'm objecting to is that with your version, it will be -LIBPATH: instead of -L in dependency_libs. I see that as a problem (see below). I am not sure what you mean by the identity mounts, could you explain a little more? Identity mount is where you put the MSYS root in the root of a windows drive, so that /absolute/path means the same thing in posix-land as in windows-land (given that you have the expected current drive, e.g. C:). Also, why would you want to convert back to a POSIX path? If the compiler does not understand posix path, there would be no point that I could see to go back. I want the .la file to contain -L and the POSIX paths, so that the .la file is usable by MSYS/MinGW and looks as much as possible as in the MSYS/MinGW case. That way the command line also looks the same regardless of if the options came from dependency_libs or from somewhere else. I guess in my case, you would have to convert back (if possible) or maintain 2 different variables. Neither is probably desired. I don't mix compilers on Windows, so I guess I have not run into a case where I want -L after converting to -LIBPATH:. My philosophy has been to convert to MSVC style as late as possible, and by doing so, keep a common code path with MinGW for as long as possible. It probably also fits better if one package is built with libtool/pr-msvc-support and some dependency/dependent package is build with a cl.exe wrapper such as cccl. But that's a bit of speculation as I'm not exactly a heavy cccl user... And you still need some way to get FLAG in behind that -link option in case someone feeds you -Wl,FLAG (which is a much better way to feed -LIBPATH: options from the outside, compared to having libtool also recognize -LIBPATH: as an alias for -L IMHO), or you are stuck with moving options to an envvar (or a command file). I consider myself a libtool hacker (not a libtool developer), but it looks like the -Wl argument modifies a linker_flag variable. Why not just add that, like deplibs, after the -link in the archive_cmds and archive_expsym_cmds that is defined in libtool.m4? Then, it would put those arguments after -link. And only do that for MSVC case only, which will force some other variable to enable the code path at all, since we don't want to foul up the command line for saner cases. But certainly doable, but I fail to see the advantage over using the LINK envvar. And I would disagree that feeding in the libpath via a bunch of -Wl is good. For example, how does an autoconf macro check for a library. Right now with my hacked libtool and a macro I wrote that emulates AC_TRY_LINK and AC_LINK_IFELSE using libtool to compile, my autoconf macros that check for libraries can just build up the -Lpath -la link information based on a directory passed into the configure argument. Otherwise, I (or another builder of my packages) would have to specify all the -LIBPATH and library files manually. I personally find this much cleaner for building. You misunderstood me, I meant that .../libtool ... -Wl,-LIBPATH:C:/foo/bar -lgazonk is better than .../libtool ... -LIBPATH:C:/foo/bar -lgazonk I don't see any reason to support .../libtool ... -LIBPATH:C:/foo/bar -lgazonk at all (unless you have -LIBPATH: in dependency_libs of course, but that's not clean IMHO). I guess I don't see a reason not to, but maybe we just don't have the same goals. In that case it's because you have more limited goals. The end result of your approach is that everything is pulled into the MSVC world, and nobody hasn't even got a remote chance of seamless integration when using the result with MinGW (or whatever). One issue I am not sure how you address, is that the linker does not interpret -ljunk as libjunk.lib, junk.lib, etc. I search the directories in deplibs for the library and translate it from -l to something the compiler/linker would understand. There is code for that in the pr-msvc-support branch. Have a look at this patch: http://savannah.gnu.org/patch/?6446 commit 452faf96f7b06e9eccee01553d95c45080d1cc29 And this
Re: pr-msvc-support: building .DLLs with symbols
On Fri, Sep 18, 2009 at 11:17 PM, Peter Rosin p...@lysator.liu.se wrote: Den 2009-09-18 14:01 skrev Christopher Hulbert: On Fri, Sep 18, 2009 at 6:53 AM, Peter Rosin p...@lysator.liu.se wrote: Hi Chris, Den 2009-09-18 12:16 skrev Christopher Hulbert: In my windows branch, I use link_search_path_spec as in: _LT_TAGDECL([], [link_search_path_spec], [1], [Flag to add a directory to the linker search path]) Then, somewhere in the -L* case of argument processing in func_mode_link. if test -n $link_search_path_spec; then this_deplib=$link_search_path_spec$dir else this_deplib=-L$dir fi where all cases of the existing -L$dir is replaced by $this_deplib. Note also that there is an explicit case for -LIBPATH:* so that -LIBPATH can be used in user-defined environment variables for example. My windows branch seems to work ok for the PGI and Intel compilers on windows with a couple exceptions: * running executables (e.g. test programs for the testsuite) that use DLLs. * building DLLs with version information. Are you suggesting that, when given this: $ .../libtool --mode=link ... -L/foo/bar ... libtool immediately munges that into an intermediate form: ... -LIBPATH:/foo/bar ... then, just before linking, moves the -LIBPATH: options to the LINK envvar: LINK= -LIBPATH:c:/some/mount/foo/bar cl ... so that link.exe sees them when cl.exe calls link.exe? Not exactly. In the argument processing of func_mode_link, the deplibs variable is built up with the dependency libraries. Building that up, the -L is translated to $link_search_path_spec, and -LIBPATH is passed as used. In libtool.m4 under the cygwin/mingw case of _LT_LINKER_SHLIBS([TAGNAME]) (when not using GCC), I have a cc_basename case, and so for the PGI and Intel compilers on these platforms, I have the commands for building the libraries which includes $deplibs after a -link for the intel compiler because it follows the MSVC convention. The PGI compilers behave more like Linux so I don't have to worry about this. My case snippet is below. *snip snippet* Ah, you are also adding -link right before all the $deplibs. Didn't think of that, but I'm not 100% sure if $deplibs can contain anything that has to be seen by cl.exe? I hope not... I'm not sure either, but I haven't seen anything that has caused an issue. Plus, deplibs sure sounds like its ONLY dependent libraries :)! Apart from that, your suggestion will litter dependency_libs with -LIBPATH: and it will not work for absolute paths (unless you're using identity mounts, but that's cheating). That could perhaps be fixed but I think you will have trouble converting back to a posix path for dependency_libs in case of -L/absolute/path - -LIBPATH:c:/some/mount/absolute/path. There's no api for that in MSYS (that I know of). I assume you mean the dependency_libs that gets written to the .la file? My dependency_libs in Linux has a number of -L, but I'm not sure if it is my patches. It seems to be in other packages that I have downloaded and built as well, so I suspect that is the normal behavior. I am not sure what you mean by the identity mounts, could you explain a little more? Also, why would you want to convert back to a POSIX path? If the compiler does not understand posix path, there would be no point that I could see to go back. And you still need some way to get FLAG in behind that -link option in case someone feeds you -Wl,FLAG (which is a much better way to feed -LIBPATH: options from the outside, compared to having libtool also recognize -LIBPATH: as an alias for -L IMHO), or you are stuck with moving options to an envvar (or a command file). I consider myself a libtool hacker (not a libtool developer), but it looks like the -Wl argument modifies a linker_flag variable. Why not just add that, like deplibs, after the -link in the archive_cmds and archive_expsym_cmds that is defined in libtool.m4? Then, it would put those arguments after -link. And I would disagree that feeding in the libpath via a bunch of -Wl is good. For example, how does an autoconf macro check for a library. Right now with my hacked libtool and a macro I wrote that emulates AC_TRY_LINK and AC_LINK_IFELSE using libtool to compile, my autoconf macros that check for libraries can just build up the -Lpath -la link information based on a directory passed into the configure argument. Otherwise, I (or another builder of my packages) would have to specify all the -LIBPATH and library files manually. I personally find this much cleaner for building. But I guess I could borrow your variable name and use my implementation. Ralf, is link_search_path_spec (or perhaps linker_search_path_spec in order to match linker_envvar) ok for what dashL_envvar_spec is currently doing? Cheers, Peter
Re: pr-msvc-support: building .DLLs with symbols
Den 2009-09-21 12:35 skrev Christopher Hulbert: Apart from that, your suggestion will litter dependency_libs with -LIBPATH: and it will not work for absolute paths (unless you're using identity mounts, but that's cheating). That could perhaps be fixed but I think you will have trouble converting back to a posix path for dependency_libs in case of -L/absolute/path - -LIBPATH:c:/some/mount/absolute/path. There's no api for that in MSYS (that I know of). I assume you mean the dependency_libs that gets written to the .la file? My dependency_libs in Linux has a number of -L, but I'm not sure if it is my patches. It seems to be in other packages that I have downloaded and built as well, so I suspect that is the normal behavior. Yes it is normal with a bunch of -L options in dependency_libs. What I'm objecting to is that with your version, it will be -LIBPATH: instead of -L in dependency_libs. I see that as a problem (see below). I am not sure what you mean by the identity mounts, could you explain a little more? Identity mount is where you put the MSYS root in the root of a windows drive, so that /absolute/path means the same thing in posix-land as in windows-land (given that you have the expected current drive, e.g. C:). Also, why would you want to convert back to a POSIX path? If the compiler does not understand posix path, there would be no point that I could see to go back. I want the .la file to contain -L and the POSIX paths, so that the .la file is usable by MSYS/MinGW and looks as much as possible as in the MSYS/MinGW case. That way the command line also looks the same regardless of if the options came from dependency_libs or from somewhere else. And you still need some way to get FLAG in behind that -link option in case someone feeds you -Wl,FLAG (which is a much better way to feed -LIBPATH: options from the outside, compared to having libtool also recognize -LIBPATH: as an alias for -L IMHO), or you are stuck with moving options to an envvar (or a command file). I consider myself a libtool hacker (not a libtool developer), but it looks like the -Wl argument modifies a linker_flag variable. Why not just add that, like deplibs, after the -link in the archive_cmds and archive_expsym_cmds that is defined in libtool.m4? Then, it would put those arguments after -link. And only do that for MSVC case only, which will force some other variable to enable the code path at all, since we don't want to foul up the command line for saner cases. But certainly doable, but I fail to see the advantage over using the LINK envvar. And I would disagree that feeding in the libpath via a bunch of -Wl is good. For example, how does an autoconf macro check for a library. Right now with my hacked libtool and a macro I wrote that emulates AC_TRY_LINK and AC_LINK_IFELSE using libtool to compile, my autoconf macros that check for libraries can just build up the -Lpath -la link information based on a directory passed into the configure argument. Otherwise, I (or another builder of my packages) would have to specify all the -LIBPATH and library files manually. I personally find this much cleaner for building. You misunderstood me, I meant that .../libtool ... -Wl,-LIBPATH:C:/foo/bar -lgazonk is better than .../libtool ... -LIBPATH:C:/foo/bar -lgazonk I don't see any reason to support .../libtool ... -LIBPATH:C:/foo/bar -lgazonk at all (unless you have -LIBPATH: in dependency_libs of course, but that's not clean IMHO). And if you have libtoolized versions of AC_TRY_LINK and AC_LINK_IFELSE (and AC_CHECK_LIB etc) then why not feed them -L/some/posix/path? It's not as if cl.exe understands -LIBPATH: anyway. Cheers, Peter
Re: pr-msvc-support: building .DLLs with symbols
On Mon, Sep 21, 2009 at 2:47 PM, Peter Rosin p...@lysator.liu.se wrote: Den 2009-09-21 12:35 skrev Christopher Hulbert: Apart from that, your suggestion will litter dependency_libs with -LIBPATH: and it will not work for absolute paths (unless you're using identity mounts, but that's cheating). That could perhaps be fixed but I think you will have trouble converting back to a posix path for dependency_libs in case of -L/absolute/path - -LIBPATH:c:/some/mount/absolute/path. There's no api for that in MSYS (that I know of). I assume you mean the dependency_libs that gets written to the .la file? My dependency_libs in Linux has a number of -L, but I'm not sure if it is my patches. It seems to be in other packages that I have downloaded and built as well, so I suspect that is the normal behavior. Yes it is normal with a bunch of -L options in dependency_libs. What I'm objecting to is that with your version, it will be -LIBPATH: instead of -L in dependency_libs. I see that as a problem (see below). I am not sure what you mean by the identity mounts, could you explain a little more? Identity mount is where you put the MSYS root in the root of a windows drive, so that /absolute/path means the same thing in posix-land as in windows-land (given that you have the expected current drive, e.g. C:). Also, why would you want to convert back to a POSIX path? If the compiler does not understand posix path, there would be no point that I could see to go back. I want the .la file to contain -L and the POSIX paths, so that the .la file is usable by MSYS/MinGW and looks as much as possible as in the MSYS/MinGW case. That way the command line also looks the same regardless of if the options came from dependency_libs or from somewhere else. I guess in my case, you would have to convert back (if possible) or maintain 2 different variables. Neither is probably desired. I don't mix compilers on Windows, so I guess I have not run into a case where I want -L after converting to -LIBPATH:. And you still need some way to get FLAG in behind that -link option in case someone feeds you -Wl,FLAG (which is a much better way to feed -LIBPATH: options from the outside, compared to having libtool also recognize -LIBPATH: as an alias for -L IMHO), or you are stuck with moving options to an envvar (or a command file). I consider myself a libtool hacker (not a libtool developer), but it looks like the -Wl argument modifies a linker_flag variable. Why not just add that, like deplibs, after the -link in the archive_cmds and archive_expsym_cmds that is defined in libtool.m4? Then, it would put those arguments after -link. And only do that for MSVC case only, which will force some other variable to enable the code path at all, since we don't want to foul up the command line for saner cases. But certainly doable, but I fail to see the advantage over using the LINK envvar. And I would disagree that feeding in the libpath via a bunch of -Wl is good. For example, how does an autoconf macro check for a library. Right now with my hacked libtool and a macro I wrote that emulates AC_TRY_LINK and AC_LINK_IFELSE using libtool to compile, my autoconf macros that check for libraries can just build up the -Lpath -la link information based on a directory passed into the configure argument. Otherwise, I (or another builder of my packages) would have to specify all the -LIBPATH and library files manually. I personally find this much cleaner for building. You misunderstood me, I meant that .../libtool ... -Wl,-LIBPATH:C:/foo/bar -lgazonk is better than .../libtool ... -LIBPATH:C:/foo/bar -lgazonk I don't see any reason to support .../libtool ... -LIBPATH:C:/foo/bar -lgazonk at all (unless you have -LIBPATH: in dependency_libs of course, but that's not clean IMHO). I guess I don't see a reason not to, but maybe we just don't have the same goals. One issue I am not sure how you address, is that the linker does not interpret -ljunk as libjunk.lib, junk.lib, etc. I search the directories in deplibs for the library and translate it from -l to something the compiler/linker would understand. And if you have libtoolized versions of AC_TRY_LINK and AC_LINK_IFELSE (and AC_CHECK_LIB etc) then why not feed them -L/some/posix/path? It's not as if cl.exe understands -LIBPATH: anyway. I feed -L and -l to the libtool link command (as if the command supported it). Libtool translates this to cl.exe ... -link -libpath:c:/some/path junk.lib, which works perfectly fine. cl.exe does not support -libpath directly, but does pass flags after -link to the linker. I like passing linker information to the compiler, because compilers like the PGI ones can add libraries like the PGI fortran runtime libraries. link.exe does not know about it unless I tell it. Cheers, Peter
Re: pr-msvc-support: building .DLLs with symbols
Hi Ralf,
Den 2009-09-18 06:37 skrev Ralf Wildenhues:
* Peter Rosin wrote on Thu, Sep 10, 2009 at 11:48:34AM CEST:
Here's a couple of patches that implements support for -Wl, and
-Xlinker for MSVC. The first one (rename-dashL_envvar-tolinker_envvar.patch)
is just a rename, to reduce confusion,
In general, a rename from an ugly variable name like dashL_envvar is a
good thing. However, it is also an API change that would normally need
announcing in NEWS and asking ourselves why we messed up before and had
to fix it. Luckily, this one is in pr-msvc-support only, not in master,
so I don't have such a big problem with it. However, if you do it then
please rename *all* instances of this ugliness (dashL_envvar_spec?).
With that, I think the first patch is probably a good thing.
I didn't know dashL_envvar was considered so ugly. Noone told me since
its introduction four years ago [1] so I was beginning to think that it
was maybe ok, but I admit to not having given it much thought lately. I
only changed it since the variable is now used for other things as well.
[1] http://lists.gnu.org/archive/html/libtool-patches/2005-08/msg00080.html
How should I name dashL_envvar_spec? For MSVC it is set to '-LIBPATH:'
so that
$ .../libtool --mode=link ... -L/foo/bar ...
triggers a transformation into
LINK= -LIBPATH:C:/some/mount/foo/bar cl ...
So, linker_envvar is the name of the variable, and dashL_envvar_spec
is what to prepend when moving -L paths to that variable. Should I
just lose that variable altogether and hardcode the -LIBPATH: thing
in func_to_linker_envvar (aka func_dashL_to_envvar)? It's not as if
there are any other users of linker_envvar et al to consider at
this point...
Is dashl_xform also a bad name? It's a sed expression that transforms
-lfoo into something more suitable (foo.lib in this case). Better
suggestion welcome (if it is indeed distasteful, I wouldn't know).
and the second patch
(-Xlinker-msvc.patch) contains the new code...
And the @lt_linker@ thing is again so ugly it makes me cringe.
Oops, sorry, I didn't mean to scare you :-)
No, really, I don't want to see code like this in master, that will be
unmaintainable a year down the road. Why are we not looking for -Wl,
and transforming that if linker_envvar is nonempty?
Because that would require $wl to be '-Wl,', which I thought was a bit
misleading. But I can do it that way if that's preferred, please
advise.
And why does the
description of linker_envvar not state that it also holds other link
flags (is that maybe *not* true for some other systems on which this
variable is used)?
After both these patches are applied, you have:
@defvar linker_envvar
When linking, move all paths specified with @option{-L} options to
this variable, for toolchains where it makes sense to pass the library
search paths in an environment variable. Linker options passed with
@option{-Wl,} or @option{-Xlinker} may also be passed via this
environment variable if @var{wl} is set to @samp{@@lt_envvar@@}.
Normally disabled (i.e. @var{linker_envvar} empty).
@end defvar
So, I think you might have only picked up the rename of the variable
and not the change in the description when its usage was actually
changed in the second patch? Or?
Does the expanded form of $wl ever get into .la files BTW? This would
certainly make them unusable for another compiler later on (this is not
something that is broken nor needs to be fixed with this patch, I'm just
noting it here because I see it and this is one of the few systems where
it makes a big difference.)
No '-Wl,' options are added to neither inherited_linker_flags nor
dependency_libs I think, so we're cool there. I think.
Ok for the pr-msvc-support branch?
Well, to me that depends upon whether you want to rewrite this code for
an eventual inclusion in master anyway or not.
I'm willing to do a rewrite if that's what it's going to take, but I
prefer to do it before any merge window opens, and I need pointers on
what needs to be rewritten. Just having the branch as a dumping spot
for a pile of unacceptable patches is not much use.
Thanks, and sorry if that was a bit harsh,
I can take the heat, better harsh and timely than nothing at all...
Cheers,
Peter
Re: pr-msvc-support: building .DLLs with symbols
On Fri, Sep 18, 2009 at 4:26 AM, Peter Rosin p...@lysator.liu.se wrote:
Hi Ralf,
Den 2009-09-18 06:37 skrev Ralf Wildenhues:
* Peter Rosin wrote on Thu, Sep 10, 2009 at 11:48:34AM CEST:
Here's a couple of patches that implements support for -Wl, and
-Xlinker for MSVC. The first one
(rename-dashL_envvar-tolinker_envvar.patch)
is just a rename, to reduce confusion,
In general, a rename from an ugly variable name like dashL_envvar is a
good thing. However, it is also an API change that would normally need
announcing in NEWS and asking ourselves why we messed up before and had
to fix it. Luckily, this one is in pr-msvc-support only, not in master,
so I don't have such a big problem with it. However, if you do it then
please rename *all* instances of this ugliness (dashL_envvar_spec?).
With that, I think the first patch is probably a good thing.
I didn't know dashL_envvar was considered so ugly. Noone told me since
its introduction four years ago [1] so I was beginning to think that it
was maybe ok, but I admit to not having given it much thought lately. I
only changed it since the variable is now used for other things as well.
In my windows branch, I use link_search_path_spec as in:
_LT_TAGDECL([], [link_search_path_spec], [1],
[Flag to add a directory to the linker search path])
Then, somewhere in the -L* case of argument processing in func_mode_link.
if test -n $link_search_path_spec; then
this_deplib=$link_search_path_spec$dir
else
this_deplib=-L$dir
fi
where all cases of the existing -L$dir is replaced by
$this_deplib. Note also that there is an explicit case for
-LIBPATH:* so that -LIBPATH can be used in user-defined environment
variables for example. My windows branch seems to work ok for the PGI
and Intel compilers on windows with a couple exceptions:
* running executables (e.g. test programs for the testsuite) that use DLLs.
* building DLLs with version information.
Chris
[1] http://lists.gnu.org/archive/html/libtool-patches/2005-08/msg00080.html
How should I name dashL_envvar_spec? For MSVC it is set to '-LIBPATH:'
so that
$ .../libtool --mode=link ... -L/foo/bar ...
triggers a transformation into
LINK= -LIBPATH:C:/some/mount/foo/bar cl ...
So, linker_envvar is the name of the variable, and dashL_envvar_spec
is what to prepend when moving -L paths to that variable. Should I
just lose that variable altogether and hardcode the -LIBPATH: thing
in func_to_linker_envvar (aka func_dashL_to_envvar)? It's not as if
there are any other users of linker_envvar et al to consider at
this point...
Is dashl_xform also a bad name? It's a sed expression that transforms
-lfoo into something more suitable (foo.lib in this case). Better
suggestion welcome (if it is indeed distasteful, I wouldn't know).
and the second patch
(-Xlinker-msvc.patch) contains the new code...
And the @lt_linker@ thing is again so ugly it makes me cringe.
Oops, sorry, I didn't mean to scare you :-)
No, really, I don't want to see code like this in master, that will be
unmaintainable a year down the road. Why are we not looking for -Wl,
and transforming that if linker_envvar is nonempty?
Because that would require $wl to be '-Wl,', which I thought was a bit
misleading. But I can do it that way if that's preferred, please
advise.
And why does the
description of linker_envvar not state that it also holds other link
flags (is that maybe *not* true for some other systems on which this
variable is used)?
After both these patches are applied, you have:
@defvar linker_envvar
When linking, move all paths specified with @option{-L} options to
this variable, for toolchains where it makes sense to pass the library
search paths in an environment variable. Linker options passed with
@option{-Wl,} or @option{-Xlinker} may also be passed via this
environment variable if @var{wl} is set to @samp{@@lt_envvar@@}.
Normally disabled (i.e. @var{linker_envvar} empty).
@end defvar
So, I think you might have only picked up the rename of the variable
and not the change in the description when its usage was actually
changed in the second patch? Or?
Does the expanded form of $wl ever get into .la files BTW? This would
certainly make them unusable for another compiler later on (this is not
something that is broken nor needs to be fixed with this patch, I'm just
noting it here because I see it and this is one of the few systems where
it makes a big difference.)
No '-Wl,' options are added to neither inherited_linker_flags nor
dependency_libs I think, so we're cool there. I think.
Ok for the pr-msvc-support branch?
Well, to me that depends upon whether you want to rewrite this code for
an eventual inclusion in master anyway or not.
I'm willing to do a rewrite if that's what it's going to take, but I
prefer to do it before any merge window opens, and I need pointers on
what needs to be rewritten. Just having the branch
Re: pr-msvc-support: building .DLLs with symbols
Hi Chris, Den 2009-09-18 12:16 skrev Christopher Hulbert: In my windows branch, I use link_search_path_spec as in: _LT_TAGDECL([], [link_search_path_spec], [1], [Flag to add a directory to the linker search path]) Then, somewhere in the -L* case of argument processing in func_mode_link. if test -n $link_search_path_spec; then this_deplib=$link_search_path_spec$dir else this_deplib=-L$dir fi where all cases of the existing -L$dir is replaced by $this_deplib. Note also that there is an explicit case for -LIBPATH:* so that -LIBPATH can be used in user-defined environment variables for example. My windows branch seems to work ok for the PGI and Intel compilers on windows with a couple exceptions: * running executables (e.g. test programs for the testsuite) that use DLLs. * building DLLs with version information. Are you suggesting that, when given this: $ .../libtool --mode=link ... -L/foo/bar ... libtool immediately munges that into an intermediate form: ... -LIBPATH:/foo/bar ... then, just before linking, moves the -LIBPATH: options to the LINK envvar: LINK= -LIBPATH:c:/some/mount/foo/bar cl ... so that link.exe sees them when cl.exe calls link.exe? Cheers, Peter
Re: pr-msvc-support: building .DLLs with symbols
On Fri, Sep 18, 2009 at 6:53 AM, Peter Rosin p...@lysator.liu.se wrote: Hi Chris, Den 2009-09-18 12:16 skrev Christopher Hulbert: In my windows branch, I use link_search_path_spec as in: _LT_TAGDECL([], [link_search_path_spec], [1], [Flag to add a directory to the linker search path]) Then, somewhere in the -L* case of argument processing in func_mode_link. if test -n $link_search_path_spec; then this_deplib=$link_search_path_spec$dir else this_deplib=-L$dir fi where all cases of the existing -L$dir is replaced by $this_deplib. Note also that there is an explicit case for -LIBPATH:* so that -LIBPATH can be used in user-defined environment variables for example. My windows branch seems to work ok for the PGI and Intel compilers on windows with a couple exceptions: * running executables (e.g. test programs for the testsuite) that use DLLs. * building DLLs with version information. Are you suggesting that, when given this: $ .../libtool --mode=link ... -L/foo/bar ... libtool immediately munges that into an intermediate form: ... -LIBPATH:/foo/bar ... then, just before linking, moves the -LIBPATH: options to the LINK envvar: LINK= -LIBPATH:c:/some/mount/foo/bar cl ... so that link.exe sees them when cl.exe calls link.exe? Not exactly. In the argument processing of func_mode_link, the deplibs variable is built up with the dependency libraries. Building that up, the -L is translated to $link_search_path_spec, and -LIBPATH is passed as used. In libtool.m4 under the cygwin/mingw case of _LT_LINKER_SHLIBS([TAGNAME]) (when not using GCC), I have a cc_basename case, and so for the PGI and Intel compilers on these platforms, I have the commands for building the libraries which includes $deplibs after a -link for the intel compiler because it follows the MSVC convention. The PGI compilers behave more like Linux so I don't have to worry about this. My case snippet is below. cygwin* | mingw* | pw32* | cegcc* | windows*) # When not using gcc, we currently assume that we are using # Microsoft Visual C++. # hardcode_libdir_flag_spec is actually meaningless, as there is # no search path for DLLs. _LT_TAGVAR(hardcode_libdir_flag_spec, $1)=' ' _LT_TAGVAR(allow_undefined_flag, $1)=unsupported # Tell ltmain to make .lib files, not .a files. libext=lib # Tell ltmain to make .dll files, not .so files. shrext_cmds=.dll case $cc_basename in pgcc* | pgCC* | pgcpp* | pgf77* | pgf90* | pgf95*) # Portland Group C,CPP, and Fortran compilers _LT_TAGVAR(archive_cmds, $1)='$CC -o $lib $libobjs $compiler_flags -Mmakedll $deplibs' _LT_TAGVAR(archive_expsym_cmds, $1)='$CC -o $lib $libobjs $compiler_flags -Mmakedll -def=$export_symbols $deplibs' _LT_TAGVAR(file_list_spec, $1)='-Wl,@' _LT_TAGVAR(compiler_needs_object, $1)='yes' ;; icl* | ifort*) # Intel C, CPP, and Fortran compilers _LT_TAGVAR(archive_cmds, $1)='$CC -o $lib $libobjs $compiler_flags -link -dll `func_echo_all $deplibs | $SED '\''s/ -lc$//'\''` ~linknames=' _LT_TAGVAR(archive_expsym_cmds, $1)='$CC -o $lib $libobjs $compiler_flags -link -dll -def:$export_symbols `func_echo_all $deplibs | $SED '\''s/ -lc$//'\''` ~linknames=' _LT_TAGVAR(file_list_spec, $1)='@' _LT_TAGVAR(link_search_path_spec, $1)='-LIBPATH:' _LT_TAGVAR(deplibs_separator, $1)='-link' ;; *) # FIXME: Setting linknames here is a bad hack. _LT_TAGVAR(archive_cmds, $1)='$CC -o $lib $libobjs $compiler_flags `func_echo_all $deplibs | $SED '\''s/ -lc$//'\''` -link -dll~linknames=' ;; esac # The linker will automatically build a .lib file if we build a DLL. _LT_TAGVAR(old_archive_from_new_cmds, $1)='true' # FIXME: Should let the user specify the lib program. _LT_TAGVAR(old_archive_cmds, $1)='lib -OUT:$oldlib$oldobjs$old_deplibs' _LT_TAGVAR(fix_srcfile_path, $1)='`cygpath -w $srcfile`' _LT_TAGVAR(enable_shared_with_static_runtimes, $1)=yes ;; Cheers, Peter
Re: pr-msvc-support: building .DLLs with symbols
Den 2009-09-18 14:01 skrev Christopher Hulbert: On Fri, Sep 18, 2009 at 6:53 AM, Peter Rosin p...@lysator.liu.se wrote: Hi Chris, Den 2009-09-18 12:16 skrev Christopher Hulbert: In my windows branch, I use link_search_path_spec as in: _LT_TAGDECL([], [link_search_path_spec], [1], [Flag to add a directory to the linker search path]) Then, somewhere in the -L* case of argument processing in func_mode_link. if test -n $link_search_path_spec; then this_deplib=$link_search_path_spec$dir else this_deplib=-L$dir fi where all cases of the existing -L$dir is replaced by $this_deplib. Note also that there is an explicit case for -LIBPATH:* so that -LIBPATH can be used in user-defined environment variables for example. My windows branch seems to work ok for the PGI and Intel compilers on windows with a couple exceptions: * running executables (e.g. test programs for the testsuite) that use DLLs. * building DLLs with version information. Are you suggesting that, when given this: $ .../libtool --mode=link ... -L/foo/bar ... libtool immediately munges that into an intermediate form: ... -LIBPATH:/foo/bar ... then, just before linking, moves the -LIBPATH: options to the LINK envvar: LINK= -LIBPATH:c:/some/mount/foo/bar cl ... so that link.exe sees them when cl.exe calls link.exe? Not exactly. In the argument processing of func_mode_link, the deplibs variable is built up with the dependency libraries. Building that up, the -L is translated to $link_search_path_spec, and -LIBPATH is passed as used. In libtool.m4 under the cygwin/mingw case of _LT_LINKER_SHLIBS([TAGNAME]) (when not using GCC), I have a cc_basename case, and so for the PGI and Intel compilers on these platforms, I have the commands for building the libraries which includes $deplibs after a -link for the intel compiler because it follows the MSVC convention. The PGI compilers behave more like Linux so I don't have to worry about this. My case snippet is below. *snip snippet* Ah, you are also adding -link right before all the $deplibs. Didn't think of that, but I'm not 100% sure if $deplibs can contain anything that has to be seen by cl.exe? I hope not... Apart from that, your suggestion will litter dependency_libs with -LIBPATH: and it will not work for absolute paths (unless you're using identity mounts, but that's cheating). That could perhaps be fixed but I think you will have trouble converting back to a posix path for dependency_libs in case of -L/absolute/path - -LIBPATH:c:/some/mount/absolute/path. There's no api for that in MSYS (that I know of). And you still need some way to get FLAG in behind that -link option in case someone feeds you -Wl,FLAG (which is a much better way to feed -LIBPATH: options from the outside, compared to having libtool also recognize -LIBPATH: as an alias for -L IMHO), or you are stuck with moving options to an envvar (or a command file). But I guess I could borrow your variable name and use my implementation. Ralf, is link_search_path_spec (or perhaps linker_search_path_spec in order to match linker_envvar) ok for what dashL_envvar_spec is currently doing? Cheers, Peter
pr-msvc-support rules and issues (was: Re: pr-msvc-support: building .DLLs with symbols)
Den 2009-09-10 11:48 skrev Peter Rosin: Here's a couple of patches that implements support for -Wl, and -Xlinker for MSVC. The first one (rename-dashL_envvar-tolinker_envvar.patch) is just a rename, to reduce confusion, and the second patch (-Xlinker-msvc.patch) contains the new code... Ok for the pr-msvc-support branch? Ping? David did say it works for him... I also want these patches commited ASAP since other branches in my git tree needs to be slightly tweaked because of these patches and it would just be easier to put that behind me instead of carrying different branches forward depending on the future of these two patches. What are the rules for the pr-msvc-support branch anyway? I have a whole bunch of patches that I would like to push, some of them I have not even bothered to send for review since the queue is so long and the dependencies on other non-approved patches makes it hard to describe how to apply them correctly. What I'm saying is that my git tree is getting closer and closer to a forrest and I'm getting tired at looking at testsuite failures only to discover that I have already solved the issue but that it was so long ago that I didn't even recognize the failure as an old failure at first. Personally, I want reviews and acks of anything going in there, since anything else is just going to come back and haunt us when it's eventually time for the merge. Which reminds me of the four commits that I pushed by mistake to the branch, namely: fbc144008bd66848111fb8ef2d7293b33957ea1a skip-on-no-reload 8c17887ee34e73a2aeb127b94f5b76f45dc34017 msvc-doc 2817364bb6efd20192c46edecfe085cbb288 embed-manifest 8c17887ee34e73a2aeb127b94f5b76f45dc34017 libtool-ar Apart from the fact that the commits have very dubious dates, and the fact the Ralf told me to leave them there, the last one (libtool-ar) must be given some attention before we merge. I have some further patches and some integration with automake to make lib.exe work better on that front, but I don't think it is any point in showing that before the following happens: I would really really like to see Chucks cross-compile-cwrapper patches pushed, that would significantly clean up my git dependencies and generally make my life easier (apart from paving the way to get the MinGW failure fixed in stresstest.at with low max_cmd_len, I have patches for that sitting and waiting, and MinGW is GNU so should receive a higher priority than some obscure MSVC patches). Pretty please! Cheers, Peter
Re: pr-msvc-support: building .DLLs with symbols
Hi Peter, * Peter Rosin wrote on Thu, Sep 10, 2009 at 11:48:34AM CEST: Here's a couple of patches that implements support for -Wl, and -Xlinker for MSVC. The first one (rename-dashL_envvar-tolinker_envvar.patch) is just a rename, to reduce confusion, In general, a rename from an ugly variable name like dashL_envvar is a good thing. However, it is also an API change that would normally need announcing in NEWS and asking ourselves why we messed up before and had to fix it. Luckily, this one is in pr-msvc-support only, not in master, so I don't have such a big problem with it. However, if you do it then please rename *all* instances of this ugliness (dashL_envvar_spec?). With that, I think the first patch is probably a good thing. and the second patch (-Xlinker-msvc.patch) contains the new code... And the @lt_linker@ thing is again so ugly it makes me cringe. No, really, I don't want to see code like this in master, that will be unmaintainable a year down the road. Why are we not looking for -Wl, and transforming that if linker_envvar is nonempty? And why does the description of linker_envvar not state that it also holds other link flags (is that maybe *not* true for some other systems on which this variable is used)? Does the expanded form of $wl ever get into .la files BTW? This would certainly make them unusable for another compiler later on (this is not something that is broken nor needs to be fixed with this patch, I'm just noting it here because I see it and this is one of the few systems where it makes a big difference.) Ok for the pr-msvc-support branch? Well, to me that depends upon whether you want to rewrite this code for an eventual inclusion in master anyway or not. Thanks, and sorry if that was a bit harsh, Ralf
Re: pr-msvc-support: building .DLLs with symbols
Den 2009-09-13 00:02 skrev David Byron: $ ../configure CC=cl CFLAGS='-MD -Zi' LD=link LDFLAGS='-Wl,-DEBUG' NM='dumpbin -symbols' AR=lib STRIP=: RANLIB=: --disable-static That will not work (as you noticed) as it will send the -Wl, option stright to cl when configure tries w/o libtool. Is there any hope of this working one day? What would it take? I suppose this is an autoconf issue, not a libtool one but am I wrong in thinking that in some more complete sense of msvc support that it should work? I don't think there's much hope for this particular isseu. I suppose that's one reason cccl and other wrapper scripts are used... I don't think other compiler drivers that use something other than -Wl, to pass linker flags through likes -Wl, in LDFLAGS during configure either. A quick scan through libtool.m4 hints that Sun C++ might be one such beast. Maybe there's need for something like LT_LDFLAGS? I blew away all the stuff related to autoreconf and re-ran it and now it works. If someone is interested in figuring out more about what's going on here, let me know and I'll revert the patches and re-test, etc. ... This works. ... So does this. Great! Cheers, Peter
Re: pr-msvc-support: building .DLLs with symbols
Hi David,
Thanks for testing!
Den 2009-09-11 21:04 skrev David Byron:
Here's a couple of patches that implements support for
-Wl, and -Xlinker for MSVC. The first one
(rename-dashL_envvar-tolinker_envvar.patch) is just a
rename, to reduce confusion, and the second patch
(-Xlinker-msvc.patch) contains the new code...
Ok for the pr-msvc-support branch?
I'm not sure I'm exercising the patch properly, but here's what I did:
- applied the patch
$ patch -p1 rename-dashL_envvar-tolinker_envvar.patch
$ patch -p1 -Xlinker-msvc.patch
- re-built libtool
$ cd build
$ make
$ make install
Then in one of my modules:
$ autoreconf -fvi
$ mkdir Debug
$ cd Debug
$ ../configure CC=cl CFLAGS='-MD -Zi' LD=link NM='dumpbin -symbols' AR=lib
STRIP=: RANLIB=: --disable-static
So far so good. But,
$ ../configure CC=cl CFLAGS='-MD -Zi' LD=link LDFLAGS='-Wl,-DEBUG'
NM='dumpbin -symbols' AR=lib STRIP=: RANLIB=: --disable-static
That will not work (as you noticed) as it will send the -Wl, option
stright to cl when configure tries w/o libtool.
checking for a BSD-compatible install... /bin/install -c
checking whether build environment is sane... yes
checking for a thread-safe mkdir -p... /bin/mkdir -p
checking for gawk... gawk
checking whether make sets $(MAKE)... yes
checking for gcc... cl
checking for C compiler default output file name...
configure: error: in `abs_path_to/build':
configure: error: C compiler cannot create executables
See `config.log' for more details.
and config.log has:
configure:2791: checking for C compiler default output file name
configure:2813: cl -MD -Zi -Wl,-DEBUG conftest.c 5
Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 14.00.50727.762 for
80x86 Copyright (C) Microsoft Corporation. All rights reserved. cl :
Command line error D8021 : invalid numeric argument '/Wl,-DEBUG'
configure:2817: $? = 2
configure:2855: result:
configure: failed program was:
| /* confdefs.h. */
| #define PACKAGE_NAME foo
| #define PACKAGE_TARNAME foo
| #define PACKAGE_VERSION 1.0
| #define PACKAGE_STRING foo 1.0
| #define PACKAGE_BUGREPORT
| #define PACKAGE foo
| #define VERSION 1.0
| /* end confdefs.h. */
|
| int
| main ()
| {
|
| ;
| return 0;
| }
configure:2861: error: in
`/c/utils/cygwin/home/dbyron/src/ams_svn/AMS_SDK/trunk/final_review/build':
configure:2864: error: C compiler cannot create executables
If I go back to the working configure invocation, but change my Makefile.am
with:
libfoo_la_LDFLAGS += -Wl,-DEBUG
The resulting library doesn't contain debug symbols. Here's the libtool
invocation that creates the library:
*snip*
Should I be doing something else?
Probably, works for metm. Maybe your autoreconf didn't really take for some
reason? (I haven't worked too much with autoreconf, and don't really know what
to expect from it)
Linking a program:
$ echo int main(void) { return 0; } main.c
$ ./libtool --tag=CC --mode=link cl -o main main.c -Wl,-DEBUG
libtool: link: LINK= -DEBUG cl -o .libs/main main.c
Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 14.00.50727.762 for 80x86
Copyright (C) Microsoft Corporation. All rights reserved.
cl : Command line warning D9035 : option 'o' has been deprecated and will be
removed in a future release
main.c
Microsoft (R) Incremental Linker Version 8.00.50727.762
Copyright (C) Microsoft Corporation. All rights reserved.
-DEBUG
/out:main.exe
/out:.libs/main.exe
main.obj
libtool: link: lt_outputfile=.libs/main
libtool: link: case .libs/main in *.[eE][xX][eE]) ;; *)
lt_outputfile=.libs/main.exe ;; esac
libtool: link: if test -e .libs/main.exe.manifest; then mt -manifest
.libs/main.exe.manifest -outputresource:.libs/main.exe || exit 1; rm -f .libs/main.
exe.manifest; fi
Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 14.00.50727.762 for 80x86
Copyright (C) Microsoft Corporation. All rights reserved.
cl : Command line warning D9035 : option 'o' has been deprecated and will be
removed in a future release
lt-main.c
Microsoft (R) Incremental Linker Version 8.00.50727.762
Copyright (C) Microsoft Corporation. All rights reserved.
/out:lt-main.exe
/debug
/out:./main.exe
lt-main.obj
Linking a library:
$ echo int foo(void) { return 0; } foo.c
$ ./libtool --tag=CC --mode=compile ../libltdl/config/compile cl -o foo.lo -c
foo.c
libtool: compile: ../libltdl/config/compile cl -c -TC foo.c -DDLL_EXPORT
-DPIC -o .libs/foo.obj
Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 14.00.50727.762 for 80x86
Copyright (C) Microsoft Corporation. All rights reserved.
foo.c
libtool: compile: ../libltdl/config/compile cl -c -TC foo.c -o foo.obj /dev/null
21
$ ./libtool --tag=CC --mode=link ../libltdl/config/compile cl -o libfoo.la
foo.lo -Wl,-DEBUG -no-undefined -rpath /nowhere
libtool: link: rm -fr .libs/foo.exp .libs/foo.lib .libs/libfoo.la
libtool: link: dumpbin -symbols .libs/foo.obj | gawk ' {last_section=section; section=$ 3}; /Section length .*#relocs.*(pick any)/{hide[last_section]=1}; $
RE: pr-msvc-support: building .DLLs with symbols
$ ../configure CC=cl CFLAGS='-MD -Zi' LD=link LDFLAGS='-Wl,-DEBUG'
NM='dumpbin -symbols' AR=lib STRIP=: RANLIB=: --disable-static
That will not work (as you noticed) as it will send the -Wl, option
stright to cl when configure tries w/o libtool.
Is there any hope of this working one day? What would it take? I suppose
this is an autoconf issue, not a libtool one but am I wrong in thinking that
in some more complete sense of msvc support that it should work?
If I go back to the working configure invocation, but
change my Makefile.am
with:
libfoo_la_LDFLAGS += -Wl,-DEBUG
The resulting library doesn't contain debug symbols.
Here's the libtool invocation that creates the library:
*snip*
Should I be doing something else?
Probably, works for metm. Maybe your autoreconf didn't
really take for some reason? (I haven't worked too much
with autoreconf, and don't really know what to expect from
it)
I blew away all the stuff related to autoreconf and re-ran it and now it
works. If someone is interested in figuring out more about what's going on
here, let me know and I'll revert the patches and re-test, etc.
Linking a program:
$ echo int main(void) { return 0; } main.c
$ ./libtool --tag=CC --mode=link cl -o main main.c -Wl,-DEBUG
This works.
Linking a library:
$ echo int foo(void) { return 0; } foo.c
$ ./libtool --tag=CC --mode=compile ../libltdl/config/compile
cl -o foo.lo -c foo.c
$ ./libtool --tag=CC --mode=link ../libltdl/config/compile cl
-o libfoo.la foo.lo -Wl,-DEBUG -no-undefined -rpath /nowhere
So does this.
Thanks for your help.
-DB
RE: pr-msvc-support: building .DLLs with symbols
Here's a couple of patches that implements support for
-Wl, and -Xlinker for MSVC. The first one
(rename-dashL_envvar-tolinker_envvar.patch) is just a
rename, to reduce confusion, and the second patch
(-Xlinker-msvc.patch) contains the new code...
Ok for the pr-msvc-support branch?
I'm not sure I'm exercising the patch properly, but here's what I did:
- applied the patch
$ patch -p1 rename-dashL_envvar-tolinker_envvar.patch
$ patch -p1 -Xlinker-msvc.patch
- re-built libtool
$ cd build
$ make
$ make install
Then in one of my modules:
$ autoreconf -fvi
$ mkdir Debug
$ cd Debug
$ ../configure CC=cl CFLAGS='-MD -Zi' LD=link NM='dumpbin -symbols' AR=lib
STRIP=: RANLIB=: --disable-static
So far so good. But,
$ ../configure CC=cl CFLAGS='-MD -Zi' LD=link LDFLAGS='-Wl,-DEBUG'
NM='dumpbin -symbols' AR=lib STRIP=: RANLIB=: --disable-static
checking for a BSD-compatible install... /bin/install -c
checking whether build environment is sane... yes
checking for a thread-safe mkdir -p... /bin/mkdir -p
checking for gawk... gawk
checking whether make sets $(MAKE)... yes
checking for gcc... cl
checking for C compiler default output file name...
configure: error: in `abs_path_to/build':
configure: error: C compiler cannot create executables
See `config.log' for more details.
and config.log has:
configure:2791: checking for C compiler default output file name
configure:2813: cl -MD -Zi -Wl,-DEBUG conftest.c 5
Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 14.00.50727.762 for
80x86 Copyright (C) Microsoft Corporation. All rights reserved. cl :
Command line error D8021 : invalid numeric argument '/Wl,-DEBUG'
configure:2817: $? = 2
configure:2855: result:
configure: failed program was:
| /* confdefs.h. */
| #define PACKAGE_NAME foo
| #define PACKAGE_TARNAME foo
| #define PACKAGE_VERSION 1.0
| #define PACKAGE_STRING foo 1.0
| #define PACKAGE_BUGREPORT
| #define PACKAGE foo
| #define VERSION 1.0
| /* end confdefs.h. */
|
| int
| main ()
| {
|
| ;
| return 0;
| }
configure:2861: error: in
`/c/utils/cygwin/home/dbyron/src/ams_svn/AMS_SDK/trunk/final_review/build':
configure:2864: error: C compiler cannot create executables
If I go back to the working configure invocation, but change my Makefile.am
with:
libfoo_la_LDFLAGS += -Wl,-DEBUG
The resulting library doesn't contain debug symbols. Here's the libtool
invocation that creates the library:
/bin/sh ./libtool --tag=CC --mode=link cl -MD -Zi -no-undefined
-export-symbols symfile -Wl,-DEBUG -o libfoo.la -rpath /usr/loca
l/lib libfoo_la-public.lo libfoo_la-private.lo
libtool: link: dumpbin -symbols .libs/libfoo_la-public.obj
.libs/libfoo_la-private.obj | gawk ' {last_section=section; sectio
n=$ 3}; /Section length .*#relocs.*(pick any)/{hide[last_section]=1};
$ 0!~/External *\|/{next}; / 0+ UNDEF /{next}; / U
NDEF \([^|]\)*()/{next}; {if(hide[section]) next}; {f=0}; $
0~/\(\).*\|/{f=1}; {printf f ? T : D }; {split($ 0, a,
/\||\r/); split(a[2], s)}; s[1]~/^...@?]/{print s[1], s[1]; next};
s[1]~prfx {split(s[1],t,@); print t[1], substr(t[1],lengt
h(prfx))} ' prfx=^_ | /bin/sed -e '/^[BCDGRS][ ]/s/.*[ ]\([^
]*\)/\1,DATA/' | /bin/sed -e '/^[AITW][ ]/s/.*[ ]//' | sort | uniq
.libs/foo.exp
libtool: link: if test x`/bin/sed 1q .libs/foo.def` = xEXPORTS; then sed
-n -e s/\\\(.*\\\)/-link\ -EXPORT:\\\1/ -e 1\!p .libs/f
oo.def .libs/foo-0.dll.exp; else sed -e s/\\\(.*\\\)/-link\ -EXPORT:\\\1/
.libs/foo.def .libs/foo-0.dll.exp; fi
libtool: link: cl -o .libs/foo-0.dll .libs/libfoo_la-public.obj
.libs/libfoo_la-private.obj -DEBUG@.libs/foo-0.dll.exp -link
-DLL
Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 14.00.50727.762 for
80x86
Copyright (C) Microsoft Corporation. All rights reserved.
cl : Command line warning D9035 : option 'o' has been deprecated and will be
removed in a future release
Microsoft (R) Incremental Linker Version 8.00.50727.762
Copyright (C) Microsoft Corporation. All rights reserved.
/out:libfoo_la-public.exe
/out:.libs/foo-0.dll
-DLL
.libs/libfoo_la-public.obj
.libs/libfoo_la-private.obj
Creating library .libs/foo-0.lib and object .libs/foo-0.exp
libtool: link: linknames=
libtool: link: rm -f .libs/foo.exp .libs/foo.filter
libtool: link: LINK=
libtool: link: ( cd .libs rm -f libfoo.la cp -p ../libfoo.la
libfoo.la )
Should I be doing something else?
-DB
Re: pr-msvc-support: building .DLLs with symbols
Hi David,
(moving to libtool-patc...@...)
Den 2009-09-03 20:24 skrev David Byron:
You want to send -DEBUG to link.exe, not to cl.exe. I'm
sure you know this, but simply adding -DEBUG to LDFLAGS is
not the way you do this. The correct way would be to use
-Wl,-DEBUG. If the msvc stuff were complete, libtool would
then feed -DEBUG to the linker. But this does not
currently work, and the main reason is that the -link
option to cl.exe is different. It feeds all options
(instead of just one) after the -link option on the
command line to the linker, so it would be very bad to
just transform -Wl,foo into -link foo.
Makes sense.
Can someone show me how to do this without hacking the
libtool file?
You can work around the above -Wl,foo limitation in two
ways.
2) Use a response file, like this:
$ cat linkdebug
-link -DEBUG
$ /bin/sh ./libtool --tag=CC --mode=link cl @linkdebug -MD -Zi \
-no-undefined -export-symbols symfile -o libfoo.la \
-rpath /usr/local/lib libfoo_la-public.lo libfoo_la-private.lo
This works well, though way I integrated it with autoconf and automake is a
bit cumbersome. Trouble is, it works so it's harder to motivate to dive in
and fix libtool to do the right thing with -Wl,-DEBUG.
Here's a couple of patches that implements support for -Wl, and
-Xlinker for MSVC. The first one (rename-dashL_envvar-tolinker_envvar.patch)
is just a rename, to reduce confusion, and the second patch
(-Xlinker-msvc.patch) contains the new code...
Ok for the pr-msvc-support branch?
Cheers,
Peter
2009-09-09 Peter Rosin p...@lysator.liu.se
Make -Wl,FLAG and -Xlinker FLAG work on MSVC.
* libltdl/m4/libtool.m4 (_LT_COMPILER_PIC) [MSVC]: Set
lt_prog_compiler_wl to @lt_envvar@ to signal that linker options
should be passed via the $linker_envvar variable.
* libltdl/config/ltmain.m4sh (func_to_linker_envvar): Also move
@lt_output@ options to the $linker_envvar variable.
(func_mode_link) [linkmode=lib]: Look for options to move to the
$linker_envvar in $compiler_flags as well. Echo the final
content of the linker_envvar.
(func_mode_link) [linkmode=prog]: Look for options to move to the
$linker_envvar in $compile_command and $finalize_command as well.
* tests/flags.at: Don't expect to find @lt_envvar@ in the output
if $wl is set to that.
* doc/libtool.texi (linker_envvar): Document the @lt_envvar@ hook.
2009-09-09 Peter Rosin p...@lysator.liu.se
Rename dashL_envvar into linker_envvar.
* libltdl/m4/libtool.m4 (_LT_LINKER_SHLIBS, _LT_LANG_CXX_CONFIG):
Rename dashL_envvar into linker_envvar. The new name makes it
less confusing to pass other linker options via the variable.
* libltdl/config/ltmain.m4sh (func_dashL_to_envvar): Rename...
(func_to_linker_envvar): ...to this, and operate on linker_envvar
instead of dashL_envvar.
(func_mode_link): Adjust to above renames.
* doc/libtool.texi: Document changes.
diff --git a/doc/libtool.texi b/doc/libtool.texi
index 610117e..9aa3d4b 100644
--- a/doc/libtool.texi
+++ b/doc/libtool.texi
@@ -5876,13 +5876,6 @@ convenience archives or a set of object file names can
be passed via
linker-specific options or linker scripts.
@end defvar
-...@defvar dashL_envvar
-When linking, move all paths specified with @option{-L} options to
-this variable, for toolchains where it makes sense to pass the library
-search paths in an environment variable. Normally disabled (i.e.
-...@var{dashl_envvar} empty).
-...@end defvar
-
@defvar dashL_envvar_spec
When moving library search paths with @var{dashL_envvar}, prepend this
to each @option{-L} path that is added to @var{dashL_envvar}. Unused
@@ -6107,6 +6100,13 @@ Linker flag (passed through the C compiler) used to
prevent dynamic
linking.
@end defvar
+...@defvar linker_envvar
+When linking, move all paths specified with @option{-L} options to
+this variable, for toolchains where it makes sense to pass the library
+search paths in an environment variable. Normally disabled (i.e.
+...@var{linker_envvar} empty).
+...@end defvar
+
@defvar macro_version
@defvarx macro_revision
The release and revision from which the libtool.m4 macros were
diff --git a/libltdl/config/ltmain.m4sh b/libltdl/config/ltmain.m4sh
index 40ff9d3..5fc8d0b 100644
--- a/libltdl/config/ltmain.m4sh
+++ b/libltdl/config/ltmain.m4sh
@@ -634,8 +634,8 @@ func_infer_tag ()
}
-# func_dashL_to_envvar deplibs_variable deplibs...
-func_dashL_to_envvar ()
+# func_to_linker_envvar deplibs_variable deplibs...
+func_to_linker_envvar ()
{
deplibs_variable=$1
shift
@@ -653,7 +653,7 @@ func_dashL_to_envvar ()
env_path=`cygpath -w $env_path`
;;
esac
- eval $dashL_envvar=\\$$dashL_envvar $dashL_envvar_spec$env_path\
+ eval $linker_envvar=\\$$linker_envvar $dashL_envvar_spec$env_path\
;;
*)
tmp_libs=$tmp_libs $deplib
@@
