Boost logo

Boost-Build :

From: John Maddock (john_at_[hidden])
Date: 2006-02-02 11:32:07


> $ REGEX_INC=/sps_home/play/install/include/boost-1_33_1
> $ REGEX_LIB=/sps_home/play/install/lib/libboost_regex-gcc-d.a
> $ g++ -I$REGEX_INC -c sp20.cc -o sp20.o
> $ g++ -o sp20 sp20.o $REGEX_LIB -lstdc++

Do you need that -lstdc++ there? Could it be picking up the wrong one?

> Program received signal SIGSEGV, Segmentation fault.
> 0x401cdd37 in __strxfrm_l () at strxfrm.c:99
> 99 strxfrm.c: No such file or directory.
> in strxfrm.c
> gdb) backtrace
> #0 0x401cdd37 in __strxfrm_l () at strxfrm.c:99
> #1 0x40076965 in std::collate<char>::_M_transform (this=0x0,
> __to=0x0, __from=0x0, __n=0) at collate_members.cc:55
> #2 0x400a179a in std::collate<char>::do_transform (this=0x400fd204,
> __lo=0xbffff48a "a", __hi=0xbffff48b "")

That's worrying: stack frame #2 looks OK, there's a valid "this" address and
the arguments look OK, but stack frame #1 has a null pointer for "this", no
wonder it segfaults!

> I have recreated this error on two different linux machines, and under
> two versions of gcc (4.0.2 and 3.4.5).
>
> I have built with and without BOOST_DISABLE_THREADS, and
> -fvisibility=default to no avail. I have also built with the compiler
> set in a non standard location and also later in a standard location
> (/usr/local)
>
> Both linux systems are older, Red Hat 7.2 systems on which I have just
> recently installed gcc 4.0.2. The compiler built and installed
> without problems, but are otherwise untested.
>
> When I try to run regression tests libs/regex/test/regress, I get the
> same segfault behavior.

Darn.

> Based on some googling, it does not appear that this is a known
> problem, and I strongly suspect that the problem relates to my
> particular installation, but cannot figure out what to try next.

No it's not a known problem and we regularly build and test with gcc-4.0.x,
it leads me to suspect that there is some kind of issue with your libstdc++
install, could you try a short test program that uses std::collate?
Something like:

#include <locale>

int main()
{
  std::locale l;
  bool b = l("a", "A");
  return b;
}

I think should probe to see if it's working OK, if that works try
constructing the locale object like this:

std::locale l("en_US");

and see if that reproduces the issue.

Hopefully that will tell is whether it's your gcc install that's to blame.

John.


Boost-Build list run by bdawes at acm.org, david.abrahams at rcn.com, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk