Message-ID: <4A485AC5.4030000@sh.cvut.cz>
Date: Mon, 29 Jun 2009 08:10:13 +0200
From: =?UTF-8?B?VsOhY2xhdiBIYWlzbWFu?= <v DOT haisman AT sh DOT cvut DOT cz>
User-Agent: Thunderbird 2.0.0.22 (Windows/20090605)
MIME-Version: 1.0
To: cygwin AT cygwin DOT com
Subject: Re: More info on boost and gcc-4
References: <320e992a0906241508i692c2935ue0c22b7de3ddeca1 AT mail DOT gmail DOT com>
In-Reply-To: <320e992a0906241508i692c2935ue0c22b7de3ddeca1@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Reply-To: cygwin AT cygwin DOT com
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Eray Ozkural wrote, On 25.6.2009 0:08:
> Hi there,
> 
> Thanks for all the replies.
> 
> I'm not subscribed to the list (not yet) so please CC your replies to
> me. I am going to try to give as much information as I can.
> 
> Here is what's happening. If I use a *vanilla* gcc 4.x that I
> compiled, everything just works fine with boost.
> 
> Here is the version that I'm using successfully at the present. It's
> been some time since I compiled this one:
> $ g++ --version
> g++ (GCC) 4.3.1
> Copyright (C) 2008 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.
> 
> Otherwise, unfortunately, everything collapses, and it is highly
> unlikely that the fault lies with the boost library as the package
> maintainer suggested. Boost is a portable library that's being tested
> on many platforms regularly and I have never seen a major crash like
> this on any other system (linux and mac tested myself).
> 
> It is not just my idea that boost is essential. What do you believe
> the next C++ standard library be?
> 
> How did I build boost? Well, I followed the standard build procedure
> of course. In my first attempts, having been frustrated by my apparent
> inability to make a shared library, I had built a static library. I
> used the following procedure for boost-1.38:
> 
> Uninstall all boost include files /usr/include/boost* and libraries /usr/local/l
> ib/*boost* as well.
> tar -xzf boost-1_38.tar.gz
> cd boost-1_38_0
> ./configure --with-libraries=filesystem,graph,program_options,regex,system
> 
> In the file "Makefile", change the line
> #BJAM_CONFIG= -sICU_PATH=/usr
> to
> #BJAM_CONFIG=-d2 release link=static runtime-link=static cxxflags=-DBOOST_POSIX_
> API=1 optimization=speed
> (Boost apparently does not work with vanilla autotools on cygwin except when
> libraries are static).
> 
> make
> make install
> cd /usr/local/include
> ln -s boost-1_38/boost boost
> 
> Just to make sure we're on the same page, and I'm doing nothing funny.
> The boost-1.39 build proceeds similarly. However, as the package
> maintainer might have noticed, the build procedure changed
> considerably so there is no more a configure or Makefile. You give the
> --with-libraries option to bootstrap.sh and you can also give a
> --disable-icu IIRC. (You can't use ICU with static linking so it must
> be disabled) Then, you must change the gcc configuration so that the
> cygwin gcc-4 is used instead of gcc. (user-config.jam). Jam is a
> terrible tool but unfortunately with the current boost we have to
> stick to it. I don't think it honors environment variables like CXX
> and has some of the worst documentation (and design) I ever saw in a
> system tool :(
> 
> I made the following change in ./tools/build/v2/user-config.jam
> # Configure specific gcc version, giving alternative name to use.
> using gcc : 4.3 : g++-4 ;
> 
> Afterwards you give the bjam options directly like this:
> $ bjam -d2 release link=static runtime-link=static
> cxxflags=-DBOOST_POSIX_API=1 optimization=speed install
> 
> And it blows up. You can see that by running the test suites of
> program_options or regex libs as I suggested or write your little
> program_options test program if you feel like it.
> 
> What I noticed was that, although I didn't build any shared libs, the
> auto-import messages were still being displayed when I used the cygwin
> gcc-4 (when linking against boost for my project). But when I switched
> to the vanilla gcc 4.x that I had built myself, I saw no such messages
> naturally, and everything worked as it should.
> 
> That's why I thought this freeze might be related to the auto-import
> feature (even though I'm using only static libraries) As I said, if
> you give the --enable-auto-import option it only causes a more
> dramatic crash, please read my previous post in which I had requested
> help with boost-1.39 on cygwin-1.7, to which absolutely no replies
> came:
> http://cygwin.com/ml/cygwin/2009-06/msg00799.html
> 
>  The same problems occur exactly on cygwin-1.5. I was at first
> suspicious that I might be doing something wrong, but having seen that
> the vanilla gcc works, it is likely that the patches are causing the
> problem so I thought I should bring this to your attention since the
> importance of boost is only going to increase.
> 
> I did notice that the auto-import feature makes some assumptions about
> the code. Those assumptions may be contradicted by the boost code, but
> of course you cannot expect any library to conform to a cygwin
> standard rather than the ISO standard.
> 
> At any rate, it seems rather strange that linking static libraries fails.
> 
> May I humbly suggest to the package maintainer that he tries the
> myriad test suite programs included in boost-1.39 library against
> gcc-4?
> 
> And then against a vanilla gcc-4?
> 
> I'm sorry that I haven't been able to exactly isolate or fix this bug,
> but at least I can tell you how to reproduce it. I've tried to track
> down boost/cygwin build problems on the net and superficially it would
> seem that they have all been resolved but this does not seem to be the
> case.
> 
> Many thanks in advance,
> 
Dunno about 1.39 but the Boost trunk has gotten a lot more Cygwin friendly
recently. The upcoming Boost 1.40's improved build system fits the Cygwin
model of things nearly out of the box, so packaging it should way easier. In
my experience, you just have to build it with -Wl,--enable-auto-import
(gcc-4) and it just works. (At least the few very basic tests I have done.)

- --
VH
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)

iFYEAREIAAYFAkpIWsUACgkQhQBMvHf/WHllgADeM91pq37/F7jJ+x+CReEBgr2N
BbeYgoevyfmgPgDfeAomxgqJ6JVTAmkm8kiguaT4CgIbL+qNQjhB4g==
=Ge18
-----END PGP SIGNATURE-----

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple