Wgcc 2.0 RC2 released.
wgcc is a cross-compiler tool primarily written for Microsoft's Interix. Its primary purpose is to produce native Windows binaries (internally using the Microsoft Tool chain), and to mimic the behaviour of the GNU compiler collection. This means that wgcc understands many of GCC's command line arguments, and in most cases delivers the same results as expected, sometimes manipulating the underlying tool's input and output. Even though wgcc was written for Interix only, it can be used on native Windows (without Interix), and other Systems, like Cygwin. The only restriction is that on Platforms other than Interix, only Windows style paths are understood. This will change in the future for Cygwin, and/or others. On Interix wgcc automatically converts UNIX style paths to Windows style ones (i.e. /wgcc to C:\SFU\wgcc). wgcc abstracts away lots of inconveniences that are introduced by building static libraries, shared libraries (DLL's) and executables with any possible combination of those three. When using wgcc both static and shared libraries behave exactly the same on Windows, and this makes tons of defines unnecessary. The only thing that still has to be done is to give all Data symbols (i.e. Variables) an import attribute (__declspec(dllimport)) when using them (i.e. in the library header files) in an executable. For a simple example take a look at the file tests/shared.test inside the wgcc distribution. The Release Candidate 2 of wgcc is more or less a bug fix release compared to RC1. There is not too much new. Bug fixes include a nearly complete rewrite of the Import Trampoline gererator and the Export Definition generator, since those two worked very bad for C, but only for C++. pxwc has been reviewed and changed a little, to not include that many defines, where inlined static functions are possible. Still pxwc currently includes only a small set of functions, so your help is needed to find out which others to include. Just open a Feature Request at http://sourceforge.net/tracker/?group_id=158081atid=806407 and we will try to add functionality as soon as possible. To continue improving wgcc and pxwc packages, we now need your help in testing them. Please download wgcc and try to compile your software using it. If something goes wrong please contact mduft or open an issue using the Sourceforge Tracker at http://sourceforge.net/tracker/?group_id=158081atid=806404, or ask your questions at the forums at http://sourceforge.net/forum/?group_id=158081. You can browse the Subversion Repository here: http://svn.sourceforge.net/viewvc/interix-wgcc/trunks/ Documentation can be found here: http://sourceforge.net/project/showfiles.php?group_id=158081package_id= 203917release_id=446943 Source Packages can be found here: http://sourceforge.net/project/showfiles.php?group_id=158081package_id= 177049release_id=445894 The Patch for Libtool can be found here: http://sourceforge.net/project/showfiles.php?group_id=158081package_id= 196163release_id=446510 Cheers, Markus ___ http://lists.gnu.org/mailman/listinfo/libtool
gcov
Hello all, I use libtool 1.5.22 in my project. I have the following directory structure: /dir/ /dir/build/ /dir/build/.libs/ /dir/build/.libs/a.o /dir/build/a.lo /dir/build/a.o /dir/prj/ /dir/prj/a/ /dir/prj/a/a.c When I call gcov under /dir/build, it says stamp mismatch with graph file (perhaps the *.gc* files do not match a.o?). So I call it from /dir/build/.libs. In this case, a.c is looked for in ../prj/a, which doesn't exist. So, I've ln -s ../prj /dir/build/prj. Then gcov works as expected. Is there a better way to do that? Thanks in advance, Baurzhan. ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: gcov
Hello Baurzhan, * Baurzhan Ismagulov wrote on Fri, Sep 22, 2006 at 02:19:32PM CEST: /dir/ /dir/build/ /dir/build/.libs/ /dir/build/.libs/a.o /dir/prj/ /dir/prj/a/ /dir/prj/a/a.c When I call gcov under /dir/build, it says stamp mismatch with graph file (perhaps the *.gc* files do not match a.o?). So I call it from /dir/build/.libs. In this case, a.c is looked for in ../prj/a, which doesn't exist. So, I've ln -s ../prj /dir/build/prj. Then gcov works as expected. Is there a better way to do that? Does libtool --mode=execute gcov ... work? Cheers, Ralf ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: gcov
Hello Ralf, thanks much for your prompt answer! On Fri, Sep 22, 2006 at 02:59:15PM +0200, Ralf Wildenhues wrote: When I call gcov under /dir/build, it says stamp mismatch with graph file (perhaps the *.gc* files do not match a.o?). So I call it from /dir/build/.libs. In this case, a.c is looked for in ../prj/a, which doesn't exist. So, I've ln -s ../prj /dir/build/prj. Then gcov works as expected. Is there a better way to do that? Does libtool --mode=execute gcov ... Nope, stamp mismatch with graph file when called from /dir/build. With kind regards, Baurzhan. ___ http://lists.gnu.org/mailman/listinfo/libtool
cannot install...to a directory not ending in
Okay, I've run into this enough that it's taken its toll on me and I must know the proper modern way to handle this. For years and years, the following worked fine for any GNU app using autoconf: ./configure --prefix=/my/final/destination make make install prefix=/my/to-be-released/destination This concept is used almost anywhere AFS/OpenAFS is used and anywhere there is a process in place to release software to its final destination. It has often not worked when involving libtool over the last year or two and it's driving me nuts. Can someone PUHLZE tell me the right way to do this? GCC 4.1.1 today: build:quake ../gcc-4.1.1/configure --prefix=/usr/rcf ... build:quake make bootstrap ... build:quake make install prefix=/afs/rcf/system/dest/lin24v2/local/gcc/040/ ... libtool: install: error: cannot install `libgij.la' to a directory not ending in /usr/rcf/lib ... ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: cannot install...to a directory not ending in
Hello Jeff, * Jeff Blaine wrote on Fri, Sep 22, 2006 at 04:17:07PM CEST: Okay, I've run into this enough that it's taken its toll on me and I must know the proper modern way to handle this. Hmm. This sounds like it used to work before and we broke something. Is it what you are implying? For years and years, the following worked fine for any GNU app using autoconf: ./configure --prefix=/my/final/destination make make install prefix=/my/to-be-released/destination Not with Libtool-using packages, at least not bug-free, as far as I remember. make install DESTDIR=/my/staging/directory works to install your stuff temporarily into /my/staging/directory/my/final/destination from where it can be moved to /my/final/destination and, after a libtool --mode=finish /my/final/destination/lib libraries should be useable. There are issues in current libtool that prevent this from working properly in _some_ cases when you try to link against third-party libraries that currently are visible below /my/staging/directory/my/final/destination but are to finally appear at /my/final/destination/ See some other discussion on this list just this week. It has often not worked when involving libtool over the last year or two and it's driving me nuts. Can someone PUHLZE tell me the right way to do this? Well, I'm really sorry you've had so much trouble, and I can only ask to report issues earlier. If you think there is a regression involved then please point me to a package where this should have worked. Hope that helps. Cheers, Ralf ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: message to the bug-libtool list
[ bug-libtool readers: the original bug report was filtered ] Hello Jitesh, * Jitesh Jhatakia wrote on Fri, Sep 22, 2006 at 05:16:12PM CEST: Tagdemo-make.test failed 2 times once for tagdemo-conf.test and 2nd time for tagdemo-shared.test. Thanks for the bug report. Could you please post the output of ./libtool --config and the output of env VERBOSE=x TESTS=tagdemo-conf.test tagdemo-make.test \ tagdemo-exec.test tagdemo-shared.test tagdemo-make.test \ tagdemo-exec.test make -e check ? Thank you. Cheers, Ralf ___ Bug-libtool mailing list Bug-libtool@gnu.org http://lists.gnu.org/mailman/listinfo/bug-libtool
Re: cannot install...to a directory not ending in
I believe the problem being described here is one that I have encountered also since I use stow for package management. A long time ago, it use to be the case you could say: ./configure --prefix=/dest make make prefix=/dest/stow/package-package version install even if the package installed shared objects. With more recent versions of libtool, I have had to add the --with-libdir=/dest/stow/package-package version/lib to allow proper installation. Ed Ralf Wildenhues wrote: Hello Jeff, * Jeff Blaine wrote on Fri, Sep 22, 2006 at 04:17:07PM CEST: Okay, I've run into this enough that it's taken its toll on me and I must know the proper modern way to handle this. Hmm. This sounds like it used to work before and we broke something. Is it what you are implying? For years and years, the following worked fine for any GNU app using autoconf: ./configure --prefix=/my/final/destination make make install prefix=/my/to-be-released/destination Not with Libtool-using packages, at least not bug-free, as far as I remember. make install DESTDIR=/my/staging/directory works to install your stuff temporarily into /my/staging/directory/my/final/destination from where it can be moved to /my/final/destination and, after a libtool --mode=finish /my/final/destination/lib libraries should be useable. There are issues in current libtool that prevent this from working properly in _some_ cases when you try to link against third-party libraries that currently are visible below /my/staging/directory/my/final/destination but are to finally appear at /my/final/destination/ See some other discussion on this list just this week. It has often not worked when involving libtool over the last year or two and it's driving me nuts. Can someone PUHLZE tell me the right way to do this? Well, I'm really sorry you've had so much trouble, and I can only ask to report issues earlier. If you think there is a regression involved then please point me to a package where this should have worked. Hope that helps. Cheers, Ralf ___ http://lists.gnu.org/mailman/listinfo/libtool smime.p7s Description: S/MIME Cryptographic Signature ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: gcov
Hello Baurzhan, * Baurzhan Ismagulov wrote on Fri, Sep 22, 2006 at 03:28:09PM CEST: When I call gcov under /dir/build, it says stamp mismatch with graph file (perhaps the *.gc* files do not match a.o?). So I call it from /dir/build/.libs. In this case, a.c is looked for in ../prj/a, which doesn't exist. So, I've ln -s ../prj /dir/build/prj. Then gcov works as expected. Is there a better way to do that? libtool --mode=execute gcov ... Nope, stamp mismatch with graph file when called from /dir/build. Hmm, ok. Can you show a bit what you're doing? My small tests with libtool/tests/demo must be too simplistic to expose the issue fully. Meanwhile, I think there also is a simple workaround: if you configure with an absolute path: mkdir build cd build /absolute/path/to/source/tree/configure [...] make then you should be able to skip the symlinking step; but it seems you still have to go to the .libs subdirectory. Not yet sure how to go about a better solution. Cheers, Ralf ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: cannot install...to a directory not ending in
Hi Ralf and Ed, Ed's description of the problem is what I am experiencing. We use VECT (aka CMU's EMT Rewritten and made Lite) for release management of apps. Written by yours truly :) http://vect.sourceforge.net/ Anyway, it's the same problematic idea as Stow's. I will try --with-libdir, however I'm immediately concerned that it's going to cause an additional problem: We don't want anything we build for /dest to have any references to /dest/stow/package-package version (to use Ed's example). We often gather up /dest in a tarball to drop onto non-networked machines, for example. They exist :) I bet building gcc (for example) with --with-libdir= is going to cause that. Ralf - sorry I came across so frustrated. I just hate when tools stop me from doing what I know is correct. That is, yes, once the app is released, the libraries *will* live where libtool wants them. Just let me install them elsewhere and handle it. As for an appropriate solution (assuming --with-libdir doesn't turn out to be a royal pain to get going), I'd be happy with any environmental flag that would turn those 'fatal errors' into warnings. Edward Maros wrote: I believe the problem being described here is one that I have encountered also since I use stow for package management. A long time ago, it use to be the case you could say: ./configure --prefix=/dest make make prefix=/dest/stow/package-package version install even if the package installed shared objects. With more recent versions of libtool, I have had to add the --with-libdir=/dest/stow/package-package version/lib to allow proper installation. Ed Ralf Wildenhues wrote: Hello Jeff, * Jeff Blaine wrote on Fri, Sep 22, 2006 at 04:17:07PM CEST: Okay, I've run into this enough that it's taken its toll on me and I must know the proper modern way to handle this. Hmm. This sounds like it used to work before and we broke something. Is it what you are implying? For years and years, the following worked fine for any GNU app using autoconf: ./configure --prefix=/my/final/destination make make install prefix=/my/to-be-released/destination Not with Libtool-using packages, at least not bug-free, as far as I remember. make install DESTDIR=/my/staging/directory works to install your stuff temporarily into /my/staging/directory/my/final/destination from where it can be moved to /my/final/destination and, after a libtool --mode=finish /my/final/destination/lib libraries should be useable. There are issues in current libtool that prevent this from working properly in _some_ cases when you try to link against third-party libraries that currently are visible below /my/staging/directory/my/final/destination but are to finally appear at /my/final/destination/ See some other discussion on this list just this week. It has often not worked when involving libtool over the last year or two and it's driving me nuts. Can someone PUHLZE tell me the right way to do this? Well, I'm really sorry you've had so much trouble, and I can only ask to report issues earlier. If you think there is a regression involved then please point me to a package where this should have worked. Hope that helps. Cheers, Ralf ___ http://lists.gnu.org/mailman/listinfo/libtool ___ http://lists.gnu.org/mailman/listinfo/libtool
RE: message to the bug-libtool list
Title: RE: message to the bug-libtool list See in line -Original Message- From: Ralf Wildenhues [mailto:[EMAIL PROTECTED]] Sent: Friday, September 22, 2006 9:34 AM To: Jitesh Jhatakia Cc: bug-libtool@gnu.org Subject: Re: message to the bug-libtool list [ bug-libtool readers: the original bug report was filtered ] abc Hello Jitesh, * Jitesh Jhatakia wrote on Fri, Sep 22, 2006 at 05:16:12PM CEST: Tagdemo-make.test failed 2 times once for tagdemo-conf.test and 2nd time for tagdemo-shared.test. Thanks for the bug report. Could you please post the output of ./libtool --config Please find attachment abc.txt and the output of env VERBOSE=x TESTS=tagdemo-conf.test tagdemo-make.test \ tagdemo-exec.test tagdemo-shared.test tagdemo-make.test \ tagdemo-exec.test make -e check ? Thank you. Make: *** No rule to make target 'check'. Stop. Cheers, Ralf abc Description: abc ___ Bug-libtool mailing list Bug-libtool@gnu.org http://lists.gnu.org/mailman/listinfo/bug-libtool
Re: cannot install...to a directory not ending in
* Jeff Blaine wrote on Fri, Sep 22, 2006 at 06:30:42PM CEST: I will try --with-libdir, however I'm immediately concerned that it's going to cause an additional problem: We don't want anything we build for /dest to have any references to /dest/stow/package-package version (to use Ed's example). Yes, in that case you probably may not do that. Note that unlike --libdir, --with-libdir is not standardized in any way, so I don't know what effect it would have on packages; in any case run paths to /dest/... are wrong. I ask you guys to please dig out an old package that uses (a probably older version of) libtool and that does not have this issue, and if you find one, point me to it. Only looking at it will allow me to decide whether there is a Libtool regression involved or not. Thank you. Other than that, please read this thread: http://lists.gnu.org/archive/html/libtool/2006-09/msg00062.html I've said most of what I think is to say on this topic there as of now. And I'm (slowly) working on improvement. Note that any usage case that is even the slightliest different than those I already know of, is important to look at, so if you think you have a setup I haven't covered there, by all means explain it to me (in detail), please. Ralf - sorry I came across so frustrated. I just hate when tools stop me from doing what I know is correct. That is, yes, once the app is released, the libraries *will* live where libtool wants them. Just let me install them elsewhere and handle it. Using the DESTDIR approach I showed should get you going. If not then please come back and complain. Don't use the --with-libdir thingy if references to /dest/... are disallowed in the final installed files. And please note all the limitations I wrote about in the other thread. Unless I get more precise data I can only assume that older libtool versions just happened to work for some special cases; I don't think they worked for the general case where `prefix' was set differently at `make install' time. Cheers, Ralf ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: cannot install...to a directory not ending in
I tried DESTDIR. It doesn't do what I want. If I specify % ./configure --prefix=/usr/local % make % make install DESTDIR=/blah/blah ...then the install process builds out /blah/blah/usr/local. We can't use that. Let me explain better what it is I am doing. The players that are relevant to this particular issue: 1. /afs/blah/dest/sun4x_59/local/bison/1875 The installed destination for a bison build. We build everything as follows, and always have: ./configure --prefix=/usr/local make make install prefix=/afs/blah/dest/sun4x_59/local/bison/1875 After that build, /afs/blah/dest/sun4x_59/local/bison/1875 looks like: % ls bin/info/ lib/man/share/ % Disregard that I am using bison as an example. It's only an example. 2. /afs/blah/gamma/sun4x_59/local Our software repository for Solaris 9. It looks like any other common /usr/local tree. It has bin, lib, man, libexec, etc, and others. These directories are populated with whatever apps have been built and released so far. What you also need to know is that there is a step used to populate this area. That step gathers ALL of the item 1 above areas and folds them into a single /usr/local like item (/afs/blah/gamma/sun4x_59/local). 3. /usr/local A simple user interface to our software repository. It is a symlink to /afs/blah/gamma/sun4x_59/local I'm not in any way suggesting that you have changed something in libtool recently that has broken this. We have had trouble with it for a long long time. I think the use of libtool by apps is just starting to reach a final critical point for us and I'm forced to figure this out finally. I couldn't begin to tell you how I've fixed it before. If I had to guess, I bet I spent a half hour doing various things by hand. For now, I will have to use --with-libdir and give that a shot even though it is not workable for us in the medium-to-long run. I'll have to rebuild a bunch of things down the road if libtool is changed to work with the situation above, but I have no choice right now. I have apps that need to be built and released... last week. I don't see anything in the previous thread that addresses this. I don't mind being forced to run libtool with special options nowadays, if I have to, in order to get everything straightened out and happy. As it is, libtool *stops* me in my tracks by refusing to proceed because it doesn't like what I told it to do (make install prefix=/some/new/place). Please let me know if you need more information. Ralf Wildenhues wrote: * Jeff Blaine wrote on Fri, Sep 22, 2006 at 06:30:42PM CEST: I will try --with-libdir, however I'm immediately concerned that it's going to cause an additional problem: We don't want anything we build for /dest to have any references to /dest/stow/package-package version (to use Ed's example). Yes, in that case you probably may not do that. Note that unlike --libdir, --with-libdir is not standardized in any way, so I don't know what effect it would have on packages; in any case run paths to /dest/... are wrong. I ask you guys to please dig out an old package that uses (a probably older version of) libtool and that does not have this issue, and if you find one, point me to it. Only looking at it will allow me to decide whether there is a Libtool regression involved or not. Thank you. Other than that, please read this thread: http://lists.gnu.org/archive/html/libtool/2006-09/msg00062.html I've said most of what I think is to say on this topic there as of now. And I'm (slowly) working on improvement. Note that any usage case that is even the slightliest different than those I already know of, is important to look at, so if you think you have a setup I haven't covered there, by all means explain it to me (in detail), please. Ralf - sorry I came across so frustrated. I just hate when tools stop me from doing what I know is correct. That is, yes, once the app is released, the libraries *will* live where libtool wants them. Just let me install them elsewhere and handle it. Using the DESTDIR approach I showed should get you going. If not then please come back and complain. Don't use the --with-libdir thingy if references to /dest/... are disallowed in the final installed files. And please note all the limitations I wrote about in the other thread. Unless I get more precise data I can only assume that older libtool versions just happened to work for some special cases; I don't think they worked for the general case where `prefix' was set differently at `make install' time. Cheers, Ralf ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: cannot install...to a directory not ending in
On Fri, Sep 22, 2006 at 05:26:07PM -0400, Jeff Blaine wrote: I tried DESTDIR. It doesn't do what I want. If I specify % ./configure --prefix=/usr/local % make % make install DESTDIR=/blah/blah ...then the install process builds out /blah/blah/usr/local. We can't use that. Let me explain better what it is I am doing. The players that are relevant to this particular issue: 1. /afs/blah/dest/sun4x_59/local/bison/1875 The installed destination for a bison build. We build everything as follows, and always have: ./configure --prefix=/usr/local make make install prefix=/afs/blah/dest/sun4x_59/local/bison/1875 After that build, /afs/blah/dest/sun4x_59/local/bison/1875 looks like: % ls bin/info/ lib/man/share/ % Disregard that I am using bison as an example. It's only an example. Then how about: % ./configure --prefix=/ % make % make install DESTDIR=/blah/blah -- albert chin ([EMAIL PROTECTED]) ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: cannot install...to a directory not ending in
On Fri, Sep 22, 2006 at 04:52:27PM -0500, Albert Chin wrote: On Fri, Sep 22, 2006 at 05:26:07PM -0400, Jeff Blaine wrote: I tried DESTDIR. It doesn't do what I want. If I specify % ./configure --prefix=/usr/local % make % make install DESTDIR=/blah/blah ...then the install process builds out /blah/blah/usr/local. We can't use that. Let me explain better what it is I am doing. The players that are relevant to this particular issue: 1. /afs/blah/dest/sun4x_59/local/bison/1875 The installed destination for a bison build. We build everything as follows, and always have: ./configure --prefix=/usr/local make make install prefix=/afs/blah/dest/sun4x_59/local/bison/1875 After that build, /afs/blah/dest/sun4x_59/local/bison/1875 looks like: % ls bin/info/ lib/man/share/ % Disregard that I am using bison as an example. It's only an example. Then how about: % ./configure --prefix=/ % make % make install DESTDIR=/blah/blah Sorry, disregard this foolish suggestion. -- albert chin ([EMAIL PROTECTED]) ___ http://lists.gnu.org/mailman/listinfo/libtool
