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 >