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