MIME-Version: 1.0
Date: Thu, 25 Jun 2009 01:08:37 +0300
Message-ID: <320e992a0906241508i692c2935ue0c22b7de3ddeca1@mail.gmail.com>
Subject: More info on boost and gcc-4
From: Eray Ozkural <examachine AT gmail DOT com>
To: cygwin AT cygwin DOT com
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
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

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