Mail Archives: cygwin/2009/06/24/18:09:02
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
- Raw text -