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
