Re: Repost: [PATCH] [cygwin|mingw] Create UAC manifest files.
On Tue, Feb 23, 2010 at 2:20 AM, Yaakov (Cygwin/X) yselkow...@users.sourceforge.net wrote: On 2010-02-21 06:11, Ralf Wildenhues wrote: 3) This patch will overwrite a .manifest file created in the build dir, thus may break a package that create them through some other means. I can't see any package generating one of these. If a package uses a .manifest file, it will be hand-written, shipped in $srcdir, and compiled in to the application, so the bigger worry is making sure that with in-tree builds we don't overwrite an existing file. Will any of this break the situation where a compiler generates a manifest file? Both the Intel and PGI native Windows compilers that I use create manifest file right next to DLLs and EXEs. I believe the thread is referring to executables that match specific names, but I just want to make sure it does not affect the general case. Chris Note that here, I'm not speaking about the manifest below .libs, and I understand that that is necessary as well, and that if the user creates one, it is probably a bug that we don't use that for the to-be-installed program; not sure if it's always harmless to then-reuse that for the cwrapper as well. It better not be, because with an in-tree build, a shipped .manifest will not only be compiled in to the real executable (so a copy in .libs shouldn't be necessary) but will end up being used by the cwrapper as well. 4) How many code instances does this patch help *in practice*? I suppose you guys know since you've used this for a lot of packages, but couldn't find data in the cited email threads. I'd like to gauge the importance of this being fixed in libtool against the regressions this patch may cause, and the cost of waiting (or not waiting) for an Automake fix to propagate. Any package which uses libtool and creates programs whose names match the specified pattern requires these .manifest files. As for which libtoolized packages require this right now, I am aware of *at least* the following: bind desktop-file-utils GeoIP gtk+ rarian WindowMaker This list is based on installed program names, but there might very well be more packages whose noinst_PROGRAMS or check_PROGRAMS trigger this. The alternative to this patch would be workarounds in said packages to add explicit code to create embedded manifests (that then apply to the to-be-installed program). We'd still need a manifest for the cwrapper. Hmm, that means waiting for (2) is moot, unless we embed a manifest into the cwrapper. Ugh. Remember that the packages with which we are dealing are designed for *NIX systems and therefore won't have their own manifests nor would an invasive patch to add a compiled-in manifest likely be accepted. Yaakov Cygwin Ports
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
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
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
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
Patch to support PGI compiler option to append libraries to the link step
PGI has compiler options to append libraries for PGI-compiled fortran and C++ code when performing a link. The attached patch lets ltmain.m4sh recognize them. diff --git a/libltdl/config/ltmain.m4sh b/libltdl/config/ltmain.m4sh index 6f44d35..795bf4a 100644 --- a/libltdl/config/ltmain.m4sh +++ b/libltdl/config/ltmain.m4sh @@ -4496,8 +4496,10 @@ func_mode_link () # -p, -pg, --coverage, -fprofile-* pass through profiling flag for GCC # @file GCC response files # -tp=* Portland pgcc target processor selection + # -pgf77libs, -pgf90libs, -pgcpplibs Portland compiler opts to append lib -64|-mips[0-9]|-r[0-9][0-9]*|-xarch=*|-xtarget=*|+DA*|+DD*|-q*|-m*| \ - -t[45]*|-txscale*|-p|-pg|--coverage|-fprofile-*|-F*|@*|-tp=*) + -t[45]*|-txscale*|-p|-pg|--coverage|-fprofile-*|-F*|@*|-tp=*|-pgcpplibs| + -pgf77libs|-pgf90libs) func_quote_for_eval $arg arg=$func_quote_for_eval_result func_append compile_command $arg pgi_libs.patch Description: Binary data
Re: Patch to support PGI compiler option to append libraries to the link step
On Tue, Jun 16, 2009 at 2:05 PM, Ralf Wildenhuesralf.wildenh...@gmx.de wrote: Hello Christopher, * Christopher Hulbert wrote on Tue, Jun 16, 2009 at 05:40:09PM CEST: PGI has compiler options to append libraries for PGI-compiled fortran and C++ code when performing a link. The attached patch lets ltmain.m4sh recognize them. Please explain what these switches do (or point to documentation), so we can find out whether it's the right thing for libtool to just ignore and pass through these switches, or whether it would need to take any further action. -pgcpplibs Append C++ libraries to the link line -pgf77libs Append pgf77 libraries to the link line -pgf90libs Append pgf90 libraries to the link line More documentation can be found in the PGI users guide (http://www.pgroup.com/doc/pgiug.pdf). Other than that, you can use `-Wc,FLAG' or `-Xcompiler FLAG' to get flags by libtool, undetected, as a workaround. I know how to get flags by libtool. It didn't seem these were any less useful than the -tp switches, so I submitted it. Instead of using the autoconf-generated FCLIBS information from AC_FC_LIBRARY_LDFLAGS, I set FCLIBS=-pgf90libs. That flag gets put into my pkg-config file Libs information. Then when using pkg-config --libs, the -pgf90libs flag shows up, but libtool strips it out. Chris Thanks, Ralf --- a/libltdl/config/ltmain.m4sh +++ b/libltdl/config/ltmain.m4sh @@ -4496,8 +4496,10 @@ func_mode_link () # -p, -pg, --coverage, -fprofile-* pass through profiling flag for GCC # @file GCC response files # -tp=* Portland pgcc target processor selection + # -pgf77libs, -pgf90libs, -pgcpplibs Portland compiler opts to append lib -64|-mips[0-9]|-r[0-9][0-9]*|-xarch=*|-xtarget=*|+DA*|+DD*|-q*|-m*| \ - -t[45]*|-txscale*|-p|-pg|--coverage|-fprofile-*|-F*|@*|-tp=*) + -t[45]*|-txscale*|-p|-pg|--coverage|-fprofile-*|-F*|@*|-tp=*|-pgcpplibs| + -pgf77libs|-pgf90libs)
Re: Windows compilers
On Wed, May 13, 2009 at 2:11 PM, Ralf Wildenhues ralf.wildenh...@gmx.de wrote: Hello Christopher, * Christopher Hulbert wrote on Wed, May 13, 2009 at 01:14:47PM CEST: 1. What's the future of that branch? Is it ever likely to merge into master to become part of a libtool release and have a larger support base? Bob addressed this already. 2. Based on (1), should I use/modify that branch or make modifications to my own copy of master. I already have a branch modified from master that works well with PGI on Windows. Well, you can show what you have. If it overlaps a lot with the branch, it would likely be good to base it on that. It was pretty close to the master before I started adding some stuff for the Intel compilers. It's still not nearly as different as the pr-msvc-support branch. Then again, I have not tested it extensively and I am not intimately familiar with the libtool script, so I am likely missing some cases. Anyways, the diff and logs are attached. I've also CC'd the patches list. 3. Checking for non-libtool libraries using autoconf (e.g. Intel MKL) requires knowing whether the compiler uses the MSVC or -L/-l format when linking (at least for the few platforms I am working with). Is it possible to develop an LT_TRY_LINK m4 macro that can handle that? Unfortunately I think the libtool program is not created until the end of the configure script. Would a macro like LT_TRY_LINK even be desired by other libtool users? Perhaps it already exists? You can use LT_OUTPUT which will create the libtool script right then. Interesting. I'll have to check that out. I was thinking it was done the same way as AC_CONFIG_FILES. I wonder if you can call AC_OUTPUT more than once. 4. Not being a shell-scripting black-belt and not having a lot of time to spend analyzing the libtool source, the 8000+ line ltmain.m4sh program is extremely difficult to navigate. I have managed relatively small hacks to it, but some sort of flowchart might be really nice for people like myself. Yes, I realize that it takes people time and effort to develop, so don't think I'm just nagging for it. I would be happy to help with it, but again I don't understand enough of libtool to make it happen. Please describe the things you want to have work or the issues you see (both as high level as you can possibly do, as well as as specific as you can do, with a command sequence showing failures). One issue is func_mode_link is gigantic. If I counted right, it's on the order of 4000+ lines. Trying to find where certain steps occurred has been a little rough. If there was some sort of flow chart that showed the steps in there with pointers into the source, that would be helpful. Chris Thanks, Ralf hulbert_windows.tar.gz Description: GNU Zip compressed data
Re: shared libraries on darwin using Intel compiler
On Fri, Jun 13, 2008 at 11:55 AM, Peter O'Gorman [EMAIL PROTECTED] wrote: Christopher Hulbert wrote: GIT version still reports that the ifort linker does not support shared libraries. The config.log is attached. Hi Chris, Your config.log confirms that ifort does not define __GNUC__, thanks. Could you confirm that this patch fixes it. Yes, the ifort linker now supports shared libraries. Chris Peter -- Peter O'Gorman http://pogma.com
lt__private.h patch for windows targets without unistd.h
This patch defined R_OK to what I think it should be for windows and changes access to _access. I think MS has access in an oldnames library, but I chose to redefine it since according to MS, the POSIX name access is deprecated (http://msdn2.microsoft.com/en-us/library/ms235395(vs.80).aspx). Chris Index: libltdl/libltdl/lt__private.h === RCS file: /sources/libtool/libtool/libltdl/libltdl/lt__private.h,v retrieving revision 1.13 diff -u -r1.13 lt__private.h --- libltdl/libltdl/lt__private.h 25 Mar 2007 12:12:43 - 1.13 +++ libltdl/libltdl/lt__private.h 4 Apr 2007 14:08:56 - @@ -45,6 +45,9 @@ #if defined(HAVE_UNISTD_H) # include unistd.h +#elif defined (_WIN32) || defined (_WIN64) +# define access(a,b) _access(a,b) +# define R_OK 4 #endif /* Import internal interfaces... */
ltmain.m4sh patch for cwrappersource
The attached patch allows compilers without unistd.h to generate
executables on windows 32 and 64-bit. This may not be the desired
version since it will be active on at least the MINGW host. On the
other hand, MINGW will support the code so it may not be a big deal.
Note: The relevant hunks of the patch are 2, 3, and 4.
Chris
Index: libltdl/config/ltmain.m4sh
===
RCS file: /sources/libtool/libtool/libltdl/config/ltmain.m4sh,v
retrieving revision 1.71
diff -u -r1.71 ltmain.m4sh
--- libltdl/config/ltmain.m4sh 25 Mar 2007 12:12:42 - 1.71
+++ libltdl/config/ltmain.m4sh 3 Apr 2007 18:29:55 -
@@ -5485,7 +5485,7 @@
# Create links to the real library.
for linkname in $linknames; do
- if test $realname != $linkname; then
+ if test $realname != $linkname ! -e $output_objdir/$linkname;then
func_show_eval '(cd $output_objdir $RM $linkname $LN_S $realname $linkname)' 'exit $?'
fi
done
@@ -5961,7 +5961,12 @@
cat $cwrappersourceEOF
#include stdio.h
#include stdlib.h
-#include unistd.h
+#if defined(_WIN32) || defined(_WIN64)
+# include direct.h
+# define getcwd(a,b) _getcwd(a,b)
+#else
+# include unistd.h
+#endif
#include malloc.h
#include stdarg.h
#include assert.h
@@ -5982,8 +5987,8 @@
# define PATH_SEPARATOR ':'
#endif
-#if defined (_WIN32) || defined (__MSDOS__) || defined (__DJGPP__) || \
- defined (__OS2__)
+#if defined (_WIN32) || defined (_WIN64) || defined (__MSDOS__) || \
+ defined (__DJGPP__) || defined (__OS2__)
# define HAVE_DOS_BASED_FILE_SYSTEM
# ifndef DIR_SEPARATOR_2
# define DIR_SEPARATOR_2 '\\'
@@ -6134,7 +6139,11 @@
#if defined (S_IXGRP)
((st.st_mode S_IXGRP) == S_IXGRP) ||
#endif
+#if defined (S_IXUSR)
((st.st_mode S_IXUSR) == S_IXUSR))
+#else
+ 1)
+#endif
)
return 1;
else
@@ -6591,6 +6600,11 @@
do
last_oldobj=$obj
done
+ if test x$with_msvc_ld = xyes;then
+oldobjs= $last_oldobj
+func_show_eval $old_archive_cmds
+objlist= $oldlib
+ fi
for obj in $save_oldobjs
do
oldobjs=$objlist $obj
@@ -6607,7 +6621,11 @@
fi
test -z $concat_cmds || concat_cmds=$concat_cmds~
eval concat_cmds=\\${concat_cmds}$old_archive_cmds\
- objlist=
+ if test x$with_msvc_ld = xyes;then
+objlist= $oldlib
+ else
+objlist=
+ fi
fi
done
RANLIB=$save_RANLIB
Re: ltmain.m4sh patch for cwrappersource
On 4/3/07, Ralf Wildenhues [EMAIL PROTECTED] wrote: Hello Christopher, * Christopher Hulbert wrote on Tue, Apr 03, 2007 at 08:36:02PM CEST: The attached patch allows compilers without unistd.h to generate executables on windows 32 and 64-bit. This may not be the desired version since it will be active on at least the MINGW host. On the other hand, MINGW will support the code so it may not be a big deal. Thanks for your patch. But really when porting to a w64 system (including a specific compiler and toolset), I'd prefer a reasonably complete port, at least including testsuite output and the like, so we can tell our users what to expect. I imagine it needs several more changes, at least for libltdl. What about without the _WIN64 defines? I can work around that. I've never had much luck running the testsuite. Cheers, Ralf
Import libraries on win32
PGI compilers have an option to create an import library on windows. The libtool default on windows (without any patches) is to create a link to the dll for the .lib file. This obviously doesn't work. I am not sure what the side-effects of the following patch is so I'm submitting it here for comments. Is there ever a time that the lib file will exist and libtool should remove it before creating the link? Chris Index: libltdl/config/ltmain.m4sh === RCS file: /sources/libtool/libtool/libltdl/config/ltmain.m4sh,v retrieving revision 1.56 diff -u -r1.56 ltmain.m4sh --- libltdl/config/ltmain.m4sh 22 Oct 2006 14:10:33 - 1.56 +++ libltdl/config/ltmain.m4sh 2 Jan 2007 20:12:42 - @@ -5402,7 +5402,7 @@ # Create links to the real library. for linkname in $linknames; do - if test $realname != $linkname; then + if test $realname != $linkname -a ! -e $output_objdir/$linkname;then func_show_eval '(cd $output_objdir $RM $linkname $LN_S $realname $linkname)' 'exit $?' fi done
Re: PGI Compiler patch for cygwin
On 2/18/06, Ralf Wildenhues [EMAIL PROTECTED] wrote: Hi Christopher, * Christopher Hulbert wrote on Wed, Feb 15, 2006 at 04:08:33PM CET: The attached patch fixes the empty wl variable and the MS toolchain assumption of -link -dll. The patch is ok, could you be bothered to run the testsuite once, verbosely make check VERBOSE=x TESTSUITE_FLAGS=-V make check-local and send (packed) the output and tests/testsuite.log, so we could hash out any other simple issues for decent support? Thanks, Ralf pgi_patch_testsuite.tar.bz2 Description: BZip2 compressed data
Re: PGI Compiler patch for cygwin
On 2/21/06, Ralf Wildenhues [EMAIL PROTECTED] wrote: Hi Christopher, * Christopher Hulbert wrote on Tue, Feb 21, 2006 at 03:15:42PM CET: Attached is the test outputs. Thanks. Unfortunately, I was not precise enough: Please configure Libtool with the Portland compilers, so that they are tested. E.g., like ./configure CC=pgcc CXX=pgCC F77=pgf77 FC=pgf95 duh, I feel braindead :)! Sorry about that. :-( Please note that the tarball you sent did not contain tests/testsuite.log. It appears make_check_local was misplaced: there is a duplicate, packed copy of make_check in there. It'd be great if you could send the testsuite.log file as well, and the other output with the above configuration. Yeah, got an error that I couldn't append to a compressed tar archive so that didn't make it :/. Not that it mattered since I used the wrong C compiler. But also see below: I looked at the failure for fcdemo. It looks like autoconf's AC_FC_LIBRARY_LDFLAGS is not picking up the PGI libraries because they are wrapped in single quotes, i.e. '-Lc:\Program Files\PGI/nt86/6.0/lib'. Hmpf. That'll be difficult to get both fixed in _AC_PROG_FC_V_OUTPUT and also all the way through Autoconf and Libtool so the embedded space isn't killed (or the path broken in two arguments). Not sure what's going on here. I use the AC_FC_LIBRARY_LDFLAGS in my configure.ac and I don't get that problem. libtool's configure must be quoting each of these arguments??? I should note that I had to patch fortran.m4 (a long time ago) to handle a case where the library was butted up against a single quote such as 'blah blah -lm'. I thought I sent that info to the autoconf list a while ago??? Probably it would currently be best (for Fortran users) to - either install the compiler under a path not containing spaces, or - create a config.site file for this compiler/system combination, with ac_cv_fc_libs pre-seeded with the right flags for Fortran, and alternate non-space path representations; on your system, that would be something like ac_cv_fc_libs='-Lc:/Progra~1/PGI/nt86/6.0/mingw/lib -Lc:/Progra~1/PGI/nt86/6.0/mingw/mingw32/lib -Lc:/Progra~1/PGI/nt86/6.0/mingw/lib/gcc-lib/mingw32/2.95.3-5 -Lc:/Progra~1/PGI/nt86/6.0/lib -lpgf90 -lpgf90_rpm1 -lpgf902 -lpgf90rtl -lpgftnrtl -lpgc -lmingw32 -lgcc -lmoldname -lmsvcrt -luser32 -lkernel32 -ladvapi32 -lshell32' all on one line. See the Autoconf docs for config.site files. - Or do both of the above. Also I think we need to stick `-Mnomain' in Fortran archive_cmds otherwise fcdemo will fail again. Well, that depends on how you link. I link my C code against the archived fortran code separately so without forcing automake to use LD=$(FC), it uses the C compiler, so I don't need -Mnomain (hence the use of AC_FC_LIBRARY_LDFLAGS). Cheers, Ralf On 2/18/06, Ralf Wildenhues [EMAIL PROTECTED] wrote: The patch is ok, could you be bothered to run the testsuite once, verbosely make check VERBOSE=x TESTSUITE_FLAGS=-V make check-local and send (packed) the output and tests/testsuite.log, so we could hash out any other simple issues for decent support?
Re: PGI Compiler patch for cygwin
On 2/21/06, Ralf Wildenhues [EMAIL PROTECTED] wrote: Hi Christopher, * Christopher Hulbert wrote on Tue, Feb 21, 2006 at 05:48:56PM CET: I get this error compiling libtool. It looks like it's trying to extract the symbols from libltdl/.libs/libltdl.lax/loadlibrary.lib, but the symbols look like they have paths associated with it and thus can't extract them because the path doesn't exist. I guess this is because the library is created using pgcc which uses the MS hack for an archiver (lib). Any ideas? Ah, ok. At this point we need a feature of the pending patches from Peter Ekberg: http://article.gmane.org/gmane.comp.sysutils.automake.general/6539 (but also see the part of this thread http://thread.gmane.org/gmane.comp.gnu.libtool.general/7182 that starts with 'msvs support' (sic)). It seems the patch is no longer available. The link refers to 6539-001.bin which doesn't exist. Doing a directory listing lists only 6539 and nothing else related to the thread. When that is applied, you will be able to configure with AR=link -lib or AR=lib and get the desired functionality. If someone (hint, hint) can get GNU binutils ar to do the one-by-one extraction nicely, or find some other nice way to achieve the extraction, I would not mind either.. I guess one way could be to collect the dirnames of all members from `ar t' and func_mkdir_p them.. or a nice subset of that.. then actually extract all members.. Sorry, I was thinking out loud. Cheers, Ralf /bin/sh ./libtool --tag=CC --mode=link pgcc -g -no-undefined -o libltdl/libltdl.la -rpath /usr/local/lib -no-undefined -version-info *snip* libtool: link: (cd libltdl/.libs/libltdl.lax/loadlibrary.lib ar x /cygdrive/c/cygwin/home/chulbert/libtool-build/libltdl/.libs/loadlibrary.lib) libltdl/loaders/.libs/loadlibrary.o: No such file or directory bash-3.00$ lib -list libltdl/.libs/loadlibrary.lib Microsoft (R) Library Manager Version 7.10.3077 Copyright (C) Microsoft Corporation. All rights reserved. libltdl/loaders/.libs/loadlibrary.o bash-3.00$ ar t libltdl/.libs/loadlibrary.lib libltdl/loaders/.libs/loadlibrary.o
Re: PGI Compiler patch for cygwin
On 2/21/06, Ralf Wildenhues [EMAIL PROTECTED] wrote: * Christopher Hulbert wrote on Tue, Feb 21, 2006 at 07:18:17PM CET: On 2/21/06, Ralf Wildenhues [EMAIL PROTECTED] wrote: http://article.gmane.org/gmane.comp.sysutils.automake.general/6539 It seems the patch is no longer available. The link refers to 6539-001.bin which doesn't exist. Doing a directory listing lists only 6539 and nothing else related to the thread. :-( I did not know gmane expires attachments or hides them. This is the same article: http://lists.gnu.org/archive/html/libtool-patches/2005-11/msg00190.html Cheers, Ralf I guess I should have replied syaing I checked that (after posting). I applied the patch but unfortunately some Hunks failed so I'm applying them by hand and testing them. For reference, here is the output of patch. Some of the failures are likely due to my PGI changes. bash-3.00$ patch -p0 ~/head-msys_msvc-13.patch patching file Makefile.am Hunk #1 succeeded at 406 (offset 28 lines). patching file libltdl/config/ltmain.m4sh Hunk #1 succeeded at 714 (offset 11 lines). Hunk #2 FAILED at 1054. Hunk #3 succeeded at 1355 (offset 35 lines). Hunk #4 succeeded at 2683 (offset 35 lines). Hunk #5 succeeded at 4170 (offset 43 lines). Hunk #6 succeeded at 4765 (offset 40 lines). Hunk #7 succeeded at 4794 (offset 40 lines). Hunk #8 succeeded at 5392 (offset 68 lines). Hunk #9 succeeded at 5626 with fuzz 2 (offset 99 lines). Hunk #10 succeeded at 5933 (offset 99 lines). Hunk #11 succeeded at 5989 (offset 99 lines). Hunk #12 succeeded at 6096 (offset 99 lines). Hunk #13 succeeded at 6274 (offset 99 lines). Hunk #14 succeeded at 6567 (offset 113 lines). 1 out of 14 hunks FAILED -- saving rejects to file libltdl/config/ltmain.m4sh.rej patching file libltdl/m4/libtool.m4 Hunk #1 succeeded at 1209 (offset 7 lines). Hunk #2 succeeded at 1271 (offset 7 lines). Hunk #3 succeeded at 2108 (offset 13 lines). Hunk #4 succeeded at 3027 (offset 39 lines). Hunk #5 succeeded at 3045 (offset 39 lines). Hunk #6 succeeded at 4026 (offset 84 lines). Hunk #7 succeeded at 4137 (offset 88 lines). Hunk #8 succeeded at 4330 (offset 103 lines). Hunk #9 FAILED at 4458. Hunk #10 FAILED at 4484. Hunk #11 succeeded at 5094 (offset 131 lines). Hunk #12 FAILED at 5470. Hunk #13 succeeded at 5497 with fuzz 2 (offset 132 lines). Hunk #14 succeeded at 5874 (offset 143 lines). 3 out of 14 hunks FAILED -- saving rejects to file libltdl/m4/libtool.m4.rej patching file tests/demo/foo.h patching file tests/depdemo/sysdep.h patching file tests/depdemo/l1/l1.h patching file tests/depdemo/l2/l2.h patching file tests/depdemo/l3/l3.h patching file tests/depdemo/l4/l4.h patching file tests/pdemo/foo.h
Re: PGI Compiler patch for cygwin
I get this error compiling libtool. It looks like it's trying to extract the symbols from libltdl/.libs/libltdl.lax/loadlibrary.lib, but the symbols look like they have paths associated with it and thus can't extract them because the path doesn't exist. I guess this is because the library is created using pgcc which uses the MS hack for an archiver (lib). Any ideas? /bin/sh ./libtool --tag=CC --mode=link pgcc -g -no-undefined -o libltdl/libltdl.la -rpath /usr/local/lib -no-undefined -version-info 7:0:0 -dlpreopen libltdl/loadlibrary.la libltdl/loaders/libltdl_libltdl_la-preopen.lo libltdl/libltdl_libltdl_la-lt__alloc.lo libltdl/libltdl_libltdl_la-lt_dlloader.lo libltdl/libltdl_libltdl_la-lt_error.lo libltdl/libltdl_libltdl_la-ltdl.lo libltdl/libltdl_libltdl_la-slist.lo argz.lo lt__strl.lo libtool: link: rm -f libltdl/.libs/libltdl.nm libltdl/.libs/libltdl.nmS libltdl/.libs/libltdl.nmT libtool: link: creating libltdl/.libs/libltdlS.c libtool: link: extracting global C symbols from `libltdl/.libs/loadlibrary.lib' libtool: link: (cd libltdl/.libs pgcc -g -c libltdlS.c) libtool: link: rm -f libltdl/.libs/libltdlS.c libltdl/.libs/libltdl.nm libltdl/.libs/libltdl.nmS libltdl/.libs/libltdl.nmT libtool: link: (cd libltdl/.libs/libltdl.lax/loadlibrary.lib ar x /cygdrive/c/cygwin/home/chulbert/libtool-build/libltdl/.libs/loadlibrary.lib) libltdl/loaders/.libs/loadlibrary.o: No such file or directory make[2]: *** [libltdl/libltdl.la] Error 1 make[2]: Leaving directory `/cygdrive/c/cygwin/home/chulbert/libtool-build' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/cygdrive/c/cygwin/home/chulbert/libtool-build' make: *** [all] Error 2 bash-3.00$ lib -list libltdl/.libs/loadlibrary.lib Microsoft (R) Library Manager Version 7.10.3077 Copyright (C) Microsoft Corporation. All rights reserved. libltdl/loaders/.libs/loadlibrary.o bash-3.00$ ar t libltdl/.libs/loadlibrary.lib libltdl/loaders/.libs/loadlibrary.o On 2/21/06, Ralf Wildenhues [EMAIL PROTECTED] wrote: * Christopher Hulbert wrote on Tue, Feb 21, 2006 at 04:53:31PM CET: On 2/21/06, Ralf Wildenhues [EMAIL PROTECTED] wrote: * Christopher Hulbert wrote on Tue, Feb 21, 2006 at 03:15:42PM CET: I looked at the failure for fcdemo. It looks like autoconf's AC_FC_LIBRARY_LDFLAGS is not picking up the PGI libraries because they are wrapped in single quotes, i.e. '-Lc:\Program Files\PGI/nt86/6.0/lib'. Hmpf. That'll be difficult to get both fixed in _AC_PROG_FC_V_OUTPUT and also all the way through Autoconf and Libtool so the embedded space isn't killed (or the path broken in two arguments). Not sure what's going on here. I use the AC_FC_LIBRARY_LDFLAGS in my configure.ac and I don't get that problem. libtool's configure must be quoting each of these arguments??? I should note that I had to patch fortran.m4 (a long time ago) to handle a case where the library was butted up against a single quote such as 'blah blah -lm'. I thought I sent that info to the autoconf list a while ago??? The issue you sent to the Autoconf list was slightly different, and the patch I posted to fix it matched very narrowly (to lessen the chance of interfering with other compilers' output, or so I must have thought back then). You should also note that, if you use the nightly tarballs, they are bootstrapped with Autoconf 2.59, but aforementioned patch was added to Autoconf after 2.59. Hopefully, Autoconf 2.60 will be out soon. Also I think we need to stick `-Mnomain' in Fortran archive_cmds otherwise fcdemo will fail again. Well, that depends on how you link. I link my C code against the archived fortran code separately so without forcing automake to use LD=$(FC), it uses the C compiler, so I don't need -Mnomain (hence the use of AC_FC_LIBRARY_LDFLAGS). Oh. Ok. But I think libtool has always tried not to emit a dependency to the Fortran main function into the shared libraries it creates. I believe it would only be consistent if we continued to do this now. Does it break anything? I don't think it would break anything, but I don't think the fortran compiler puts in a main when creating shared libraries. Are you trying to avoid the DllMain routine? If so you want -Mnopgdllmain. The doc says that the latest version of the PGI DllMain are included in the release notes and must be included for proper functioning of the dll. I would think under windows unless the user gives a specific entry point or tells libtool not to use the DllMain, you may want to leave that. Just my opinion though. Cheers, Ralf
Re: PGI Compiler patch for cygwin
On 2/21/06, Ralf Wildenhues [EMAIL PROTECTED] wrote: * Christopher Hulbert wrote on Tue, Feb 21, 2006 at 07:18:17PM CET: On 2/21/06, Ralf Wildenhues [EMAIL PROTECTED] wrote: http://article.gmane.org/gmane.comp.sysutils.automake.general/6539 It seems the patch is no longer available. The link refers to 6539-001.bin which doesn't exist. Doing a directory listing lists only 6539 and nothing else related to the thread. :-( I did not know gmane expires attachments or hides them. This is the same article: http://lists.gnu.org/archive/html/libtool-patches/2005-11/msg00190.html Cheers, Ralf I can't seem to shake this error. Attahed is the config.log and make output in a bzipped tar file. Chris pgi_patch_error.tar.bz2 Description: BZip2 compressed data
Re: PGI Compiler patch for cygwin
Yes, I can, but it will have to wait till tuesday when I go back to work. Chris On 2/18/06, Ralf Wildenhues [EMAIL PROTECTED] wrote: Hi Christopher, * Christopher Hulbert wrote on Wed, Feb 15, 2006 at 04:08:33PM CET: The attached patch fixes the empty wl variable and the MS toolchain assumption of -link -dll. The patch is ok, could you be bothered to run the testsuite once, verbosely make check VERBOSE=x TESTSUITE_FLAGS=-V make check-local and send (packed) the output and tests/testsuite.log, so we could hash out any other simple issues for decent support? Thanks, Ralf
PGI Compiler patch for cygwin
The attached patch fixes the empty wl variable and the MS toolchain assumption of -link -dll. pgi.patch Description: Binary data
