Re: HP-UX "module" linking problem
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. 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. > On HP-UX, lib*.a libraries are always static archives, regardless of > how the members were compiled. If you want to link in > libmysqlclient_r, I think your only solution is to build it as part of > whatever program you're building but create it as a convenience > library. Thanks, I will look into that option, kent -- Kent Boortz, Senior Software Developer MySQL AB, www.mysql.com Office: +46 18 174400 ext. 4450 (VoIP) Office: +46 19 182931 Mobile: +46 70 2791171 ___ http://lists.gnu.org/mailman/listinfo/libtool
wgcc 2.0 RC1 released
Hi again! For all interested in native Windows binaries built with Autotools and mnay other interesting things: 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 1 of wgcc has a completely rewritten Configuration File parser, which allows for faster and safer parsing; now adding the ability to include empty directives in configuration files. This could be something like "paths.c++ =" to unset all C++ search directories. Also the ability to automatically generate export definitions and import trampolines for mixing static and shared libraries with executables has been reviewed and improved. This did not change the behaviour of wgcc regarding the 2.0-pre.x versions, but only speeded it up a little. pxwc, the accompanying library for wgcc allows further abstraction for C code, allowing use of the ANSI function names (i.e. without the leading "_"). 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=158081&atid=806407 and we will try to add functionality as soon as possible. Using the patch provided for GNU Libtool, wgcc can be used with many Open Source packages. After patching and installing Libtool, simply bootstrap the package in question, configure (set CC, CXX and LD to "wgcc") and build. The configure Script should tell that the linker in use is the "Interix to Win32 cross linker (wgcc)". Since the version jump to 2.x wgcc now resides in the Sourceforge Subversion Repository. The CVS Repository still continues to contain previous wgcc versions (0.x). To continue improving wgcc and pxwc packages, we now need your help in testing them. Please download wgcc and try to compile you 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=158081&atid=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=158081&package_id=203917&release_id=446943Source Packages can be found here: http://sourceforge.net/project/showfiles.php?group_id=158081&package_id=177049&release_id=445894The Patch for Libtool can be found here: http://sourceforge.net/project/showfiles.php?group_id=158081&package_id=196163&release_id=446510 ___ http://lists.gnu.org/mailman/listinfo/libtool
AW: [boost] wgcc 2.0 RC1 released
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. The visual studio debugger (the 2005 version especially) is very very much better. (gdb on cygwin doesn't behave too good either. This was the initial reason for wgcc to be written (we are a 300 programmer company ;o), we need to debug...)) With cygwin the thing is, that cygwin isn't really quite stable on win xp and above when using more than one CPU. I don't know how MinGW behaves there. The second thing is, that resulting executables depend on msvcrt.lib and are therefore binary compatible with nearly everything ;o) on windows. 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. 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) At the moment as i wrote in my release note only Interix is supported, since this is also stable on win xp and above with multiple processors. But using cygwin as a build environment only, using wgcc as compiler is possible too, i'd just need to implement one method, about 5 lines of code, to convert paths from unix <-> windows style. I hope this is an answer to your questions! I'm really overwhelmed that someone outside my company finally shows at least _some_ interest. It's really cool, give it a try! Cheers, Markus -Ursprüngliche Nachricht- Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Im Auftrag von David Abrahams Gesendet: Dienstag, 19. September 2006 16:07 An: boost@lists.boost.org Cc: libtool@gnu.org Betreff: Re: [boost] wgcc 2.0 RC1 released "Duft Markus" <[EMAIL PROTECTED]> writes: > Hi again! > > For all interested in native Windows binaries built with Autotools and > mnay other interesting things: I'm not sure whether this is on-topic for Boost; it seems of somewhat borderline relevance. However, now that you've started the thread, one obvious question leaps to mind: why would anyone want to use wgcc in lieu of Cygwin or MinGW gcc? -- Dave Abrahams Boost Consulting www.boost-consulting.com ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost ___ http://lists.gnu.org/mailman/listinfo/libtool
[Bug-kawa] 少し遊びましょう
j«ÌFlÌ×ÉAtêåTCgÅ·I ®S³¿o^§ÅïõÍÆEgbvNXI K¸o èÜ·B j«ÌFlÉͨàÌSͲ´¢Ü¹ñB TCgÅÍAèØètðÛðó]·é«ÌÝðÐîµÄ¨èÜ·B http://www.free-premium.com/sereb/Ps007/ j«ÌFlÍ«ÌFl©çT|[gª èÜ·B ÅáÀÌ}i[ðçÁ½ãÅfGÈÔðǤ¼¨ß²µº³¢B http://www.free-premium.com/sereb/Ps007/ â⩵A«YÚĮqlÍr³¹Ä¸¢Ä¨èÜ·B 632811977332349736 ___ Bug-kawa mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/bug-kawa
Re: HP-UX "module" linking problem
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. > 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. -- albert chin ([EMAIL PROTECTED]) ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: wgcc 2.0 RC1 released
On Tue, Sep 19, 2006 at 11:05:25AM +0200, Duft Markus wrote: > > For all interested in native Windows binaries built with Autotools > and mnay other interesting things: > > 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. So, with this tool, someone doesn't need the cccl Visual C++ wrapper: http://cccl.sourceforge.net/ -- albert chin ([EMAIL PROTECTED]) ___ http://lists.gnu.org/mailman/listinfo/libtool
AW: wgcc 2.0 RC1 released
Hm, really i started out porting from unix to windows using cccl, but it took not too long to realize that cccl is far to less powerfull. Cccl is capable of translating some command line options, not really much more. This doesn't mean cccl is bad. If one doesn't need more than this, its perfect. Wgcc is just _more_ and more powerfull. Cccl has, i don't know, say 200 lines of shell script code? Wgcc has about 10.000 lines of c++ code (9305). It does a little more than just wrapping around the command line. It has many benefits over comparable wrappers like cccl, c89 (interix) and wcc (interix, see interopsystems.com) which are all shell scripts just wrapping some arguments. You may want to take a look at the docs for rc.1. there is a section about building libraries with wgcc which may be of interest regarding this question... Cheers, Markus -Ursprüngliche Nachricht- Von: Albert Chin [mailto:[EMAIL PROTECTED] Gesendet: Dienstag, 19. September 2006 17:03 An: Duft Markus Cc: libtool@gnu.org Betreff: Re: wgcc 2.0 RC1 released On Tue, Sep 19, 2006 at 11:05:25AM +0200, Duft Markus wrote: > > For all interested in native Windows binaries built with Autotools and > mnay other interesting things: > > 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. So, with this tool, someone doesn't need the cccl Visual C++ wrapper: http://cccl.sourceforge.net/ -- albert chin ([EMAIL PROTECTED]) ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: wgcc 2.0 RC1 released
"Duft Markus" <[EMAIL PROTECTED]> writes: > Hi again! > > For all interested in native Windows binaries built with Autotools and > mnay other interesting things: I'm not sure whether this is on-topic for Boost; it seems of somewhat borderline relevance. However, now that you've started the thread, one obvious question leaps to mind: why would anyone want to use wgcc in lieu of Cygwin or MinGW gcc? -- Dave Abrahams Boost Consulting www.boost-consulting.com ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: [boost] wgcc 2.0 RC1 released
"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. > The visual studio debugger (the 2005 version especially) is > very very much better. (gdb on cygwin doesn't behave too good > either. What's wrong with it? > With cygwin the thing is, that cygwin isn't really quite stable on win > xp and above when using more than one CPU. Never had a problem there, but haven't stressed Cygwin since I got 2 cores. However, given your claims about Cygwin/gdb I am inclined to wonder about this claim. > 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? > 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. > 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. -- Dave Abrahams Boost Consulting www.boost-consulting.com ___ http://lists.gnu.org/mailman/listinfo/libtool
deploying libraries and executables from a staging area
What are the proper incantations to deploy libraries and executables
from a staging area (such that the rpath correctly points to the
deployment area)?
The following doesn't seem to work:
./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}
Thanks,
Noel
___
http://lists.gnu.org/mailman/listinfo/libtool
Re: deploying libraries and executables from a staging area
On Tue, Sep 19, 2006 at 03:32:58PM -0700, Noel Yap wrote:
> What are the proper incantations to deploy libraries and executables
> from a staging area (such that the rpath correctly points to the
> deployment area)?
>
> The following doesn't seem to work:
>
>./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}
Look at the libtool documentation for -inst-prefix and DESTDIR.
--
albert chin ([EMAIL PROTECTED])
___
http://lists.gnu.org/mailman/listinfo/libtool
Re: deploying libraries and executables from a staging area
On 9/19/06, Albert Chin <[EMAIL PROTECTED]> wrote:
On Tue, Sep 19, 2006 at 03:32:58PM -0700, Noel Yap wrote:
> What are the proper incantations to deploy libraries and executables
> from a staging area (such that the rpath correctly points to the
> deployment area)?
>
> The following doesn't seem to work:
>
>./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}
Look at the libtool documentation for -inst-prefix and DESTDIR.
I read that documentation. It's not that clear to someone new to
libtool and automake especially since the canonical way to release the
product is via configure and make.
Noel
___
http://lists.gnu.org/mailman/listinfo/libtool
Re: deploying libraries and executables from a staging area
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:
> >> What are the proper incantations to deploy libraries and executables
> >> from a staging area (such that the rpath correctly points to the
> >> deployment area)?
> >>
> >> The following doesn't seem to work:
> >>
> >>./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}
> >
> >Look at the libtool documentation for -inst-prefix and DESTDIR.
>
> I read that documentation. It's not that clear to someone new to
> libtool and automake especially since the canonical way to release the
> product is via configure and make.
I think DESTDIR is to be thought of as a virtual root. I don't know if
this mimics what you want. So, if you:
$ ./configure --prefix=/usr/local
and you want it installed to the "/nfs/stage1" staging directory,
you'd:
$ make install DESTDIR=/nfs/stage1
>From my reading of DESTDIR in the libtool manual, this should install
the software in /nfs/stage1/usr/local, with the RPATH configured for
/usr/local.
--
albert chin ([EMAIL PROTECTED])
___
http://lists.gnu.org/mailman/listinfo/libtool
Re: deploying libraries and executables from a staging area
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
