Re: Problem with libtool adding -pthread
On Sun, Nov 28, 2010 at 12:39 PM, John R. Cary c...@txcorp.com wrote: On 11/28/10 10:25 AM, Ralf Wildenhues wrote: Hello John, * John R. Cary wrote on Sun, Nov 28, 2010 at 03:02:48PM CET: I am tring to link with libtool using the compiler wrappers on a Cray and with pgi. At final link, libtool inserts the flag, -pthread, which causes the compiler to fail. This is shown below. Uh, that's probably because one of the installed libtool libraries you link against was compiled with GCC and with -pthread, so it has that flag in its inherited_linker_flags. Easiest workaround would be to remove that from the *.la file. And yes, this is a libtool bug. It should translate -pthread to the spelling that your compiler uses for enabling threads. Thanks for the report, Ralf Thanks, Ralf. Unfortunately, I cannot apply your suggested fix, as the library is a system library. For now I have a workaround that I just drop back to the the non libtool way for linking C++ code that links in a fortran library. The PGI compilers look for config files in your home directory. Try adding this line set NOSWITCHERROR=1; to the following files ~/.mypgcpprc ~/.mypgf77rc ~/.mypgf90rc ~/.mypgfortranrc Then, the compiler will just ignore switches it does not understand. Chris Thx.John ___ http://lists.gnu.org/mailman/listinfo/libtool ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Windows Patches [Was: GNU Libtool 2.2.8 released (stable)]
On Tue, Jun 8, 2010 at 4:22 AM, Peter Rosin p...@lysator.liu.se wrote: Hi Gary! Den 2010-06-08 09:34 skrev Gary V. Vaughan: [[Adding Libtool List]] On 8 Jun 2010, at 08:42, Charles Wilson wrote: Which is why I don't think even the Peter's long-ready MSVC patches, nor my pile of pending patches, are candidates for this extremely shortened release cycle. Regarding these patches, I honestly have paid very little attention to Windows fixes for libtool because I can't test them, and don't use them: So I figured someone else was taking care of it. Since that obviously isn't the case, and because I'd hate to see them bitrotting indefinitely in the list archives, we can either commit them on the trunk after 2.2.10, or else create a topic branch in git to collect them together for testing and merging back at an appropriate point. Peter/Charles, Do you have a summary of the capabilities added by your patches/branch. I looked at the pr-msvc-support branch some time ago, but had some issues getting it to work for what I wanted. I have my own local branch that adds windows support. I recently sent an email to the libtool list trolling for comments (particularly from you guys which work with Windows as well) before committing changes for manifest file embedding [1]. For my Windows branch I can: * Build libraries and executables using Microsoft, Intel, and PGI compilers. * Embed manifest files at a specific resource (e.g. 2 which supports use with LoadLibrary). * Run testsuites depending on DLLs built (I had to fixup some things for this, so it was not a gimme). Anyways, I would like before this is merged into master to perhaps have more activity on this topic and maybe try to merge features provided by both Charles' and my own changes. Again, I think more activity and publicity for the topic branch (including maybe a couple releases from that branch) would be better than a near-term merge into master. That's just my opinions though. 1. http://lists.gnu.org/archive/html/libtool/2010-03/msg00022.html Chris There's already the pr-msvc-support branch, but when I tried to merge master into it to make it easy to merge back later, the ChangeLog rotation caused conflicts. How should I resolve those conflicts? By adding the entries to ChangeLog.2009 or to ChangeLog? I think the rule is to commit with the date preserved even if that causes the ChangeLog to be unordered, but I don't know how that rule applies in the face of a ChangeLog rotation (or two)... It seems odd both to (a) have entries from 2009 in the (future-to-be) 2010 ChangeLog and (b) to make changes to the 2009 ChangeLog at this point. I see that for the first merge of master into the branch last year I updated the dates in the ChangeLog so that they said 2009, but that's lying. Sort-of anyway... Please advice. Cheers, Peter ___ http://lists.gnu.org/mailman/listinfo/libtool ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Windows Patches [Was: GNU Libtool 2.2.8 released (stable)]
On Tue, Jun 8, 2010 at 7:40 AM, Gary V. Vaughan g...@gnu.org wrote: Hi Chris, Forgive my jumping in again here... No problem, at least the subject is being talked about. On 8 Jun 2010, at 17:47, Christopher Hulbert wrote: On Tue, Jun 8, 2010 at 4:22 AM, Peter Rosin p...@lysator.liu.se wrote: Den 2010-06-08 09:34 skrev Gary V. Vaughan: On 8 Jun 2010, at 08:42, Charles Wilson wrote: Which is why I don't think even the Peter's long-ready MSVC patches, nor my pile of pending patches, are candidates for this extremely shortened release cycle. Regarding these patches, I honestly have paid very little attention to Windows fixes for libtool because I can't test them, and don't use them: So I figured someone else was taking care of it. Since that obviously isn't the case, and because I'd hate to see them bitrotting indefinitely in the list archives, we can either commit them on the trunk after 2.2.10, or else create a topic branch in git to collect them together for testing and merging back at an appropriate point. [[snip]] Anyways, I would like before this is merged into master to perhaps have more activity on this topic and maybe try to merge features provided by both Charles' and my own changes. Again, I think more activity and publicity for the topic branch (including maybe a couple releases from that branch) would be better than a near-term merge into master. ...to clarify my release plans. Once the pr-msvc-support branch has had master merged into it, and Peter and/or Chuck tell me they are happy with the state of it on Windows, then I'll run through the complete testsuite with the head of that branch on all the Unix platforms I have access to. If there are significant regressions, then I'll create a 2.2.x maintenance branch for future 2.2.x releases, and merge pr-msvc-support into master for eventual inclusion in libtool-2.4.0. Otherwise, I'll make the next 2.2.x release from master in a few months with pr-msvc-support already merged. I think it important to merge pr-msvc-support into master one way or another so that it doesn't get ignored for any longer than it has already. I would like it to not get ignore longer either, but just looking at the branch after pulling, I still don't see a hint of support for either Intel or PGI compilers on windows, both of which my changes support. That means I will likely have to continue to keep a local branch with all my changes. In addition, I might have to work around any issues created from the merge of the pr-msvc-support branch. Obviously making more work for 1 person shouldn't stop libtool progress, but I think taking the time to come up with a plan on what will be supported when the branch is merged in and making it useful for people like me using other native Windows compilers (again, Intel and PGI) would be nice. No matter what, I am sure I can work with/around whatever happens, but I would certainly prefer that the official libtool have more Windows support than at least I can see from the pr-msvc-support branch. Chris In any case, I'm hoping to make point releases every few months from now on for as long as 2.2.x continues to accumulate fixes and ports. Cheers, -- Gary V. Vaughan (g...@gnu.org) ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Windows Patches [Was: GNU Libtool 2.2.8 released (stable)]
On Tue, Jun 8, 2010 at 9:24 AM, Peter Rosin p...@lysator.liu.se wrote: Hi Christopher! Den 2010-06-08 15:06 skrev Christopher Hulbert: On Tue, Jun 8, 2010 at 7:40 AM, Gary V. Vaughang...@gnu.org wrote: I think it important to merge pr-msvc-support into master one way or another so that it doesn't get ignored for any longer than it has already. I would like it to not get ignore longer either, but just looking at the branch after pulling, I still don't see a hint of support for either Intel or PGI compilers on windows, both of which my changes support. That means I will likely have to continue to keep a local branch with all my changes. In addition, I might have to work around any issues created from the merge of the pr-msvc-support branch. So, me working around issus with your patches is better exactly how? My apologies if that is what you took away from what I said. What I meant is that it is more work than the status quo. I can keep up with libtool master right now with ease, I don't know what would happen after the pr-msvc-branch was merged. I would like it if the few people interested in Windows support would collaborate more (more on that below). Obviously making more work for 1 person shouldn't stop libtool progress, but I think taking the time to come up with a plan on what will be supported when the branch is merged in and making it useful for people like me using other native Windows compilers (again, Intel and PGI) would be nice. No matter what, I am sure I can work with/around whatever happens, but I would certainly prefer that the official libtool have more Windows support than at least I can see from the pr-msvc-support branch. Hey, I have more stuff that I would like to add, but given that it has been virtually impossible to get any patch review for Windows stuff (Ralf has been the only one doing it, thanks!), maybe, just maybe, we shouldn't add too much to the plate? Which is also the reason why I have been mostly ignoring anything new on the Windows front. Sorry about the silence. I agree that it has been hard to get any patch for Windows support reviewed. I think the lack of participation by people like myself who are interested in libtool on Windows has contributed to this. On the other hand, I would hardly consider myself capable of reviewing such patches. Libtool is a complex package that I know only enough to hack and get myself in trouble. There is already enough pending stuff, IMHO. Let's just get that out the door first. That may be frustrating for you, but the alternative is frustrating for me which is worse - of course :-) I've had enough frustration here, methinks. Sorry for my contribution to your frustration. I would just like to see windows support in the mainstream to be done right, and the attitude of just get that out the door first doesn't seem to be an approach in the right direction. I realize you have done a lot of work on that branch, and I am not trying to subvert it or criticize it. I was just trying to make the Windows libtool support better. I guess in the end, it doesn't matter to me. I will continue to do whatever I am doing. Sorry for the noise. Chris Cheers, Peter ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Windows Patches [Was: GNU Libtool 2.2.8 released (stable)]
On Tue, Jun 8, 2010 at 11:03 AM, Peter Rosin p...@lysator.liu.se wrote: Den 2010-06-08 15:40 skrev Christopher Hulbert: On Tue, Jun 8, 2010 at 9:24 AM, Peter Rosinp...@lysator.liu.se wrote: I've had enough frustration here, methinks. Sorry for my contribution to your frustration. I would just like to see windows support in the mainstream to be done right, and the attitude of just get that out the door first doesn't seem to be an approach in the right direction. I realize you have done a lot of work on that branch, and I am not trying to subvert it or criticize it. I was just trying to make the Windows libtool support better. But you are subverting it and you are criticizing it when you say that it should be done right. Of course it can be done better. That's true of all software. But you have to understand that I'm at a point where I since long have stopped adding new stuff since the pending queue is too long. It should be no surprise that I'm not happy to see others butt in and defer the queue even further. Rereading what I wrote, my point didn't come out right. What I wanted to criticize was the attitude of just merge it then go forward. For someone who has their own windows branch for some time now, I just don't feel that the emotional desire to just get your existing work into the master warrants that kind of approach. I don't know what the right-way to do Windows support is and you are probably far more knowledgeable than I am with libtool, so there's no way for me to say your stuff is wrong, bad, etc. FWIW, I butted in over a year ago with questions about the branch and my desire to support PGI and Windows compilers [1]. Only 2 people responded to my butting, but unfortunately (and understandably) neither of them I think wanted to get involved with it. Since the consensus seems to be to merge the pr-msvc-support branch, then perhaps you should find problems with it now rather than wait for it to be merged? You seem to want someone to look at your work to check if it fits with what's pending, and adjust so that your stuff merges easily later. But I get the feeling that we are past that stage and am not really interested in going back to the drawing board. I want to start using what's already implemented first. So if you want your work to fit with the future of libtool you will have to address specific issues now instead of the above hand-waving with the implication that the pending stuff is somehow bad. I already mentioned two problems that exist for me (no support for Intel or PGI compilers). Of course I want someone to look at my work or at least be interested in looking at it because it provides me support for building on Windows that I currently don't see available, but I fail to see how that is a bad thing. I want to share what I have done to possibly help other people. Obviously I am willing to get my hands dirty or I would not have started modifying libtool on my own. I am not saying what pr-msvc-support does is bad. I am saying that it does not provide the Windows support I needed. I would not mind helping to add my stuff to what you have, but I have posted several messages before related to Windows that have just dead-ended. If someone on the pr-msvc-support branch shows no interest in my work, and it is easier for me to start from libtool master with a clean slate, why would I bother trying to figure out what pr-msvc-support already had. I'm biased of course, but you all know that. I guess in the end, it doesn't matter to me. I will continue to do whatever I am doing. Sorry for the noise. Sorry if I'm stepping on toes here, but somehow this is a rather sensitive subject to me... I understand it may be a sensitive subject to you. I don't know how to say it again, but I am not criticizing or passing any other negative judgement on the pr-msvc-support branch. I am just saying that it does not support my Windows needs. I don't recall at the time I started my windows branch if I was aware of pr-msvc-support or not. Oh, and I will be much more open to collaboration once the branch has been merged. That's a promise. I guess I just don't understand that attitude. If it were me and someone else wanted to collaborate or help out on Windows support, interacting with them would be important to me. Then again, I don't really care if my windows changes make into libtool. I will continue to use whatever I have, and if pr-msvc-support gets merged with master I will just figure it out. I guess in the end it is just frustrating that few people on the libtool list care about Windows, and furthermore do not express an interest or invite collaboration. A year ago I had some questions on the pr-msvc-support branch and even provided some patches I had made to master at the time for PGI windows compiler support [1]. Only Bob and Ralf responded. Had you popped up as the owner of the branch and expressed interest in what I wanted to do (even if you did not care
Embedding manifests in DLLs
I am working on a patch for my windows branch of libtool that will
allow me to embed manifest files in the DLLs. I have been manually
embedding them for a while now using mt -manifest libfoo.dll.manifest
-outputresource:libfoo.dll;#2. Growing tired of that and the
occasional error if I forget to do that, I finally put in a little
time to add what I need into libtool. Since a patch would be relative
to my windows branch, I'll just describe the changes below. I am just
hoping to get some feedback from others who are working with manifest
files since the topic was recently active on the list.
libltdl/m4/libtool.m4 was modified as follows:
1. add the LT_PATH_MT function to look for MS's manifest tool program.
This sets the Libtool variable MANIFEST_TOOL to the program found.
+# LT_PATH_MT
+# --
+# find the pathname to the MS Manifest Tool
+AC_DEFUN([LT_PATH_MT],
+[
+# Check for Microsoft Manifest Tool
+AC_CHECK_TOOL(MT, mt,)
+_LT_DECL([MANIFEST_TOOL], [MT], [0], [MS Manifest Tool])dnl
+]) # LT_PATH_MT
2. Add a call to the LT_PATH_MT function added in _LT_SETUP.
Also, libltdl/config/ltmain.m4sh was modified as follows:
1. Add -embed-manifest and -manifest-resource-id options to
func_mode_link. The first option tells libtool to embed the manifest
file if it exists, and the second takes an argument that is the
manifest id. The way it works out, is I need resource id 2 for my DLLs
to work.
2. In func_mode_link, after the test whether to create links to the
real library, the code block below was added. I am not sure if this is
the exact correct place for it, but it seems to work and
func_mode_link is VERY long. embed_manifest is a variable set to yes
when '-embed-manifest' is given as an argument, and
manifest_resource_id is the argument given by the
'manifest-resource-id'. Right now, I am passing a little more than
just the resource id (e.g. I'm passing ';#2' instead of just '2'), but
I will probably clean it up before I commit it. So from the makefile
perspective, I am now passing -embed-manifest -manifest-resource-id
';\#2' to my AM_LDFLAGS to get it passed to libtool. I've tested and
this seems to work with the Intel C++ compilers on Windows. I haven't
yet checked the MSVC or PGI compilers.
+ if test $embed_manifest = yes test -n $MANIFEST_TOOL; then
+ if test -e ${output_objdir}/${realname}.manifest; then
+ func_show_eval '$MANIFEST_TOOL -manifest
${output_objdir}/${realname}.manifest
-outputresource:${output_objdir}/${realname}${manifest_resource_id}'
+ fi
+ fi
___
http://lists.gnu.org/mailman/listinfo/libtool
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)
shlib_search_path on cygwin in func_mode_link
I am working on the search for libraries in func_mode_link to get it to find DLL import libraries on the search path (this is around line 4824 of ltmain.m4sh). The shlib_search_path is built on shlibpath_var which is set to PATH on cygwin. My setup happens to have a PATH with spaces in the directory names. These paths to search gets broken on the spaces in the directory name instead of just at the separator. I was looking at using func_to_host_pathlist function, but this does not seem to work either (I think at least partly because of cygpath). I thought this might be a cygwin bug, but using the which program seems to handle the path list correctly. cygpath -w -p however does not. Another problem is that my PATH contains references to other environemnt variables (e.g. ...:%COMPILER%\bin). Again the which program seems to handle this. So, I guess I'm asking for suggestions on how I might make this work, or if I should just give up on trying to make it work. For now, I've just passed the needed directory using a -L flag in linker flags to get libtool to find the libraries in the search since that gets added to the lib_search_path and it seems to work. The only caveat is that the -L can only go to libtool otherwise other compiler tests in configure fail because the compiler expects -link -libpath. Chris ___ http://lists.gnu.org/mailman/listinfo/libtool
-objectlist in compile mode
Would it be acceptable to add the -objectlist option in compile mode. If passed in compile mode, the .lo file compiled should be appended to the file for use with -objectlist at link time. The reason I am wondering is I have updated to automake 1.11 to check out the new quieter output. Unfortunately, it did not work on 1 of my packages because it has too many files for the command line, so I made a rule (taken from an older libtool/automake) like the following and then pass -objectlist libvsip.objlist at link time. .c.lo: source='$' object='$@' libtool=yes \ DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) \ $(LTCOMPILE) -c -o $@ $ echo $@ libvsip.objlist Thus, I changed it to the following for the new automake. .c.lo: $(AM_V_CC) @AM_BACKSLASH@ $(LTCOMPILE) -c -o $@ $ echo $@ libvsip.objlist None of this would be needed obviously of libtool had a -objectlist in compile mode as well. I could possibly supply a patch if this change would be acceptable. Chris ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: -objectlist in compile mode
On Tue, May 19, 2009 at 6:24 PM, Ralf Wildenhues ralf.wildenh...@gmx.de wrote: Hi Christopher, * Christopher Hulbert wrote on Tue, May 19, 2009 at 06:38:10PM CEST: Would it be acceptable to add the -objectlist option in compile mode. If passed in compile mode, the .lo file compiled should be appended to the file for use with -objectlist at link time. The reason I am wondering is I have updated to automake 1.11 to check out the new quieter output. Unfortunately, it did not work on 1 of my packages because it has too many files for the command line, so I made a rule (taken from an older libtool/automake) like the following and then pass -objectlist libvsip.objlist at link time. Neat idea. In a Makefile.am, it could be passed in target_CFLAGS, for example. However, how would you cope with recompiles and changes in the set of sources? For example, make touch foo.c make will then list foo.lo twice in the object list file, no? Hmm, I guess you can solve that with using some kind of intermediate rule that uses 'sort -u' to create a better list; but specifying that without the set of objects as prerequisites looks to be difficult. I thought about that a little today after sending the email. After testing on a few systems, I updated my rule to .c.lo: $(AM_V_CC) @AM_BACKSLASH@ $(LTCOMPILE) -c -o $@ $ ( ( test -f libvsip.objlist test -n `$(GREP) $@ libvsip.objlist` ) || echo $@ libvsip.objlist ) Similar issue however if, after 'make', you remove foo.c from the *_SOURCES variable and recompile without a 'make clean' in between (where presumably the object list file is listed in CLEANFILES)? This is a scenario which makefiles typically cope fine with otherwise. This scenario I have not thought about and even my updated rule would fail for this case. Please note that the general tool that libtool provides you with to cope with line length issues is the convenience archive: you just collect subsets of objects in convenience archives, and in a final step link them together to form a real library (depending on your source language, you might want to keep one real object around for the final link). If that is not sufficient yet, you can also link convenience archives into bigger convenience archives. Of course this approach is typically less efficient. I haven't looked into using convenience libraries. I'd have to see how it works on Windows. Another approach that doesn't require changing libtool would be something like this (where you'd need to replace $(object_files) with the appropriate variable name for the objects (which, incidentally, is an internal Automake detail): collect-object-list: $(object_files:.lo=.ls) .lo.ls: �...@echo $ object-list object-list: : $@ $(MAKE) $(AM_MAKEFLAGS) collect-object-list This assumes that you have no files named *.ls anywhere. Bottom line is that I would like to see a clear advantage of such an option, together with a use case that is not very difficult to use correctly. This is probably where the thread will die. I only have one package that needs this, and what I have works for almost every way I use it except for the case you mentioned above removing a source file. Since that seems like only an issue for a developer, I will just ignore the problem, but remember it in case it comes up. Chris Cheers, Ralf ___ http://lists.gnu.org/mailman/listinfo/libtool
Trying to link a program using libtool in configure script
I would like to perform configure tests trying to link a program (in
order to test for libraries) using libtool since that is what my
libraries and programs use anyways. So, based on AC_TRY_LINK and
AC_LINK_IFELSE, I've come up with the macro below which works for C. I
would like to extend it for the other languages (hence the use of
AC_LANG_CASE). Before I do that, I was hoping to get comments/feedback
on the current implementation. Specifically any issues I might have.
One concern I have is that AC_LANG_CASE is undocumented as far as I
can tell, and _AC_DO_STDERR seems to be (from the naming) meant for
autoconf use only. The current version seems to do what I want as far
as my limited testing has shown.
Chris
# VSIPL_LTLINK_IFELSE(PROGRAM, [ACTION-IF-TRUE], [ACTION-IF-FALSE])
#
# Tries to link a program using a libtool script. Requires that the libtool
# script be generated (e.g. LT_OUTPUT)
AC_DEFUN([VSIPL_LTLINK_IFELSE],
[
AC_REQUIRE([LT_OUTPUT])
AC_LANG_COMPILER_REQUIRE()
AC_LANG_CASE(
[C],
[vsipl_ltcompile='./libtool --tag=CC --mode=compile $CC $CFLAGS
$CPPFLAGS $LT_CFLAGS -c -o conftest.lo conftest.$ac_ext
AS_MESSAGE_LOG_FD'
vsipl_ltlink='./libtool --tag=CC --mode=link $CC $CFLAGS $CPPFLAGS
$LT_CFLAGS $LDFLAGS $LT_LDFLAGS -o conftest$ac_exeext conftest.lo
$LIBS AS_MESSAGE_LOG_FD'],
[vsipl_ltcompile='exit 1'
vsipl_ltlink='exit 1'])
#
# Generate the program
#
AC_LANG_CONFTEST([$1])
rm -f conftest.lo conftest.$ac_objext conftest$ac_exeext
AS_IF([_AC_DO_STDERR($vsipl_ltcompile) _AC_DO_STDERR($vsipl_ltlink) {
test -z $ac_[]_AC_LANG_ABBREV[]_werror_flag ||
test ! -s conftest.err
} test -s conftest$ac_exeext {
test $cross_compiling = yes ||
AS_TEST_X([conftest$ac_exeext])
}],
[$2],
[_AC_MSG_LOG_CONFTEST
$3])
# Delete the IPA/IPO (Inter Procedural Analysis/Optimization) information
# created by the PGI compiler (conftest_ipa8_conftest.oo), as it would
# interfere with the next link command; also delete a directory that is
# left behind by Apple's compiler. We do this before executing the actions.
rm -rf conftest.dSYM conftest_ipa8_conftest.oo
])
# VSIPL_TRY_LTLINK(INCLUDES, FUNCTION-BODY,
# [ACTION-IF-TRUE], [ACTION-IF-FALSE])
#
# Tries to link a program using a libtool script. Requires that the libtool
# script be generated (e.g. LT_OUTPUT)
AC_DEFUN([VSIPL_TRY_LTLINK],
[VSIPL_LTLINK_IFELSE([AC_LANG_PROGRAM([[$1]], [[$2]])], [$3], [$4])])
___
http://lists.gnu.org/mailman/listinfo/libtool
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: 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 ___ http://lists.gnu.org/mailman/listinfo/libtool
Windows compilers
Until now, I have been using for the most part the PGI compilers on Windows which conveniently use most of the same flags/command style as its Linux compilers (e.g. -L -l). I am now also trying to use the Intel compilers which use the MSVC format on Windows (e.g. -link -libpath:). I have been looking at the pr-msvc-support branch, but have a few questions. 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? 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. 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? 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. Thanks, Chris ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Libtool strips out -tp=k8-32 PGI compiler flag in link mode
On Thu, Mar 26, 2009 at 3:06 PM, Ralf Wildenhues ralf.wildenh...@gmx.de wrote: * Ethan Mallove wrote on Thu, Mar 26, 2009 at 04:17:11PM CET: On Sat, Mar/21/2009 11:47:42AM, Ralf Wildenhues wrote: * Ralf Wildenhues wrote on Sat, Mar 21, 2009 at 11:41:20AM CET: Thanks for the bug report. A workaround should be to ./configure CC=pgcc -tp=k8-32 and the following patch should fix the issue. Can you try both? Never mind; the `-tp PROCESSOR' gets reordered badly by libtool anyway, so only `-tp=PROCESSOR' is feasible. Updated patch below. OTOH, another workaround should be to pass -Wc,-tp=k8-32 to `libtool --mode=link'. AM_CFLAGS seems to do the trick, e.g., $ make AM_CFLAGS='-Wc,-tp=k8-32' Yes. But that can cause problems with packages where the compiler is also called directly from make, without the libtool script in between. Because I work with compilers that have flags libtool does not pass through, it has become a habit for me to develop my autoconf/automake/libtool packages where the configure.ac file defines variables LT_CFLAGS, LT_FCFLAGS, LT_LDFLAGS so that the user (usually me) can pass flags that use the form -Xcompiler,flag and -XCClinker,flag. All of my automake files pass $(LT_CFLAGS), etc. to libtool libraries. Perhaps it would be beneficial to add some form of these to standard libtool so that all packages using new libtool provide a way for the user to get flags passed libtool if necessary. It would actually be nice if that would be passed to libtool in a way that the user (again me a lot) did not have to add the -Xcompiler, -XCClinker, etc. to make sure they get passed through libtool. Perhaps one of the LT macros would look at that configure variable and substitute it with the proper flag quoting? Another idea would be to somehow provide an option for a user/developer to specify a file with a set of known compiler flags that libtool could match against, but that might slow things down unless it is only done once at configure and not for every compile, link, etc. Just some thoughts from another PGI user. Chris --- a/libltdl/config/ltmain.m4sh +++ b/libltdl/config/ltmain.m4sh @@ -4497,8 +4497,9 @@ func_mode_link () # -F/path gives path to uninstalled frameworks, gcc on darwin # -p, -pg, --coverage, -fprofile-* pass through profiling flag for GCC # @file GCC response files + # -tp=* Portland pgcc target processor selection -64|-mips[0-9]|-r[0-9][0-9]*|-xarch=*|-xtarget=*|+DA*|+DD*|-q*|-m*| \ - -t[45]*|-txscale*|-p|-pg|--coverage|-fprofile-*|-F*|@*) + -t[45]*|-txscale*|-p|-pg|--coverage|-fprofile-*|-F*|@*|-tp=*) func_quote_for_eval $arg arg=$func_quote_for_eval_result func_append compile_command $arg I am using the latest Libtool from the git repo (Fri Mar 20 16:42:25), with the above -tp patch and libtoolize is stuck pegging my CPU at 99%. I assume I should have been applying the -tp patch to a stable Libtool version, e.g., 2.2.6? That's really weird. libtoolize doesn't have anything to do with this. I have meanwhile tested the patch myself with a PGI compiler set, applied against the latest git Libtool, and found no problems. Can you be more specific in where libtoolize hangs? I.e., run the command that hangs manually, with --debug added. Also, autom4te is used for creating the libtoolize script, so please state the Autoconf version you are using. Thanks, Ralf ___ http://lists.gnu.org/mailman/listinfo/libtool ___ http://lists.gnu.org/mailman/listinfo/libtool
Windows-style paths for dependency_libs in .la files
I have a package with a few libraries where some of the libraries depend on the others. I specify the dependent libraries in LIBADD as $(top_builddir)/liba/liba.la. In the dependency_libs of the .la in the build directory, the paths are expanded in a UNIX fashion. On cygwin, this causes minor issues when building (I say minor because my compiler, PGI, ignores the unrecognized file). After installing the package, the dependency_libs of the installed .la file is fixed so that all the libraries are in Windows path style. Would it be possible to have the .la file in the build directory have Windows-style paths as well? For example (note the first 2 entries): In the .la file in the build directory: dependency_libs=' /home/chulbert/ISLdevel/build-cygwin-x86/scats/libseke/libseke.la /home/chulbert/ISLdevel/build-cygwin-x86/scats/libscatsio/libscatsio.la -LC:/cygwin/home/chulbert/isl-scrd/i686-pc-cygwin/lib -Lc:/cygwin/home/chulbert/software/x86/lib C:/cygwin/home/chulbert/isl-scrd/i686-pc-cygwin/lib/libisl_edb.la c:/cygwin/home/chulbert/software/x86/lib/libxml2.la C:/cygwin/home/chulbert/isl-scrd/i686-pc-cygwin/lib/libgctpc.la C:/cygwin/home/chulbert/isl-scrd/i686-pc-cygwin/lib/libislm.la C:/cygwin/home/chulbert/isl-scrd/i686-pc-cygwin/lib/libisl.la -lz' In the installed .la file: dependency_libs=' C:/cygwin/home/chulbert/isl-scrd/i686-pc-cygwin/lib/libseke.la C:/cygwin/home/chulbert/isl-scrd/i686-pc-cygwin/lib/libscatsio.la -LC:/cygwin/home/chulbert/isl-scrd/i686-pc-cygwin/lib -Lc:/cygwin/home/chulbert/software/x86/lib C:/cygwin/home/chulbert/isl-scrd/i686-pc-cygwin/lib/libisl_edb.la c:/cygwin/home/chulbert/software/x86/lib/libxml2.la C:/cygwin/home/chulbert/isl-scrd/i686-pc-cygwin/lib/libgctpc.la C:/cygwin/home/chulbert/isl-scrd/i686-pc-cygwin/lib/libislm.la C:/cygwin/home/chulbert/isl-scrd/i686-pc-cygwin/lib/libisl.la -lz' Chris ___ http://lists.gnu.org/mailman/listinfo/libtool
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
Re: shared libraries on darwin using Intel compiler
On Thu, Jun 12, 2008 at 7:42 PM, Bob Friesenhahn [EMAIL PROTECTED] wrote: On Thu, 12 Jun 2008, Christopher Hulbert wrote: In libtool 2.2.2, building shared libraries using Intel fortran compilers seem to be disabled (although the icc compiler appears to say yes). Thus, mixed language shared libraries or purely fortran I suspect that this is already fixed for the next release (fix already in GIT): 2008-05-25 Ralf Wildenhues [EMAIL PROTECTED] Fix ifort settings again. * libltdl/m4/libtool.m4 (_LT_COMPILER_PIC) [linux] ifort: Unlike icc and ecc, not all ifort versions understand `-KPIC', e.g. version 10.1, so use `-fPIC' instead. Report by Jeff Squyres. Thanks. I will try the version from git. Chris Bob == Bob Friesenhahn [EMAIL PROTECTED], http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: shared libraries on darwin using Intel compiler
On Thu, Jun 12, 2008 at 7:42 PM, Bob Friesenhahn [EMAIL PROTECTED] wrote: On Thu, 12 Jun 2008, Christopher Hulbert wrote: In libtool 2.2.2, building shared libraries using Intel fortran compilers seem to be disabled (although the icc compiler appears to say yes). Thus, mixed language shared libraries or purely fortran I suspect that this is already fixed for the next release (fix already in GIT): 2008-05-25 Ralf Wildenhues [EMAIL PROTECTED] Fix ifort settings again. * libltdl/m4/libtool.m4 (_LT_COMPILER_PIC) [linux] ifort: Unlike icc and ecc, not all ifort versions understand `-KPIC', e.g. version 10.1, so use `-fPIC' instead. Report by Jeff Squyres. GIT version still reports that the ifort linker does not support shared libraries. The config.log is attached. Chris Bob == Bob Friesenhahn [EMAIL PROTECTED], http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ config.log.gz Description: GNU Zip compressed data ___ http://lists.gnu.org/mailman/listinfo/libtool
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 ___ http://lists.gnu.org/mailman/listinfo/libtool
shared libraries on darwin using Intel compiler
In libtool 2.2.2, building shared libraries using Intel fortran compilers seem to be disabled (although the icc compiler appears to say yes). Thus, mixed language shared libraries or purely fortran shared libraries can't be built. I have the intel 10.1 compilers. As a quick way to get shared libraries working, I hacked the _LT_LINKER_SHLIBS function for the darwin case to what's below, but I'm sure there's a better way of doing this. What would be the more preferable way of adding support for shared libraries using Intel fortran compiler? I'm not sure why it works for icc but not ifort. Using the hack below I can successfully link with the fortran linker and build the shared library. Chris darwin* | rhapsody*) - _LT_DARWIN_LINKER_FEATURES($1) + case $cc_basename in +icc* | ifort*) + GCC_save=$GCC + GCC=yes + _LT_DARWIN_LINKER_FEATURES($1) + GCC=$GCC_save + ;; +*) + _LT_DARWIN_LINKER_FEATURES($1) + ;; + esac ;; ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: multiarch procedure
On Fri, May 9, 2008 at 9:20 AM, Bob Friesenhahn [EMAIL PROTECTED] wrote: On Fri, 9 May 2008, Steve Edwards wrote: I've been using libtool quite happily for some time but have just started looking at packaging libraries for x86_64 systems. I'm trying to find out what the recommended method is for installation of x86_64 64bit libraries. Different systems use different approaches. Is the only method to manually set --libdir at configure time (I have libtool integrated with automake/autoconf)? I was a little The only way to be sure that things will work is to use --prefix and install into a different directory tree. If you advise to use --libdir, then you still have the interface header files to worry about. Interface header files often have different definitions for 32 and 64 bits. I agree with this. I started out using the default redhat method of lib64 and lib. After a while, and adding more platforms, compilers, versions, etc. I found it useful to almost always use different prefixes. That being said, I still have a mechanism in my configure to use lib64, etc. I use the code below to add a configure option to set a libdir suffix. Thus, I can set it to create lib64, lib/x86_64, etc. Then, all my other checks for packages try using $acl_libdirstem to link. If that fails and it is not simply lib, I try that for a mix of packages some of which use lib64, some of which use separate prefixes. You could also set a default, say based on the existance of /usr/lib64 for redhat systems. AC_DEFUN([CHECK_LIBDIR_SUFFIX], [ AC_ARG_WITH(libdir-suffix, AS_HELP_STRING([--with-libdir-suffix=suffix],[Suffix to apply to library directories]),,with_libdir_suffix=) ]) acl_libdirstem=lib$with_libdir_suffix libdir=$libdir$with_libdir_suffix Hope that helps some. I had a run through the libtool info at work and I'm sure I found a tantalising reference to multiarch (with a comment along the lines of unless you know what this is you don't need it) but I certainly can't find anything on my home system (libtool 2.2.4) Libtool 2.2.X includes support for automatically using 64-bit libraries on various popular systems (e.g. Solaris, Linux). Otherwise 64-bit builds would fail on systems which default to a 32 bit ABI. It does not include multiarch/multilib support necessary to build 32 and 64 bit libraries and install into that footprint. Bob == Bob Friesenhahn [EMAIL PROTECTED], http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ ___ http://lists.gnu.org/mailman/listinfo/libtool ___ http://lists.gnu.org/mailman/listinfo/libtool
multiple compilers
I'm starting to think about how to compile/link for the cell processor using the autotools. My first thought was to configure for the PowerPC processor, then override the C compiler for the SPU source files, but that doesn't work. The only way I can see right now is multiple configures or independently configured subdirectories. Would there be any reason (except for the cell processor) for the libtool script to have multiple-configured compilers for a single language? Then, based on the compiler passed to the libtool command select one? Chris ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: multiple compilers
On 8/27/07, Ralf Wildenhues [EMAIL PROTECTED] wrote: Hello Christopher, * Christopher Hulbert wrote on Mon, Aug 27, 2007 at 03:39:21PM CEST: I'm starting to think about how to compile/link for the cell processor using the autotools. My first thought was to configure for the PowerPC processor, then override the C compiler for the SPU source files, but that doesn't work. The only way I can see right now is multiple configures or independently configured subdirectories. Would there be any reason (except for the cell processor) for the libtool script to have multiple-configured compilers for a single language? Then, based on the compiler passed to the libtool command select one? I'm not sure I understand the problem enough at all, best to treat me as not having heard anything of the cell processor yet. Is it that compilation is done on the powerpc processor for code to run on the cell, and neither can execute code for the other? So that would be just a normal cross-compile situation, where you pass --host and optionally also --build, and typically the cross compiler has a prefixed name. If you then also need to execute code compiled for the $build system (the powerpc processor), then you will need two different libtool scripts, and for that you will need two different configure scripts. However, I have yet to see a package that needs to build shared libraries for both the $build and the $host system, except for compilers and other related toolchain stuff. In which case I guess it helps to look at the (complicated!) build system GCC uses for bootstrap. The cell processor has 2 different architecture cores. There's a compiler for the PowerPC and a compiler for the SPU. The SPU image can be embedded into the powerpc executable via a special command, or the powerpc code can load the SPU image much the same way as dlopen. In my case, I have a main driver function that will load the shared object from the SPU and spawn off some threads onto these SPU cores. So, to compile both the PPU and SPU binaries, I have to have a custom-written makefile or two seperately configured directories. So, I had some thoughts of libtool being configured for say 2 C compilers. In the Makefile the rule for c - lo passes --tag=CC $(CC). If I could change $(CC) to another compiler say $(SPU_CC), libtool could compile the SPU code with the SPU compiler and PPU code for the PPU compiler. Something like the following: multibin_pd_cov_ka_cbe.lo: multibin_pd_cov_ka_cbe.c $(LIBTOOL) --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(AM_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o multibin_pd_cov_ka_cbe.lo `test -f 'multibin_pd_cov_ka_cbe.c' || echo '$(srcdir)/'`multibin_pd_cov_ka_cbe.c multibin_pd_cov_ka_spu.lo: multibin_pd_cov_ka_spu.c $(LIBTOOL) --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(SPU_CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(AM_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o multibin_pd_cov_ka_spu.lo `test -f 'multibin_pd_cov_ka_spu.c' || echo '$(srcdir)/'`multibin_pd_cov_ka_spu.c Of course, this situation is probably rare, dangerous, etc. But I thought I'd throw out what I had thought of because maybe it is useful. Another thought I had was trying to figure out if there would be a clean way to extend libtool to a general language. Then I could just call the SPU code some other language and do it that way. Alas though, custom Makefiles are probably not as bad as cleanly implementing either approach :). Chris Hope that helps. Cheers, Ralf ___ http://lists.gnu.org/mailman/listinfo/libtool
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
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
___
http://lists.gnu.org/mailman/listinfo/libtool
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 ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Compiler/Linker flags
On 1/17/07, Bob Friesenhahn [EMAIL PROTECTED] wrote: On Wed, 17 Jan 2007, Christopher Hulbert wrote: It seems that libtool is set up to strip unrecognized flags unless using something like -Wc,flag. Can anyone give me a brief answer as to why? I often find myself going through hoops to get flags past The reason for the odd behavior is that libtool needs to know which options should be applied to the compiler, and which should be applied to the linker. Only libtool knows if the compiler is used for linking, or if the system linker is used to link. If the system linker is used to link, then only linker options are safe to apply. Makes sense. Now if the compiler is used for linking (which is generally the case for my compilations), would it make sense to allow unrecognized flags through? Bob == Bob Friesenhahn [EMAIL PROTECTED], http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Compiler/Linker flags
On 1/18/07, Ralf Wildenhues [EMAIL PROTECTED] wrote: * Christopher Hulbert wrote on Thu, Jan 18, 2007 at 01:18:07PM CET: On 1/17/07, Bob Friesenhahn [EMAIL PROTECTED] wrote: On Wed, 17 Jan 2007, Christopher Hulbert wrote: It seems that libtool is set up to strip unrecognized flags unless using something like -Wc,flag. Can anyone give me a brief answer as to why? I often find myself going through hoops to get flags past The reason for the odd behavior is that libtool needs to know which options should be applied to the compiler, and which should be applied to the linker. [...] Makes sense. Now if the compiler is used for linking (which is generally the case for my compilations), would it make sense to allow unrecognized flags through? As in, for example, `-MF foo.Tpo', erroneously passed by the (non-Automake-using) innocent user in $(CFLAGS)? Or, FWIW, -Bstatic, which will let libtool make the completely wrong choices of libraries (at the moment) if allowed through? I can't say I've ever tried -Bstatic, so I have no idea what libtool would do with it. I still lack the details of libtool's guts :)! -Bstatic_pgi may very well also be in the category that libtool needs to know about it; I cannot know, you haven't told us what semantics it has, and the GNU/Linux PGI I have access to doesn't know about it either. Well, -Bstatic_pgi was just the latest flag I was trying to get through. There are a lot of others that are useful at link time for the pgi compilers. These flags deal with optimization flags like IPA, vectorization, etc. Sometimes, I just end up defining a variable like LDFLAGS_LT which I put in AM_LDFLAGS in the automake files so that they do not get used in autoconf testing, but still make it into the package compiling. Then I can use -Wc,-Bstatic_pgi -Wc,-Mipa=fast,libinline, etc Cheers, Ralf ___ http://lists.gnu.org/mailman/listinfo/libtool
Compiler/Linker flags
It seems that libtool is set up to strip unrecognized flags unless using something like -Wc,flag. Can anyone give me a brief answer as to why? I often find myself going through hoops to get flags past libtool. I often can't use -Wc,flag because that gets passed directly to the compiler since autoconf does not use libtool for running the tests. It seems to me that libtool should assume that I'm intentionally passing those flags and just keep them. Perhaps an option to accept unrecognized flags would be good? My latest round was with the -Bstatic_pgi flag. Chris ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: MS lib program in msys
On 1/8/07, Ralf Wildenhues [EMAIL PROTECTED] wrote: Hello Christopher, Thanks for the report. * Christopher Hulbert wrote on Fri, Jan 05, 2007 at 04:10:18PM CET: Libtool uses MS's lib program when not using gcc in windows. On msys lib /out:.libs/liba.lib is translated to lib C:\msys1.0\OUT;.libs\liba.lib. I'm not sure when lib (or windows) started accepting - for options, but lib -out fixes the problem on Windows XP. Would there be any objection to changing that in mainline libtool? I think that when we put that in, there were some older MSVC versions that did no accept -out. May be remembering wrongly, though. What about a libtool autoconf test for lib -out and if that fails use lib /out? I'm tied up monday and tuesday, but I can try to write that patch after that to test the concept. Chris [EMAIL PROTECTED] ~ $ lib /OUT:.libs/liba.lib Microsoft (R) Library Manager Version 7.10.3077 Copyright (C) Microsoft Corporation. All rights reserved. LIB : fatal error LNK1104: cannot open file 'C:\msys1.0\OUT;.libs\liba.lib' Does lib //OUT:.libs/liba.lib work? Does anybody know whether doubling the slash can lead to problems when used under Cygwin (I think they address shares that way)? Not that the Cygwin/MSVC combo works with Libtool now... Nope. [EMAIL PROTECTED] ~]$ lib //OUT:.libs/liba.lib Microsoft (R) Library Manager Version 8.00.50727.42 Copyright (C) Microsoft Corporation. All rights reserved. LIB : warning LNK4044: unrecognized option '//OUT:.libs/liba.lib'; ignored Thanks, Ralf ___ http://lists.gnu.org/mailman/listinfo/libtool
MS lib program in msys
Libtool uses MS's lib program when not using gcc in windows. On msys lib /out:.libs/liba.lib is translated to lib C:\msys1.0\OUT;.libs\liba.lib. I'm not sure when lib (or windows) started accepting - for options, but lib -out fixes the problem on Windows XP. Would there be any objection to changing that in mainline libtool? [EMAIL PROTECTED] ~ $ lib /OUT:.libs/liba.lib Microsoft (R) Library Manager Version 7.10.3077 Copyright (C) Microsoft Corporation. All rights reserved. LIB : fatal error LNK1104: cannot open file 'C:\msys1.0\OUT;.libs\liba.lib' [EMAIL PROTECTED] ~ $ lib -OUT:.libs/liba.lib test.o Microsoft (R) Library Manager Version 7.10.3077 Copyright (C) Microsoft Corporation. All rights reserved. Chris ___ http://lists.gnu.org/mailman/listinfo/libtool
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: libtool related build questions
On 12/14/06, Bob Rossi [EMAIL PROTECTED] wrote: On Thu, Dec 14, 2006 at 07:11:08PM +0100, Ralf Wildenhues wrote: What exactly can I do about the libtool warning messages? These? Yup, *** Warning: This system can not link to static lib archive /home/bobbybrasko/log4cxx/apr-util/src/prefixdir/lib/libaprutil.la. *** I have the capability to make that library automatically link in when *** you link to this library. But I can only do this if you have a *** shared version of the library, which you do not appear to have. They are sometimes bogus. Nobody has gotten around to fixing that yet. I used to get these a lot. I link shared libraries (Matlab MEX functions) against my static libraries. To fix this, I patch libtool after configure using this line in configure.ac and the following shell script. I have not removed this, so I'm not sure if the most recent libtool still issues these warnings and refuses to build the shared libraries. AC_CONFIG_COMMANDS([libtool_patch],[chmod 755 patch_libtool.sh;./patch_libtool.sh]) #! /bin/bash mv libtool libtool.orig cat libtool.orig | sed -e s/deplibs_check_method=.*/deplibs_check_method=pass_all/g libtool chmod 755 libtool ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: libtool related build questions
On 12/14/06, Ralf Wildenhues [EMAIL PROTECTED] wrote: * Christopher Hulbert wrote on Thu, Dec 14, 2006 at 08:11:20PM CET: On 12/14/06, Bob Rossi [EMAIL PROTECTED] wrote: *** Warning: This system can not link to static lib archive /home/bobbybrasko/log4cxx/apr-util/src/prefixdir/lib/libaprutil.la. *** I have the capability to make that library automatically link in when *** you link to this library. But I can only do this if you have a *** shared version of the library, which you do not appear to have. They are sometimes bogus. Nobody has gotten around to fixing that yet. I used to get these a lot. They are very very likely _not_ bogus in your case, and your case very very likely has nothing whatsoever to do with Bob's. Linking shared libraries against static ones is a bad idea in general, and most often a hack. IIRC the warning was bogusly output sometimes when the static library really was a convenience archive. And there are cases on w32 systems where you simply have to link against static libraries in some cases. I have not removed this, so I'm not sure if the most recent libtool still issues these warnings and refuses to build the shared libraries. Wait until you move from you GNU Linux/x86 to a x86_64 one, for example (I'm guessing here; please correct me if wrong), to see your setup blow up. It works fine on x86, x86_64, and win32. I have not tried win64, OS X, solaris, etc. The message is not bogus in the way you define that term, but to _some_ extent it is bogus because the message clearly says the system cannot link against a static library which is flat wrong. It may be insert your degree here ill advised to do so, but it at least appears to work and without any problems (at least none I've found in the last year or two). I'm not saying this is an endorsed way of performing the operation, but I find it better than the alternative of delivering 4 shared libraries so a user can call a single function from Matlab. Just my thoughts though, Chris Hope that helps. Cheers, Ralf ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Absolute paths generated by libtool.
On 11/14/06, Benoit Sigoure [EMAIL PROTECTED] wrote:
Hello folks.
I'm developing Qt-based applications. The build system is controlled by the
autotools rather than by Qmake.
I'm porting our projects on Windows. We're using an automated build system
(buildbot.sf.net) to build every commit on Linux/OSX/Windows. Automating the
process on Windows proved to be really annoying. I looked at how other
projects do it (Python, KDE, Subversion etc.) they all seem to use hand
written .bat files and/or Makefile.vc (for Visual C++) with nmake and co. I
didn't want to deal with special Makefiles or setting up a special build
system for each project, so I tried to do something more generic.
Things are rather complicated but I'll try to explain them here. Everything
might not be relevant to the problem described below but I suppose you people
have a good experience about porting applications so you might be able to
advise me.
First off, I chose to use a Cygwin environment for the buildfarm. This was
convenient since Cygwin comes with lots of packages (python, vim, zsh etc)
and make it easy to have a complete environment on the Windows machine. The
buildbot (which is a python app) runs in that environment.
Qt distributes Windows binaries for mingw only so I ended up installing
mingw. This entails that everything is built by the mingw-gcc toolchain rather
than by the cygwin-gcc. Anyway, I *guess* that building mingw apps in a
Cygwin environment isn't a problem since there is probably not much
differences between both.
You can compile in mingw mode by using the -mno-cygwin flag to cygwin gcc.
However, doing this made me run into several problems. For instance, Qt
generates Makefiles that have rules such as:
C:\Foo\Bar: C:\Baz\Qux
Which is a problem for cygwin's GNU make (since it sees C as a target). For
some reason the mingw GNU make has no problem with this kind of rule, I guess
they patched it. Nevermind, let's use mingw GNU make. The problem is that
when make runs commands such as C:\Qt\4.2.1\bin\moc.exe, the backslashes are
interpreted by the shell (cygwin's shell) which leads to the execution of the
command C:Qt4.2.1binmoc.exe. I tried to use MSYS's shell (the shell provided
with mingw) or cmd.exe directly but this wouldn't work (for some reason it
always ended up running C:Qt4.2.1binmoc.exe).
I ran into this recently with the latest cygwin make 3.81. The move
from 3.80 to 3.81 dropped support for dos style paths. here is a link
to a patch which worked for me. Note that you need to install the
source for make which ends up in /usr/src.
http://thread.gmane.org/gmane.comp.gnu.make.windows/2058/focus=2147
And here's an example after compiling.
-bash-3.2$ cat Makefile
c:\cygwin\home\chulbert\test.exe: c:\cygwin\home\chulbert\test.c
gcc -mno-cygwin test.c
-bash-3.2$ cat test.c
#include stdlib.h
#include stdio.h
int
main(void)
{
return EXIT_SUCCESS;
}
-bash-3.2$ make
gcc -mno-cygwin test.c
My idea was to write a perl script and to invoke make SHELL=my_shell.pl. That
script would rewrite the command properly so that it works within the Cygwin
environment. I succeeded and I can now run configure scripts and compile my
projects using that shell-wrapper.
In order to make this automatic and transparent, I have ~/bin first in my
PATH and I wrote a shell script named make.exe there that forwards the
invocation of make to mingw's GNU make with the SHELL variable set.
Hopefully you can get rid of all this if you use the patched make?
However, on last problem remains, and that's where libtool comes in. MingW
applications don't know anything about the cygwin environment, they're not
aware of the pseudo filesystem emulated by cygwin. At the end of the
compilation, libtool is invoked to link the final executable but for some
reason, it transforms a relative path in an absolute one:
*snip link*
/home/build/build/urbidev_winxp/build/behavior-graphs/src/xml_parser/.libs/libfsm_xml_parser.a:
No such file or directory
Make sure to specify prefix and exec-prefix in the form
c:/path/for/install. This is what libtool puts in the .la (I think).
* snip other question, etc *
___
http://lists.gnu.org/mailman/listinfo/libtool
Re: Absolute paths generated by libtool.
On 11/14/06, Benoit Sigoure [EMAIL PROTECTED] wrote:
Quoting Christopher Hulbert [EMAIL PROTECTED]:
My idea was to write a perl script and to invoke make
SHELL=my_shell.pl. That
script would rewrite the command properly so that it works within the Cygwin
environment. I succeeded and I can now run configure scripts and compile my
projects using that shell-wrapper.
In order to make this automatic and transparent, I have ~/bin first in my
PATH and I wrote a shell script named make.exe there that forwards the
invocation of make to mingw's GNU make with the SHELL variable set.
Hopefully you can get rid of all this if you use the patched make?
I don't think so, this problem is independant of make.
make will always end up running /bin/sh -c C:\Qt\4.2.1\bin\... which
will always
yield C:Qt4.2.1bin. Unless your patch (which I haven't looked yet) also
provides
some black magic to reverse the backslashes.
I *think* it will work. Perhaps this would convince you more:
-bash-3.2$ rm test.exe
-bash-3.2$ cat test.c
#include stdlib.h
#include stdio.h
int
main(void)
{
printf(test.exe\n);
return EXIT_SUCCESS;
}
-bash-3.2$ cat Makefile
c:\cygwin\home\chulbert\test.exe: c:\cygwin\home\chulbert\test.c
gcc -mno-cygwin -o $@ $
-bash-3.2$ make
gcc -mno-cygwin -o c:\cygwin\home\chulbert\test.exe
c:\cygwin\home\chulbert\test.c
-bash-3.2$ ./test.exe
test.exe
However, on last problem remains, and that's where libtool comes in. MingW
applications don't know anything about the cygwin environment, they're not
aware of the pseudo filesystem emulated by cygwin. At the end of the
compilation, libtool is invoked to link the final executable but for some
reason, it transforms a relative path in an absolute one:
*snip link*
/home/build/build/urbidev_winxp/build/behavior-graphs/src/xml_parser/.libs/libfsm_xml_parser.a:
No such file or directory
Make sure to specify prefix and exec-prefix in the form
c:/path/for/install. This is what libtool puts in the .la (I think).
I highly doubt it's the case (although I haven't tried ATM) because the
.la has
references to the build dir.
Can you post the .la file?
___
http://lists.gnu.org/mailman/listinfo/libtool
picewise linking and MS lib.exe
Piecewise linking with the MS archiver (lib) doesn't work. Every
invocation of the lib clobbers the old one. The solution is to list
the library as the first object (really anywhere should be fine) in
the next lib command. I'm not sure how to patch this. It looks like
the piecewise linking code in ltmain.m4sh doesn't depend on what
linker it's using. Any ideas on how best to patch this?
e.g.
[EMAIL PROTECTED] ~
$ cat test1.c test2.c
#include stdlib.h
double add(double x,double y)
{
return (x+y);
}
#include stdlib.h
double sub(double x,double y)
{
return (x-y);
}
[EMAIL PROTECTED] ~
$ pgcc -c test1.c test2.c
test1.c:
test2.c:
[EMAIL PROTECTED] ~
$ lib /out:libtest.lib test.o
Microsoft (R) Library Manager Version 7.10.3077
Copyright (C) Microsoft Corporation. All rights reserved.
[EMAIL PROTECTED] ~
$ lib /list libtest.lib
Microsoft (R) Library Manager Version 7.10.3077
Copyright (C) Microsoft Corporation. All rights reserved.
test.o
[EMAIL PROTECTED] ~
$ lib /out:libtest.lib test2.o
Microsoft (R) Library Manager Version 7.10.3077
Copyright (C) Microsoft Corporation. All rights reserved.
[EMAIL PROTECTED] ~
$ lib /list libtest.lib
Microsoft (R) Library Manager Version 7.10.3077
Copyright (C) Microsoft Corporation. All rights reserved.
test2.o
[EMAIL PROTECTED] ~
$ lib /out:libtest.lib libtest.lib test.o
Microsoft (R) Library Manager Version 7.10.3077
Copyright (C) Microsoft Corporation. All rights reserved.
[EMAIL PROTECTED] ~
$ lib /list libtest.lib
Microsoft (R) Library Manager Version 7.10.3077
Copyright (C) Microsoft Corporation. All rights reserved.
test.o
test2.o
___
Bug-libtool mailing list
Bug-libtool@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-libtool
Re: Cygwin failure with large number of sources
On 6/14/06, Ralf Wildenhues [EMAIL PROTECTED] wrote: * Christopher Hulbert wrote on Wed, Jun 14, 2006 at 04:37:50PM CEST: On 6/14/06, Ralf Wildenhues [EMAIL PROTECTED] wrote: setting not trigger a multiple archiver invocation? All these questions may be answered by the output of ./libtool --debug [rest of command line] log 21 That won't work. It's crashing I guess trying to call libtool with all those arguments. Ah, there is a fix for this: Create a file with all objects listed in it. Use it as argument to the libtool option -objectlist. If you want to create the file from a Makefile, and have all the object names in a variable, you could do echo $(ALLOBJECTS) | tr ' ' '\n' libfoo.objectlist but it could possibly fail as well (the shell command being too long, too), leaving you with the need to resort to some other means to create the list, possibly by using make variables which contain only subsets of object names which are short enough for the command line. If that still fails, but now inside libtool, post as decribed above. Cheers, Ralf Well, this library wont add/rm source files too often, so I'll create the file statically and just add the -objlist flag to the AM_LDFLAGS variable? As a side, I posted to the libtool mailing list about some more PGI conflicts I'm having. It's not necessarily a libtool bug since it assumes msvc support if not using the gcc compiler. It seems to work if I manually set the with_gcc=yes in the libtool script. Can I pass that on the AM_LDFLAGS variable? ___ Bug-libtool mailing list Bug-libtool@gnu.org http://lists.gnu.org/mailman/listinfo/bug-libtool
with_gcc using PGI compilers windows
It's been a long time since I've tried the PGI compilers with the autotools. I usually get frustrated and go a way for a while. Anyways, I ran into a problem I don't remember having before [updating the CVS source]. When with_gcc is not set to yes, libtool is replacing library files, -la with a.lib (assuming msvc). The problem is the PGI compilers won't look for a.lib in any of the -L arguments. Manually setting with_gcc=yes allows linking in the -L -l manner. So, I was wondering if a libtool autoconf test for linking style on windows would be better, or just manually adding pgcc, pgCC, and pgf* to the ones that set with_gcc=yes. As an aside does this really work with msvc? I thought msvc used -LIBPATH. Also, I had sent a patch in a while ago about making DLL's with the PGI compilers (-Mmakedll flag) that I guess never made it in. I remember having problems running the tests. I guess at some point I'll try to rerun that to get that fixed. ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: with_gcc using PGI compilers windows
On 6/13/06, Christopher Hulbert [EMAIL PROTECTED] wrote: [snip] Also, I had sent a patch in a while ago about making DLL's with the PGI compilers (-Mmakedll flag) that I guess never made it in. I remember having problems running the tests. I guess at some point I'll try to rerun that to get that fixed. Ignore that. I was picking up the older libtool m4 macros. The newer ones do indeed use -Mmakedll. PGI compilers with autotools are looking promising despite the lib renaming. ___ http://lists.gnu.org/mailman/listinfo/libtool
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
Re: exclusive static or shared
I normally do not create shared libraries. The ONE place I do though is with Matlab MEX functions which are nothing more than a shared library with the mexFunction as an exported function. I link my Matlab code against static libraries that contain my real functions (The matlab interface serves exactly that an interface from matlab to my C/fortran backend). Although it's not advised it works on 3 main platforms that we use matlab on x86,x86_64,and win32. The comment/suggestion was not a necessity, but would facilitate my option as a user/developer to build both shared and static libraries and be able to link the Matlab code against either (without separate builds). It's really no big deal though. Maybe this little spiel will give you an idea of where I start doing wacky things with libtool :)! On 2/17/06, Ralf Wildenhues [EMAIL PROTECTED] wrote: Hi Christopher, * Christopher Hulbert wrote on Wed, Feb 15, 2006 at 04:10:20PM CET: Lets say I build library liba as both static and shared (thus I have liba.a and liba.so or liba.lib and liba.dll). I later want to build libb.so or libb.dll against the installed liba. From my observations it always takes the shared liba. Is this true, or is there a flag to tell it to use static libraries where available (similar to -i-static for intel compiler). I was thinking something like -libtool-static or -libtool-static=-la,-lxyz where the comma-separated list is a list of libraries this rule applies to. Any thoughts on the matter? Yes, there are some thoughts: First, don't let shared libraries have static libraries as dependencies. It's a pain, there are many systems where this will not work as desired, and making sure you never end up with duplicate symbols and/or arising subtle bugs is not easy. Text relocations cost shareability and lots of memory on some systems, and if they cause a sufficient speedup, it usually means your interface design is broken. Surely I acknowledge that on _some_ systems things may be differently, but Libtool is about portable library creation. And after all, it is possible to achieve this now by the workaround of creating several instances of a library (don't bother us with bug reports then, though; I won't read them). On systems without pass_all, libtool will not actually _include_ the static library into the shared one, though, but record the dependency in the .la file so that it can be fulfilled when a program is created. Second, there was recently a longish thread about per-deplib static/ shared flags for creating programs, including patches. Likely, soon after 2.0 is released some progress on that issue can be expected. ;-) Third, there is a pending patch implementing `-static-libtool-libs', to be applied before 2.0 hopefully. Cheers, Ralf ___ http://lists.gnu.org/mailman/listinfo/libtool
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
Re: exclusive static or shared
On 2/15/06, Ralf Wildenhues [EMAIL PROTECTED] wrote: Hi Christopher, * Christopher Hulbert wrote on Tue, Feb 14, 2006 at 11:08:28PM CET: I have a number of directories most of which I ONLY want to build shared libraries from. There are a couple that I ONLY want static libraries. Is there a way to turn on/off shared/static libraries. I saw -static which would work IF both build_old_libs=yes. Is there any way to have -static set build_old_libs=yes? This is on cygwin with libtool 1.5.22. Is there a -shared equivelent to disable static and enable shared library building? Here's a set of rules. The developer can set preferences on a per-(sub)package basis by using AC_ENABLE_SHARED AC_DISABLE_SHARED AC_ENABLE_STATIC AC_DISABLE_STATIC in the respective configure.ac files. The user can do so per-(sub)package with --enable-shared=pkgs --disable-shared=pkgs --enable-static=pkgs --disable-static=pkgs and override above macros thusly. I guess I didn't make it clear enough that ALL the subdirectories were under the same configure script and doesn't make logical sense to split them. Assuming a package that uses Automake, the developer can control this on a per-library basis by putting -static into the *LDFLAGS that affect libtool-created libraries. The user can override this (usually on a per-make invocation basis) by using the flag in LDFLAGS, but has to make sure only libtool-created libraries (and not any other linked targets) are affected. I had shared libraries enables and static disabled from configure. In passing -static to the 1 library I wanted to be static, it created the library, but without any object files in it. i.e. it was an empty library and thus resulted in missing symbols later. I found If I enabled static libraries at configure time The objects would be put in, but the 30 shared libraries I wanted all got useless static ones built which wasted time and space. The developer or the user can possibly limit the types of libraries created by using the --tag=disable-shared --tag=disable-static tags for libtool. To use these correctly, there are a few things to be noted though: - Shared libraries may not have been disabled at configure time. - These tags work with both 1.5.x and CVS libtool versions, but are not (yet) documented. - These flags need to go before the compiler: speaking in Automake terms, they would fit in LIBTOOLFLAGS but not in LDFLAGS. - We took liberty to change (fix) their semantics in 1.5.22 to this: If you pass --tag=disable-shared --tag=CXX then previously, the CXX configuration could overwrite the disabling of shared libraries. Now that does not happen any more. The new behavior (in branch-1-5 and HEAD) gives the disable-* tags precedence over the language tags. - Until we document the tags, we'll probably take liberty to change them again if we encounter more issues that we don't like. The LIBTOOLFLAGS is the variable I was looking for! Of course tag's don't work in LDFLAGS because they come after the compiler (another shot at the problem I took). I will try setting LIBTOOLFLAGS later today. On a side note, I have started to dig into the libtool CVS internals and have created a patch for the PGI wl= and -link -dll problem I was receiving. When I get to work I will test these and submit them to the libtool-patches list. Chris With all of the aforementioned measures, one has to take the following additional rule into account: Libtool will never disable all types of libraries. That means, it will usually fall back to static libraries because it is usually possible to create them everywhere. It is furthermore important to note that there are systems where libtool will not build static libraries by default (AIX without runtimelinking) or not build shared libraries at all. Hope that helps (and gives enough flexibility). Cheers, Ralf ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: exclusive static or shared
On 2/15/06, Ralf Wildenhues [EMAIL PROTECTED] wrote: Hi Christopher, * Christopher Hulbert wrote on Wed, Feb 15, 2006 at 12:28:59PM CET: On 2/15/06, Ralf Wildenhues [EMAIL PROTECTED] wrote: Here's a set of rules. I guess I didn't make it clear enough that ALL the subdirectories were under the same configure script and doesn't make logical sense to split them. Oh, you made that clear. You are not the only reader of this mailing list, though, and I thought it to be appropriate to give a general answer that is useful for more than one specific purpose. Assuming a package that uses Automake, the developer can control this on a per-library basis by putting -static I had shared libraries enables and static disabled from configure. In passing -static to the 1 library I wanted to be static, it created the library, but without any object files in it. i.e. it was an empty library and thus resulted in missing symbols later. Ahh! Now this may be a bug, I believe. I cannot reproduce this in a test, though. Can you show me how to reproduce it? Which Libtool version? How did you configure exactly? On what $host? config.log? Having a problem reproducing it now that I've installed the CVS libtool :(. and have created a patch for the PGI wl= and -link -dll problem I was receiving. When I get to work I will test these and submit them to the libtool-patches list. Well, some of the issues arise from the first MSVC patches: a couple of times there was the assumption that on win32, non-gcc compiler meant MSVC. You'd need to undo that. And then go and set the flags in _LT_COMPILER_PIC correctly (for both CXX and other tags). And then you can check all the other PORTME instances in libtool.m4 to see whether they need adaptation, too. ;-) Working on the patch now, I'll send it here If I don't get a confimation email from libtool-patches before it's done. Cheers, Ralf ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: exclusive static or shared
Ok, I sent the patch to libtool-patch. Another question I have wondered is as follows: Lets say I build library liba as both static and shared (thus I have liba.a and liba.so or liba.lib and liba.dll). I later want to build libb.so or libb.dll against the installed liba. From my observations it always takes the shared liba. Is this true, or is there a flag to tell it to use static libraries where available (similar to -i-static for intel compiler). I was thinking something like -libtool-static or -libtool-static=-la,-lxyz where the comma-separated list is a list of libraries this rule applies to. Any thoughts on the matter? On 2/15/06, Ralf Wildenhues [EMAIL PROTECTED] wrote: [ off-list ] Hi Christopher, * Christopher Hulbert wrote on Wed, Feb 15, 2006 at 02:24:10PM CET: On 2/15/06, Ralf Wildenhues [EMAIL PROTECTED] wrote: Well, some of the issues arise from the first MSVC patches: a couple of times there was the assumption that on win32, non-gcc compiler meant MSVC. You'd need to undo that. And then go and set the flags in _LT_COMPILER_PIC correctly (for both CXX and other tags). And then you can check all the other PORTME instances in libtool.m4 to see whether they need adaptation, too. ;-) ___ http://lists.gnu.org/mailman/listinfo/libtool
Bug with linker flags under cygwin?
I'm trying to pass some options to the linker using -Wl,opt1,opt2, Libtool is not placing the -Wl, in front of each argument because in the generated libtool script, wl=. If I manually replace that with wl=-Wl, it prepends arguments with it as expected. bash-3.00$ uname -a CYGWIN_NT-5.1 maxwell 1.5.19(0.150/4/2) 2006-01-20 13:28 i686 Cygwin bash-3.00$ ../libtool --version cygpath: can't convert empty path ltmain.sh (GNU libtool) 1.5.22 (1.1220.2.365 2005/12/18 22:14:06) Copyright (C) 2005 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. ___ http://lists.gnu.org/mailman/listinfo/libtool
archive_commands
archive_cmds=\$CC -o \$lib \$libobjs \$compiler_flags \\\`echo $deplibs\\\ | \$SED -e 's/ -lc\$//'\\\` -link -dll~linknames= What is the -link and -dll doing? This messes up my linking with the PGI C compiler as it can't find liblink.a. libtool 1.5.22 ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: archive_commands
On 2/10/06, Christopher Hulbert [EMAIL PROTECTED] wrote: archive_cmds=\$CC -o \$lib \$libobjs \$compiler_flags \\\`echo $deplibs\\\ | \$SED -e 's/ -lc\$//'\\\` -link -dll~linknames= What is the -link and -dll doing? This messes up my linking with the PGI C compiler as it can't find liblink.a. libtool 1.5.22 I should note that the option for PGI to create dll's is -Mmakedll. My current workaround is to have autoconf run a shell script after libtool is creatied and run sed -e 's/-link -dll/-Mmakedll/'. I THINK the 6.2 release of the Win32 PGI compilers will support -shared, but I should note that it does not appear that -shared would be put on the command line anyways like it is with gcc. ___ http://lists.gnu.org/mailman/listinfo/libtool
libtool rearranging library paths
I have a some fortran code compiled by libtool into a static (convenience archive). Later I compile a C source file into a shared library linking against the fortran library. Since automake/libtool have no knowledge that the objects are from fortran, I add in the necessary fortran libraries. The problem I get is with PIC. libtool is changing the order of my library paths and picking up a non-PIC PGI fortran library. I have fought with libtool for days and cannot figure out why. I can provide the debug output if necessary, but here are the few commands that show the rearranging. Note that in the libtool --mode=link command /usr/local/pgi/linux86-64/6.0/libso is before /usr/local/pgi/linux86-64/6.0/lib, but in the actual command executed, the order is reversed, Also, why is libtool not passing the PIC flag to the pgcc command? I told it to use PIC and it uses PIC in the compile stage. NOTE that this only happens on 64-bit platform because the 32-bit platform has only one directory. /bin/sh ../libtool --tag=CC --mode=link pgcc -O0 -Wall -g --exceptions -m64 -g -no-undefined -module -avoid-version -shrext .mexa64 -Wl,--wrap,malloc,--wrap,calloc,--wrap,free,--wrap,assert -L../libislmex -L../libscatsmex -pthread -shared -Wl,--version-script,/usr/local/matlab71/extern/lib/glnxa64/mexFunction.map -o llh2ecef.la -rpath /home/chulbert/ISLtools_v1.2/i686-pc-linux-gnu/mex/geo_mex llh2ecef_la-llh2ecef.lo -lscatsmex -L../../libscats -lscats -L../../libseke -lseke -L../../libscatsio -lscatsio -L/apps/lib64 -lvsip /apps/lib64/libz.a -L/usr/local/pgi/linux86-64/6.0/libso -L/usr/local/pgi/linux86-64/6.0/lib -L/usr/lib64 -L/usr/lib/gcc/x86_64-redhat-linux/4.0.0 -lpgf90 -lpgf90_rpm1 -lpgf902 -lpgf90rtl -lpgftnrtl -lnspgc -lpgc -lm -L/apps/lib64 -lvsip -lislmex -Wl,--rpath-link,/usr/local/matlab71/extern/lib/glnxa64,--rpath-link,/usr/local/matlab71/bin/glnxa64 -L/usr/local/matlab71/bin/glnxa64 -lmx -lmex -lmat -lm -lm *** Warning: Linking the shared library llh2ecef.la against the *** static library /apps/lib64/libz.a is not portable! rm -fr .libs/llh2ecef.lax rm -fr .libs/llh2ecef.lax mkdir .libs/llh2ecef.lax rm -fr .libs/llh2ecef.lax/libscats.a mkdir .libs/llh2ecef.lax/libscats.a (cd .libs/llh2ecef.lax/libscats.a ar x /home/chulbert/ISLtools/build-fedora4.0/scats/libscats/.libs/libscats.a) rm -fr .libs/llh2ecef.lax/libseke.a mkdir .libs/llh2ecef.lax/libseke.a (cd .libs/llh2ecef.lax/libseke.a ar x /home/chulbert/ISLtools/build-fedora4.0/scats/libseke/.libs/libseke.a) rm -fr .libs/llh2ecef.lax/libscatsio.a mkdir .libs/llh2ecef.lax/libscatsio.a (cd .libs/llh2ecef.lax/libscatsio.a ar x /home/chulbert/ISLtools/build-fedora4.0/scats/libscatsio/.libs/libscatsio.a) pgcc -shared .libs/llh2ecef_la-llh2ecef.o .libs/llh2ecef.lax/libscats.a/cover.o .libs/llh2ecef.lax/libscats.a/scatsMAT.o .libs/llh2ecef.lax/libscats.a/matrix.o .libs/llh2ecef.lax/libscats.a/geo.o .libs/llh2ecef.lax/libscats.a/los.o .libs/llh2ecef.lax/libscats.a/seke.o .libs/llh2ecef.lax/libscats.a/scatsfft.o .libs/llh2ecef.lax/libscats.a/grid.o .libs/llh2ecef.lax/libscats.a/scatsmath.o .libs/llh2ecef.lax/libscats.a/cov.o .libs/llh2ecef.lax/libscats.a/noise.o .libs/llh2ecef.lax/libscats.a/pattern.o .libs/llh2ecef.lax/libscats.a/array.o .libs/llh2ecef.lax/libscats.a/scats_loop.o .libs/llh2ecef.lax/libscats.a/timing.o .libs/llh2ecef.lax/libscats.a/scats.o .libs/llh2ecef.lax/libscats.a/terrain.o .libs/llh2ecef.lax/libseke.a/libseke_la-El2Prop.o .libs/llh2ecef.lax/libseke.a/libseke_la-Goptap2.o .libs/llh2ecef.lax/libseke.a/libseke_la-Paraf4.o .libs/llh2ecef.lax/libseke.a/libseke_la-Scenario.o .libs/llh2ecef.lax/libseke.a/libseke_la-tvertf1.o .libs/llh2ecef.lax/libseke.a/libseke_la-setel.o .libs/llh2ecef.lax/libseke.a/libseke_la-Kesrch.o .libs/llh2ecef.lax/libseke.a/libseke_la-Kedey7.o .libs/llh2ecef.lax/libseke.a/libseke_la-Linef4.o .libs/llh2ecef.lax/libseke.a/libseke_la-geose1.o .libs/llh2ecef.lax/libseke.a/libseke_la-trajap0.o .libs/llh2ecef.lax/libseke.a/libseke_la-rland0.o .libs/llh2ecef.lax/libseke.a/libseke_la-Sph35n1.o .libs/llh2ecef.lax/libseke.a/libseke_la-sekea16.o .libs/llh2ecef.lax/libscatsio.a/scatsio.o .libs/llh2ecef.lax/libscatsio.a/snprintf.o .libs/llh2ecef.lax/libscatsio.a/scatsfileio.o .libs/llh2ecef.lax/libscatsio.a/scatsBIL.o .libs/llh2ecef.lax/libscatsio.a/scatsGridFloat.o -L/usr/lib/gcc/x86_64-redhat-linux/4.0.0 -L/usr/lib64 -L/usr/local/pgi/linux86-64/6.0/lib -L/usr/local/pgi/linux86-64/6.0/libso -L/home/chulbert/ISLtools/build-fedora4.0/scats/libseke/.libs -L/home/chulbert/ISLtools/build-fedora4.0/scats/mex/libislmex -L/home/chulbert/ISLtools/build-fedora4.0/scats/mex/libscatsmex -pthread -lscatsmex -L/home/chulbert/ISLtools/build-fedora4.0/scats/libscats -L/home/chulbert/ISLtools/build-fedora4.0/scats/libseke -L/home/chulbert/ISLtools/build-fedora4.0/scats/libscatsio -L/apps/lib64 /apps/lib64/libz.a -lpgf90 -lpgf90_rpm1 -lpgf902 -lpgf90rtl -lpgftnrtl -lnspgc -lpgc -lvsip -lislmex -L/usr/local/matlab71/bin/glnxa64 -lmx -lmex -lmat -lm -lc
