Segfault in re_search_internal() - SOLVED!
Jeremy Bowen
jeremy.bowen at pertronic.co.nz
Thu Nov 13 22:10:49 UTC 2008
Replying to myself....
On Thursday 13 November 2008 4:54:35 pm Jeremy Bowen wrote:
> This commands results in my busybox "mdev -s" command segfaulting:
> sudo make clean install PREFIX=/usr/local/avr32/avr32-linux/ DEVEL_PREFIX=
> RUNTIME_PREFIX=
>
> This command results in no segfault:
> > su
>
> # make clean install PREFIX=/usr/local/avr32/avr32-linux/ DEVEL_PREFIX=
> RUNTIME_PREFIX=
Having identified this as a problem with my uClibc installation I further
traced this to what looked to be an incorrect path selection in the build
process.
I had previously installed a pre-built (and known buggy) binary toolchain from
RPM's from the Atmel site but I hadn't removed these. This was part of the
motivation for building my own toolchain in the first place.
The old avr32-linux-gcc was in /usr/bin which was not referenced from my
normal environment and I had my new compiler in /usr/loca/avr32/bin which I
had set higher in my $PATH
Using "su" inherited my environment from my shell and was OK.
Using "sudo" did not inherit the $PATH from my shell and picked up the old
buggy binaries installed in /usr/bin.
Consequently the uClibc build process was being built by the old compiler and
picking up older header files from this previous install while
building/installing my new uClibc, resulting in the ensuing segfaults.
The only thing I'm not clear about is how uClibc determines the dependenices
and which headers to build with. All the *.oS.dep files were referencing the
older paths. This doesn't seem to be a .config option so it must have been
picking them up from the compiler. For my own edification I'd like to know
which part of the uClibc build process does this and how.
I'm now off for a cup of tea & a lie down, and to learn all about the "-E"
option to sudo :-)
--
Cheers
JeremyB
More information about the uClibc
mailing list