Re: [boost] wgcc 2.0 RC1 released
David Abrahams wrote: > "Duft Markus" <[EMAIL PROTECTED]> writes: > >> When building with wgcc there are a few benefits: >> >> Wgcc uses the native windows compiler to build (so the code may or may >> not be faster ;o)) and whats a lot more important: the debug >> information produced is readable by visual studio, so you can debug >> the output. Gdb on windows (at least on interix) is so terribly >> broken, i could not debug 10 lines of code without gdb failing at some >> point. > > Works great for me under Cygwin, especially through emacs. Code may not be faster. It really depends on the implementation of the compiler. The differences would be negligible from my understanding, though with more resources MS may be able to optimise some things in their compiler... I don't know. I do prefer the MS debugger, but my experience with GDB is that it also works fine in windows (Under Cygwin and with MSYS/MinGW) and achieves its purpose well enough (I guess not using emacs is part of my problem :-) as it seems a little more clunky to use having to type in all these breakpoints... I need a GUI frontend for GDB i think...) >> The second thing is, that resulting executables depend on msvcrt.lib >> and are therefore binary compatible with nearly everything ;o) on >> windows. > > That's also true of MinGW, right? Yes. MinGW depends on msvcrt.lib >> When using gcc it has it's own libc (on interix gcc is a >> interix build, and has really not much to do with windows ;o//) >> and one can't link those things together, so in gcc built binaries one >> can _not_ use the win32 API which, on windows, is not really desireable. > > Huh? Not so; I have used the win32 API even through cygwin GCC. > And then there's gcc -mno-cygwin. Yep. There is a win32api library for cygwin. Same as MinGW really with -mno-cygwin i think... >> The last thing is, that tools such as Rational Purify may be used to >> examine the resulting binaries. It's all just really native ;o) >> >> I'm really overwhelmed that someone outside my company finally shows >> at least _some_ interest. It's really cool, give it a try! > > Not sure what I'm missing here, but at this point I don't see why I > should bother. The existing tools work for me and are > well-established, with good support. > One possible reason I can think of is that in the non-free world... Sometimes a company might distribute a C++ library + some header files (Without any source code). I have encountered this before. Since the ABI is not the same between MSVC and MinGW/GCC it forces you to use the compiler they have created the libraries using (Unless it is a pure C interface) and if you have a desire to use the autotools build framework (autoconf/automake/libtool) then this could be useful. Having a wrapper for MSVC that behaves like gcc would mean that you can use the autotools (A particulary important part of it is libtool for this discussion) build framework with the MSVC compiler. This may be beneficial in some situations instead of using the MSVC build environment. I tried cccl a while ago and shortly discovered a HEAP of issues especially trying to compile things using libtool. So i went and started my own shell script wrapper that improved on cccl. It got a fair way but i was not willing to put more time into it and being a shell script like libtool it slows compiling down a bit on large projects. Plus there is no way to fix the auto import problem with MSVC. So i gave up on that line of thought. From my understanding, wgcc is a compiled wrapper similar to cccl but it has had a lot more features put into it so it better "emulates" gcc. This has got advantages though is not suitable in a lot of situations. Instead of using a wrapper for the compiler/linker i have just started using a different build toolset from automake/libtool. Jam and Scons are two good examples that can use either compiler without having to force the usage of MSVC to behave like gcc. Anyhows, Thats just my two cents worth on the subject... Brendon. ___ http://lists.gnu.org/mailman/listinfo/libtool
RE: [boost] wgcc 2.0 RC1 released
All i can talk of is my experience using interix, since i didn't use cygwin that much. Cygwin was more or less dead at out company when i came in. The yhad too much problems with the cygwin builds. Some of the problems are, that the w32api for cygwin and mingw is not the *real* w32api, but some own thing they built. I really don't know how this w32api behaves, or if it has any drawbacks. As for gdb, the version that comes with interix 3.5 is from i-don't-know-when (seems like year 2k or something), so many years old. Maybe newer versions would work better. Debugging C code is not a problem, everything works fine there, but never try to debug C++, you'll get 10 lines far or so (until first using a STL string.) ;o) As of the import/export problems with MS, wgcc really does a lot in this direction, one can say most of it's code is just for those problems. And i think it manages to push things in the right direction. One has to _only_ put __declspec(dllimport) in place where needed, and that _only_ for Data symbols. There is no need to differenciate static and shared libraries, just put the import everywhere ;o) wgcc manages the rest. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Brendon Costa Sent: Wednesday, September 20, 2006 10:43 AM To: David Abrahams Cc: boost@lists.boost.org; libtool@gnu.org Subject: Re: [boost] wgcc 2.0 RC1 released David Abrahams wrote: > "Duft Markus" <[EMAIL PROTECTED]> writes: > >> When building with wgcc there are a few benefits: >> >> Wgcc uses the native windows compiler to build (so the code may or >> may not be faster ;o)) and whats a lot more important: the debug >> information produced is readable by visual studio, so you can debug >> the output. Gdb on windows (at least on interix) is so terribly >> broken, i could not debug 10 lines of code without gdb failing at >> some point. > > Works great for me under Cygwin, especially through emacs. Code may not be faster. It really depends on the implementation of the compiler. The differences would be negligible from my understanding, though with more resources MS may be able to optimise some things in their compiler... I don't know. I do prefer the MS debugger, but my experience with GDB is that it also works fine in windows (Under Cygwin and with MSYS/MinGW) and achieves its purpose well enough (I guess not using emacs is part of my problem :-) as it seems a little more clunky to use having to type in all these breakpoints... I need a GUI frontend for GDB i think...) >> The second thing is, that resulting executables depend on msvcrt.lib >> and are therefore binary compatible with nearly everything ;o) on >> windows. > > That's also true of MinGW, right? Yes. MinGW depends on msvcrt.lib >> When using gcc it has it's own libc (on interix gcc is a interix >> build, and has really not much to do with windows ;o//) and one >> can't link those things together, so in gcc built binaries one can >> _not_ use the win32 API which, on windows, is not really desireable. > > Huh? Not so; I have used the win32 API even through cygwin GCC. > And then there's gcc -mno-cygwin. Yep. There is a win32api library for cygwin. Same as MinGW really with -mno-cygwin i think... >> The last thing is, that tools such as Rational Purify may be used to >> examine the resulting binaries. It's all just really native ;o) >> >> I'm really overwhelmed that someone outside my company finally shows >> at least _some_ interest. It's really cool, give it a try! > > Not sure what I'm missing here, but at this point I don't see why I > should bother. The existing tools work for me and are > well-established, with good support. > One possible reason I can think of is that in the non-free world... Sometimes a company might distribute a C++ library + some header files (Without any source code). I have encountered this before. Since the ABI is not the same between MSVC and MinGW/GCC it forces you to use the compiler they have created the libraries using (Unless it is a pure C interface) and if you have a desire to use the autotools build framework (autoconf/automake/libtool) then this could be useful. Having a wrapper for MSVC that behaves like gcc would mean that you can use the autotools (A particulary important part of it is libtool for this discussion) build framework with the MSVC compiler. This may be beneficial in some situations instead of using the MSVC build environment. I tried cccl a while ago and shortly discovered a HEAP of issues especially trying to compile things using libtool. So i went and started my own shell script wrapper that improved on cccl. It got a fair way but i was not willing to put more time into it and being a shell script like libtool it slows compiling down a bit on large projects. Plus there is no way to fix the auto import problem with MSVC. So i gave up on that line of thought. From my understanding, wgcc is a compiled wrapper similar to cccl but it
Re: deploying libraries and executables from a staging area
This makes things /much/ clearer.
Thanks,
Noel
On 9/19/06, Ralf Wildenhues <[EMAIL PROTECTED]> wrote:
Hello Noel, Albert,
* Albert Chin wrote on Wed, Sep 20, 2006 at 05:36:45AM CEST:
> On Tue, Sep 19, 2006 at 05:18:08PM -0700, Noel Yap wrote:
> > On 9/19/06, Albert Chin <[EMAIL PROTECTED]> wrote:
> > >On Tue, Sep 19, 2006 at 03:32:58PM -0700, Noel Yap wrote:
> > >>
> > >>./libtool --mode=install install ${la} ${destination}/lib/${l}
> > >>./libtool --mode=finish ${destination}/lib/${l}
> > >>
> > >>./libtool --mode=install install ${exe}
${destination}/bin/${x}
> > >>./libtool --mode=finish ${destination}/bin/${x}
There are several bugs in the above commands, and there are also
undocumented limitations in libtool about DESTDIR installations
(some of which I've been working on a bit lately).
First, the target you specify should be a file name (the same as the
source), i.e., ${l} should be the basename of ${la}, and ${x} should be
the basename of ${exe}. (You may have this, but it's not clear.)
Then, --mode=finish operates on library directories only, so it doesn't
need to be done for ${x} at all, and for the library directory, you
should not specify the library name. But here's another catch: finish
mode can only be done once the libraries appear at their final location
(i.e., when they appear below $libdir, not $DESTDIR$libdir).
The next limitation is the one Albert mentioned: it only works if
the destination (let's call it $DESTDIR) is a prefix to the configured
library directory ($libdir); and since $libdir must be an absolute path
anyway, it's common and good style to not separate the two by a slash:
./libtool --mode=install install ${la} ${DESTDIR}${libdir}/${l}
./libtool --mode=install install ${exe} ${DESTDIR}${bindir}/${x}
[ move things to the right location... ]
./libtool --mode=finish ${libdir}
But wait, there's more: currently, things only work out well if the
programs and libraries you install do _not_ depend upon any previously
installed libraries that currently live below ${DESTDIR}. In some
special cases this may work or may be made to work, but in general it
will cause interesting failures.
I'm currently working on lifting the last restriction; this may not be
possible portably (e.g., some settings definitely require the GNU
binutils linker for its -rpath-link support), but at least it should be
possible to get more cases working than we have now. And we should
document exactly when it will work and when it won't. More details
about this on the libtool-patches list as soon as I have them worked
out (but don't hold your breath).
The CVS Libtool file tests/destdir.at more or less demonstrates what is
working at the moment.
Cheers,
Ralf
___
http://lists.gnu.org/mailman/listinfo/libtool
Re: deploying libraries and executables from a staging area
Actually, one more question.
I need to install the binaries into /some/read-only/dir, but need the
rpath to point to /some/read-write/dir. How can this be done?
Thanks,
Noel
On 9/20/06, Noel Yap <[EMAIL PROTECTED]> wrote:
This makes things /much/ clearer.
Thanks,
Noel
On 9/19/06, Ralf Wildenhues <[EMAIL PROTECTED]> wrote:
> Hello Noel, Albert,
>
> * Albert Chin wrote on Wed, Sep 20, 2006 at 05:36:45AM CEST:
> > On Tue, Sep 19, 2006 at 05:18:08PM -0700, Noel Yap wrote:
> > > On 9/19/06, Albert Chin <[EMAIL PROTECTED]> wrote:
> > > >On Tue, Sep 19, 2006 at 03:32:58PM -0700, Noel Yap wrote:
> > > >>
> > > >>./libtool --mode=install install ${la}
${destination}/lib/${l}
> > > >>./libtool --mode=finish ${destination}/lib/${l}
> > > >>
> > > >>./libtool --mode=install install ${exe}
${destination}/bin/${x}
> > > >>./libtool --mode=finish ${destination}/bin/${x}
>
> There are several bugs in the above commands, and there are also
> undocumented limitations in libtool about DESTDIR installations
> (some of which I've been working on a bit lately).
>
> First, the target you specify should be a file name (the same as the
> source), i.e., ${l} should be the basename of ${la}, and ${x} should be
> the basename of ${exe}. (You may have this, but it's not clear.)
>
> Then, --mode=finish operates on library directories only, so it doesn't
> need to be done for ${x} at all, and for the library directory, you
> should not specify the library name. But here's another catch: finish
> mode can only be done once the libraries appear at their final location
> (i.e., when they appear below $libdir, not $DESTDIR$libdir).
>
> The next limitation is the one Albert mentioned: it only works if
> the destination (let's call it $DESTDIR) is a prefix to the configured
> library directory ($libdir); and since $libdir must be an absolute path
> anyway, it's common and good style to not separate the two by a slash:
>
> ./libtool --mode=install install ${la} ${DESTDIR}${libdir}/${l}
> ./libtool --mode=install install ${exe} ${DESTDIR}${bindir}/${x}
>
> [ move things to the right location... ]
>
> ./libtool --mode=finish ${libdir}
>
>
> But wait, there's more: currently, things only work out well if the
> programs and libraries you install do _not_ depend upon any previously
> installed libraries that currently live below ${DESTDIR}. In some
> special cases this may work or may be made to work, but in general it
> will cause interesting failures.
>
> I'm currently working on lifting the last restriction; this may not be
> possible portably (e.g., some settings definitely require the GNU
> binutils linker for its -rpath-link support), but at least it should be
> possible to get more cases working than we have now. And we should
> document exactly when it will work and when it won't. More details
> about this on the libtool-patches list as soon as I have them worked
> out (but don't hold your breath).
>
> The CVS Libtool file tests/destdir.at more or less demonstrates what is
> working at the moment.
>
> Cheers,
> Ralf
>
___
http://lists.gnu.org/mailman/listinfo/libtool
Re: deploying libraries and executables from a staging area
* Noel Yap wrote on Wed, Sep 20, 2006 at 07:22:41PM CEST: > > I need to install the binaries into /some/read-only/dir, but need the > rpath to point to /some/read-write/dir. How can this be done? This isn't enough information to go by. If there are no libraries involved at all, or no libtool libraries that are to be moved elsewhere, then you just use `-R /some/read-write/dir' at link time. To be able to say more (including whether it works portably ATM or not), we need to know - which libraries are involved (uninstalled ones, installed but at a different location in which they will ultimately appear, or installed ones at their final location), - whether those libraries are static, shared, created with libtool or without (i.e., there is a *.la file or not), - and the exact dependencies between them (including whether direct or not); best to show both the `libtool --mode=link' line for each of them and the respective output. - and of course the same for the final binaries, too. Cheers, Ralf ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: HP-UX "module" linking problem
Hello Albert, Kent, * Albert Chin wrote on Tue, Sep 19, 2006 at 04:58:59PM CEST: > On Tue, Sep 19, 2006 at 10:11:36AM +0200, Kent Boortz wrote: > > Albert Chin <[EMAIL PROTECTED]> writes: > > > > > So, in both cases, libz is not on the command-line used to create the > > > shared library. > > > > Yes, what I meant was that I took the "cc" line libtool expand to, > > inserted "-lmysqlclient" and tried link it manually. and it worked. > > Making me beleive it is a libtool problem. > > Well, I suppose you could argue libtool should exit(1) rather than > stripping libraries from the command-line in this case. I think it shouldn't. Libtool is acting as it states and putting the dependency in $dependency_libs in the .la file. If we allow installing PIC archives (== installing convenience archives) then we can just wait for the day that someone comes and complains that this broke their program because he used a symbol from some completely unrelated library. (Imagine third-party shared libfoo containing code from your libmysqlclient that's both three years old, outdated, security bug ridden, and noone notices, but fourth-party program bar happened to link against that one before linking against a shared libmysqlclient.) > > Looking inside the "libtool" command and Googling a bit more, I found > > an ugly way around this. After generating the "configure" script, I > > change it to say > > > > hpux10.20* | hpux11*) > > lt_cv_deplibs_check_method=pass_all > > > > This makes it let "-lmysqlclient" pass on, I found no way to force > > this using any command line flag. > > Correct. Some systems like AIX and Tru64 UNIX generate PIC for all > object files. Maybe this is a plan to kill pass_all on some more systems: allow a link flag that enables lt_cv_deplibs_check_method=test_compile, after spitting out some long warning. Then at least we can be a little more sure that we don't create fully broken libraries; and Kent's case would work (as its archive contains PIC code). Not sure though. Cheers, Ralf ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: deploying libraries and executables from a staging area
On 9/20/06, Ralf Wildenhues <[EMAIL PROTECTED]> wrote: * Noel Yap wrote on Wed, Sep 20, 2006 at 07:22:41PM CEST: > > I need to install the binaries into /some/read-only/dir, but need the > rpath to point to /some/read-write/dir. How can this be done? This isn't enough information to go by. If there are no libraries involved at all, or no libtool libraries that are to be moved elsewhere, then you just use `-R /some/read-write/dir' at link time. I made a mistake in my problem statement. The binaries (both libraries and executables) need to be installed into /some/read-write/dir and the rpaths need to point to /some/read-only/dir. To be able to say more (including whether it works portably ATM or not), we need to know - which libraries are involved (uninstalled ones, installed but at a different location in which they will ultimately appear, or installed ones at their final location), - whether those libraries are static, shared, created with libtool or without (i.e., there is a *.la file or not), - and the exact dependencies between them (including whether direct or not); best to show both the `libtool --mode=link' line for each of them and the respective output. - and of course the same for the final binaries, too. In the end, both /some/read-only/dir and /some/read-write/dir will be pretty much the same physical directory, but /some/read-only/dir will be read only. In this scenario, I'm no longer sure what it means for a binary (both libraries and executables) to be 'installed' or not. Both static and dynamic libraries will be deployed and dynamic linking for executables is preferred but not required. I don't currently have an exact 'libtool --mode=link' command since that's what I'm trying to figure out, but it should look something like: /bin/sh ../libtool --mode=link gcc -g -O2 -Bstatic -o libclamav.la -rpath /some/read-only/dir -thread -safe -version-info 1:17:0 -no-undefined matcher-ac.lo matcher-bm.lo matcher.lo md5.lo others.lo readdb.lo cvd.lo dsig.lo str.lo scanners.lo filetypes.lo unrarlib.lo zzip-dir.lo zzip-err.lo zzip-file.lo zzip-info.lo zzip-io.lo zzip-stat.lo zzip-zip.lo strc.lo blob.lo mbox.lo message.lo snprintf.lo strrcpy.lo table.lo text.lo ole2_extract.lo vba_extract.lo msexpand.lo pe.lo cabd.lo lzxd.lo mszipd.lo qtmd.lo system.lo upx.lo htmlnorm.lo chmunpack.lo rebuildpe.lo petite.lo fsg.lo line.lo untar.lo special.lo binhex.lo is_tar.lo tnef.lo uuencode.lo -L/path/to/libs -lz -lbz2 -lpthread -lnsl /bin/sh ../libtool --mode=link gcc -g -O2 -o clamscan output.o getopt.o memory.o cfgparser.o misc.o clamscan.o options.o others.o manager.o treewalk.o ../libclamav/libclamav.la Thanks, Noel ___ http://lists.gnu.org/mailman/listinfo/libtool
RE: AW: boost ?!
The initial reason for writing wgcc was, that we have tons and tons of unix software in-house, and need to port them to windows. We have our own build and distribution mechanism, and use much of autotools and libtool as well. To not break everything, i wrote wgcc, so that we are able to (under interix) use our mechanisms and the autotools on windows as well (even without the need to change makefiles much). Some simple changes are allways required ;o) thats because of the really different concepts between compilers. Of course i'd like wgcc to understand as m uch as possible! I'd love to see stdcxx built with wgcc by the way. But at the moment i have not really enough time to look into it. Don't know how much changes this would need. Cheers, Markus -Original Message- From: Martin Sebor [mailto:[EMAIL PROTECTED] Sent: Wednesday, September 20, 2006 11:02 PM To: stdcxx-dev@incubator.apache.org Subject: Re: AW: boost ?! Duft Markus wrote: > OMG, i'm so blind.. I messed up 12d and 15d, maybe those should get other > names ;o) now it's all clear why it can't work Yes, container iterators have different types between debug and optimized builds, with std::string and std::vector being plain pointers for efficiency. This makes the two kinds of builds incompatible with one another. > > Anyway thanks for your time, and sorry for messing around in here! No problem. Glad you got it worked out. Martin PS I haven't played with wgcc too much yet but I like the concept. In fact, I've been thinking about writing a similar tool for some time, one that would provide a uniform interface to all compilers (i.e., the same set of compiler options across all). Have you considered enhancing wgcc in this way? > > Cheers, Markus > > -Ursprüngliche Nachricht- > Von: Duft Markus [mailto:[EMAIL PROTECTED] > Gesendet: Dienstag, 19. September 2006 09:37 > An: stdcxx-dev@incubator.apache.org > Betreff: AW: boost ?! > > Hm, the struct thing was completely wrong, sorry > > Ok, i just digged a little into this: > > For example one of the unresolved symbols is: > > [EMAIL PROTECTED]@[EMAIL PROTECTED]@std@@[EMAIL PROTECTED]@2@@s > td@@QAEPADXZ > > Which would be: > > __declspec(dllimport) public: char * __thiscall > std::basic_string,class > std::allocator >::begin(void) > > The Stdcxx library has symbols some symbols which are close: > > [EMAIL PROTECTED]@[EMAIL PROTECTED]@std@@[EMAIL PROTECTED]@2@@s > td@@[EMAIL PROTECTED]@[EMAIL PROTECTED]@std@@V?$ > [EMAIL PROTECTED]@2@@std@@[EMAIL PROTECTED]@@XZ > > Which would be: > > __imp_public: class __rw::__rw_debug_iter std::basic_string,class > std::allocator >,char *,char *> __thiscall > std::basic_string,class > std::allocator >::begin(void) > > I now think that somehow there is a problem with the headers thinking they > need to compile debug iterators (in build 15d!?) and when using the lib, they > think something else ;o// i looked at my config.h but there was nothing i > could see in there. I attached it, maybe you can see something. > > Cheers, Markus > > -Ursprüngliche Nachricht- > Von: Martin Sebor [mailto:[EMAIL PROTECTED] > Gesendet: Montag, 18. September 2006 17:34 > An: stdcxx-dev@incubator.apache.org > Betreff: Re: boost ?! > > Duft Markus wrote: > >>Hey again! >> >>I'm currently fighting to get boost compiled with stdcxx... ;o) It >>seems, that boost uses both char and wchar_t versions of methods from >>stdcxx, which at least seems to compile, but cannot link, since there >>is no wchar_t impl in the stdlib15d.lib/.dll. Now my question is: can >>i somehow use 15d and 15D together on windows, so that both kind of >>symbols are present? > > > The difference between 15d and 15D is that the first is a 32-bit build type > (ILP32) while the second is a 64-bit or wide one (LLP64 on Windows). The > "wide" has nothing to do with wchar_t, it refers to the width of the data > type(s). > > Stdcxx has full support for wchar_t as long as the compiler supports it. Keep > in mind that the MSVC /Zc:wchar_t option changes the type and mangling of > wchar_t and thus is a binary incompatible option. > Programs that link with the library must be compiled with same setting of the > option as the library (i.e., both on or both off). > > See http://msdn2.microsoft.com/en-us/library/dh8che7s.aspx > > >>And there seem to be some differences from windows STL to this one in >>which files get included automatically from other includes and so on, >>since i need to explicitly include some files for some things to work >>(like std::hex and std::dec are not found, except i include istream or >>so) > > > Stdcxx is much less promiscuous (i.e., a lot cleaner) than other > implementations of the C++ standard library when it comes to its headers > introducing unnecessary names into scope. std::hex and other manipulators are > required to be declared in the header and nowhere else so in order to > use them you m
