[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: pr-msvc-support: building .DLLs with symbols
From: |
Christopher Hulbert |
Subject: |
Re: pr-msvc-support: building .DLLs with symbols |
Date: |
Fri, 18 Sep 2009 08:01:01 -0400 |
On Fri, Sep 18, 2009 at 6:53 AM, Peter Rosin <address@hidden> 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, Peter Rosin, 2009/09/10
- pr-msvc-support rules and issues (was: Re: pr-msvc-support: building .DLLs with symbols), Peter Rosin, 2009/09/17
- Re: pr-msvc-support: building .DLLs with symbols, Ralf Wildenhues, 2009/09/18
- Re: pr-msvc-support: building .DLLs with symbols, Peter Rosin, 2009/09/18
- Re: pr-msvc-support: building .DLLs with symbols, Christopher Hulbert, 2009/09/18
- Re: pr-msvc-support: building .DLLs with symbols, Peter Rosin, 2009/09/18
- Re: pr-msvc-support: building .DLLs with symbols,
Christopher Hulbert <=
- Re: pr-msvc-support: building .DLLs with symbols, Peter Rosin, 2009/09/18
- Re: pr-msvc-support: building .DLLs with symbols, Christopher Hulbert, 2009/09/21
- Re: pr-msvc-support: building .DLLs with symbols, Peter Rosin, 2009/09/21
- Re: pr-msvc-support: building .DLLs with symbols, Christopher Hulbert, 2009/09/21
- Re: pr-msvc-support: building .DLLs with symbols, Peter Rosin, 2009/09/22