Bug 5486

(In reply to comment #0)
> Using CS TC (current or otherwise), 32 bit system. Builroot latest via GIT
> 
> libglib2-2.30.2
> 
> As a general overview:
> CFLAGS="-fno-stack-protector -O2 -ffast-math -march=armv6j -mtune=arm1136jf-s
> -mfpu=vfp -pipe -$fomit-frame-pointer"
> CXXFLAGS="-fno-stack-protector" CPPFLAGS="-U_FORTIFY_SOURCE" 
> HOST=i686-pc-linux
> BUILD=arm-unknown-linux-gnueabi
> 
> Whilst:
> >>> libglib2 2.30.2 Building
> Fails with
>   CC     gtester.o
>   CCLD   libglib-2.0.la
>   CCLD   gtester
> ./.libs/libglib-2.0.so: undefined reference to `qsort_r'
> collect2: ld returned 1 exit status
> 
> There was some reference (related? maybe?) to an embedded patch for libglib2 re
> another system here: http://patches.openembedded.org/patch/14169/ 
> Perhaps it is relevant.
> 
> This is my first bug report apologies for any elided required info.
> Will be glad to forward any extra required.
> 
> Regards.


Just wanted to add that the link doesn't actually point to the fix/patch itself. it's a monologue about when it should be used. and a patch for when it would be applied in the other system. Thanks

Created attachment 4532 [details]
the dot config file used.

The relevant dot config and the lines from the build log


{standard input}: Assembler messages:
{standard input}:6196: rdhi, rdlo and rm must all be different
  CC     gunibreak.lo
  CC     gunicollate.lo
  CC     gunidecomp.lo
  CC     gurifuncs.lo
  CC     gutils.lo
  CC     gvariant.lo
  CC     gvariant-core.lo
  CC     gvariant-parser.lo
  CC     gvariant-serialiser.lo
gvariant-core.c: In function 'g_variant_take_ref':
gvariant-core.c:744: warning: pointer targets in passing argument 1 of 'g_atomic_int_and' differ in signedness
  CC     gvarianttypeinfo.lo
{standard input}: Assembler messages:
{standard input}:46059: rdhi, rdlo and rm must all be different
{standard input}:46074: rdhi, rdlo and rm must all be different
{standard input}:46086: rdhi, rdlo and rm must all be different
{standard input}:46098: rdhi, rdlo and rm must all be different
{standard input}:46480: rdhi, rdlo and rm must all be different
{standard input}:47837: rdhi, rdlo and rm must all be different
{standard input}:47865: rdhi, rdlo and rm must all be different
{standard input}:47875: rdhi, rdlo and rm must all be different
{standard input}:47887: rdhi, rdlo and rm must all be different
  CC     gvarianttype.lo
  CC     gwakeup.lo
  CC     gprintf.lo
  CC     glib-unix.lo
  CC     giounix.lo
  CC     gspawn.lo
echo glib-unix.h glib-object.h glib.h galloca.h garray.h gasyncqueue.h gatomic.h gbacktrace.h gbase64.h gbitlock.h gbookmarkfile.h gcache.h gchecksum.h gcompletion.h gconvert.h gdataset.h gdate.h gdatetime.h gdir.h gerror.h gfileutils.h ghash.h ghmac.h ghook.h ghostutils.h gi18n.h gi18n-lib.h giochannel.h gkeyfile.h glist.h gmacros.h gmain.h gmappedfile.h gmarkup.h gmem.h gmessages.h gnode.h goption.h gpattern.h gpoll.h gprimes.h gqsort.h gquark.h gqueue.h grand.h gregex.h grel.h gscanner.h gsequence.h gshell.h gslice.h gslist.h gspawn.h gstdio.h gstrfuncs.h gtestutils.h gstring.h gthread.h gthreadpool.h gtimer.h gtimezone.h gtree.h gtypes.h gunicode.h gurifuncs.h gutils.h gvarianttype.h gvariant.h gwin32.h gprintf.h > glib-public-headers.txt.tmp && mv glib-public-headers.txt.tmp glib-public-headers.txt
  CC     gtester.o
  CCLD   libglib-2.0.la
  CCLD   gtester
./.libs/libglib-2.0.so: undefined reference to `qsort_r'
collect2: ld returned 1 exit status
make[6]: *** [gtester] Error 1
make[5]: *** [all-recursive] Error 1
make[4]: *** [all] Error 2
make[3]: *** [all-recursive] Error 1
make[2]: *** [all] Error 2
make[1]: *** [/home/simon/BLDS/buildroot/build/libglib2-2.30.2/.stamp_built] Error 2
make: *** [all] Error 2
simon@dev ~/BLDS/buildroot $

http://git.openembedded.org/openembedded-core/plain/meta/recipes-core/glib-2.0/glib-2.0/remove.test.for.qsort_r.patch?id=43adb8dcf4461b68a7ce0ba9d8acdb2012a70416

Appears to be highly relevant in this instance. 
Would this be a straight patch job for this use? 
Many thanks.

My apologies for not managing to encompass all the information in a single post.
I will know better for next time.

Regards.

Shouldn't this be fixed already by the following commit ?

commit 78a5c27cc37f1d0453defa8d3f59762ca7f4c7ef
Author: Sven Neumann <s.neumann@raumfeld.com>
Date:   Wed Feb 29 07:05:49 2012 +0100

    libglib2: fix build with legacy uClibc versions
    
    qsort_r was only added in uClibc 0.9.33, so only enable it when we're sure
    it's available. For external/ctng toolchains we cannot easily know, so
    simply disable it there.
    
    Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>

(In reply to comment #4)
> Shouldn't this be fixed already by the following commit ?
> 
> commit 78a5c27cc37f1d0453defa8d3f59762ca7f4c7ef
> Author: Sven Neumann <s.neumann@raumfeld.com>
> Date:   Wed Feb 29 07:05:49 2012 +0100
> 
>     libglib2: fix build with legacy uClibc versions
> 
>     qsort_r was only added in uClibc 0.9.33, so only enable it when we're sure
>     it's available. For external/ctng toolchains we cannot easily know, so
>     simply disable it there.
> 
>     Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>

I see the changes from http://git.buildroot.net/buildroot/commit/?id=97165f123bd67b8d1a9a0a3bb41f2c4b8475156d in my local .mk

They appear to specifically target uClibc use cases? I'm no expert in these matters.

+ifeq ($(BR2_UCLIBC_VERSION_0_9_31)$(BR2_UCLIBC_VERSION_0_9_32)$(BR2_TOOLCHAIN_CTNG_uClibc)$(BR2_TOOLCHAIN_EXTERNAL_UCLIBC),y)
+LIBGLIB2_CONF_ENV += glib_cv_have_qsort_r=no
+else
+LIBGLIB2_CONF_ENV += glib_cv_have_qsort_r=yes
+endif

Should I refactor this to encompass my TC use case?

Given this unsurity: To move forward I attempted removing the test entirely, this leads to:

checking for format to printf and scanf a guint64... none
checking for an ANSI C-conforming const... yes
checking if malloc() and friends prototypes are gmem.h compatible... yes
checking for growing stack pointer... configure: error: in `/home/simon/BLDS/buildroot/build/libglib2-2.30.2':
configure: error: cannot run test program while cross compiling
See `config.log' for more details
make[2]: *** [config.status] Error 1
make[1]: *** [/home/simon/BLDS/buildroot/build/libglib2-2.30.2/.stamp_built] Error 2
make: *** [all] Error 2

Which would suggest that even if this worked as intended it would not be a complete solution. Currently endeavouring to bypass this next hurdle.

Many thanks.

Well, yes, the fix that Peter committed specifically addresses the uCLibC case. If your external toolchain doesn't provide qsort_r, then your build will still fail.

I am not sure if this can be fixed properly in buildroot as we can't know all details about any possible external toolchain. But you can work around this by adding "glib_cv_have_qsort_r=no" to LIBGLIB2_CONF_ENV in your tree.

(In reply to comment #6)
> Well, yes, the fix that Peter committed specifically addresses the uCLibC case.
> If your external toolchain doesn't provide qsort_r, then your build will still
> fail.
> 
> I am not sure if this can be fixed properly in buildroot as we can't know all
> details about any possible external toolchain. But you can work around this by
> adding "glib_cv_have_qsort_r=no" to LIBGLIB2_CONF_ENV in your tree.

Okay some progress.

As I said I am unsure why but defaulting the values via your method. Now read up on the process so I understand that should have defaulted the value to yes - which *is* the case for the TC.

so to *get further* I simply elided the test as per the patch I referenced above which got me one step farther; past the qsort_r error with it correctly identified to the positive.

Which led to a fail testing the stack growth. I razed everything to the ground and started again. applied the qsort_r.patch I referenced and this time I get.

tests'
make[5]: Nothing to be done for `install-exec-am'.
make[5]: Nothing to be done for `install-data-am'.
make[5]: Leaving directory `/home/simon/GIT/buildroot/output/build/host-libglib2-2.30.2/gobject/tests'
make[4]: Leaving directory `/home/simon/GIT/buildroot/output/build/host-libglib2-2.30.2/gobject/tests'
make[3]: Leaving directory `/home/simon/GIT/buildroot/output/build/host-libglib2-2.30.2/gobject'
make[2]: Leaving directory `/home/simon/GIT/buildroot/output/build/host-libglib2-2.30.2/gobject'
Making install in gio
make[2]: Entering directory `/home/simon/GIT/buildroot/output/build/host-libglib2-2.30.2/gio'
/usr/bin/make  install-recursive
make[3]: Entering directory `/home/simon/GIT/buildroot/output/build/host-libglib2-2.30.2/gio'
Making install in gdbus-2.0/codegen
make[4]: Entering directory `/home/simon/GIT/buildroot/output/build/host-libglib2-2.30.2/gio/gdbus-2.0/codegen'
make[5]: Entering directory `/home/simon/GIT/buildroot/output/build/host-libglib2-2.30.2/gio/gdbus-2.0/codegen'
 /bin/mkdir -p '/home/simon/GIT/buildroot/output/host/usr/bin'
 /bin/mkdir -p '/home/simon/GIT/buildroot/output/host/usr/lib/gdbus-2.0/codegen'
 /usr/bin/install -c gdbus-codegen '/home/simon/GIT/buildroot/output/host/usr/bin'
 /usr/bin/install -c -m 644 __init__.py codegen.py codegen_main.py codegen_docbook.py config.py dbustypes.py parser.py utils.py '/home/simon/GIT/buildroot/output/host/usr/lib/gdbus-2.0/codegen'
../../../py-compile: Missing argument to --destdir.
make[5]: *** [install-codegenPYTHON] Error 1
make[5]: Leaving directory `/home/simon/GIT/buildroot/output/build/host-libglib2-2.30.2/gio/gdbus-2.0/codegen'
make[4]: *** [install-am] Error 2
make[4]: Leaving directory `/home/simon/GIT/buildroot/output/build/host-libglib2-2.30.2/gio/gdbus-2.0/codegen'
make[3]: *** [install-recursive] Error 1
make[3]: Leaving directory `/home/simon/GIT/buildroot/output/build/host-libglib2-2.30.2/gio'
make[2]: *** [install] Error 2
make[2]: Leaving directory `/home/simon/GIT/buildroot/output/build/host-libglib2-2.30.2/gio'
make[1]: *** [install-recursive] Error 1
make[1]: Leaving directory `/home/simon/GIT/buildroot/output/build/host-libglib2-2.30.2'
make: *** [/home/simon/GIT/buildroot/output/build/host-libglib2-2.30.2/.stamp_host_installed] Error 2

Is this related to the other python patch - and should I change the title of the bug report? Attempting to become more useful.

Many thanks.

So I deleted everything again and resynced from GIT.

I now cannot replicate the earlier failure on qsort_r. However I now still fail:

make V=99 2>&1 | tee build.log

...
libs/libglib-2.0.lax/libpcre.a/pcre_try_flipped.o .libs/libglib-2.0.lax/libpcre.a/pcre_ucp_searchfuncs.o .libs/libglib-2.0.lax/libpcre.a/pcre_xclass.o 
libtool: link: /home/simon/GIT/buildroot/output/host/usr/bin/arm-none-linux-gnueabi-ranlib .libs/libglib-2.0.a
libtool: link: rm -fr .libs/libglib-2.0.lax
libtool: link: ( cd ".libs" && rm -f "libglib-2.0.la" && ln -s "../libglib-2.0.la" "libglib-2.0.la" )
/bin/sh ../libtool  --tag=CC   --mode=link /home/simon/GIT/buildroot/output/host/usr/bin/arm-none-linux-gnueabi-gcc  -pipe -Os  -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -Wall   -o gtester gtester.o libglib-2.0.la  
libtool: link: /home/simon/GIT/buildroot/output/host/usr/bin/arm-none-linux-gnueabi-gcc -pipe -Os -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -Wall -o gtester gtester.o  ./.libs/libglib-2.0.so -lrt -Wl,-rpath -Wl,/home/simon/GIT/buildroot/output/build/libglib2-2.30.2/glib/.libs
./.libs/libglib-2.0.so: undefined reference to `qsort_r'
collect2: ld returned 1 exit status
make[5]: *** [gtester] Error 1
make[5]: Leaving directory `/home/simon/GIT/buildroot/output/build/libglib2-2.30.2/glib'
make[4]: *** [all-recursive] Error 1
make[4]: Leaving directory `/home/simon/GIT/buildroot/output/build/libglib2-2.30.2/glib'
make[3]: *** [all] Error 2
make[3]: Leaving directory `/home/simon/GIT/buildroot/output/build/libglib2-2.30.2/glib'
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory `/home/simon/GIT/buildroot/output/build/libglib2-2.30.2'
make[1]: *** [all] Error 2
make[1]: Leaving directory `/home/simon/GIT/buildroot/output/build/libglib2-2.30.2'
make: *** [/home/simon/GIT/buildroot/output/build/libglib2-2.30.2/.stamp_built] Error 2


The .config has nothing in it aside from libglib2 (and auto-selected dependencies)

In essence, this doesn't happen using the Buildroot installed Code Sourcery Toolchains.

For my use case I was attempting to utitlise a pre-installed chain.
It was possibly too old a version.

Using the 2011 TC fixes this. So I will set it as a non issue and possibly add a note when I figure out the oldest CS TC that *will* build this without error.

(I run all this on a 3rd gen kindle, no really)
Thanks for all your help.

If I find something *actually* useful to contribute I will.
Regards.

(In reply to comment #9)
> In essence, this doesn't happen using the Buildroot installed Code Sourcery
> Toolchains.
> 
> For my use case I was attempting to utitlise a pre-installed chain.
> It was possibly too old a version.
> 
> Using the 2011 TC fixes this. So I will set it as a non issue and possibly add
> a note when I figure out the oldest CS TC that *will* build this without error.
> 
> (I run all this on a 3rd gen kindle, no really)
> Thanks for all your help.
> 
> If I find something *actually* useful to contribute I will.
> Regards.

Okay as promised.   

CCLD   libglib-2.0.la
  CCLD   gtester
./.libs/libglib-2.0.so: undefined reference to `qsort_r'

First exhibits in Toolchains older than 

rm-2008q3-72-arm-none-linux-gnueabi-i686-pc-linux-gnu.tar.bz2

From here:

http://sourcery.mentor.com/public/gnu_toolchain/arm-none-linux-gnueabi/

so perhaps a "min required version" might properly reflect that.

2008q3 onward all build as expected.