More info on boost and gcc-4

More info on boost and gcc-4

[Eray Ozkural]

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,

-- 
Eray Ozkural, PhD candidate.  Comp. Sci. Dept., Bilkent University, Ankara
Researcher, Erendiz Superbilgisayar Ltd.
http://groups.yahoo.com/group/ai-philosophy
http://myspace.com/arizanesil http://myspace.com/malfunct

--
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

Re: More info on boost and gcc-4

[Václav Haisman]

-----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