After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 684723 - run-assert-msg-test.sh fails
run-assert-msg-test.sh fails
Status: RESOLVED FIXED
Product: glib
Classification: Platform
Component: build
2.34.x
Other Mac OS
: Normal normal
: ---
Assigned To: gtkdev
gtkdev
: 629164 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2012-09-24 15:45 UTC by Daniel Macks
Modified: 2017-05-16 08:18 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
tests: multiple fixes to run-assert-msg-test.sh (1.92 KB, patch)
2012-11-20 14:25 UTC, Dan Winship
committed Details | Review

Description Daniel Macks 2012-09-24 15:45:41 UTC
glib-2.34.0 built on OS X 10.6 (using "-arch i386" as compiler flag), then failed 'make check' in glib-2.34.0/tests...

Test failed: failed to run gdb
FAIL: run-assert-msg-test.sh


Running that test specifically:

$ ./run-assert-msg-test.sh -v
Running assert-msg-test
Running gdb on assert-msg-test
libtool: unknown option character `-' in: --mode=execute
Usage: libtool -static [-] file [...] [-filelist listfile[,dirname]] [-arch_only arch] [-sacLT]
Usage: libtool -dynamic [-] file [...] [-filelist listfile[,dirname]] [-arch_only arch] [-o output] [-install_name name] [-compatibility_version #] [-current_version #] [-seg1addr 0x#] [-segs_read_only_addr 0x#] [-segs_read_write_addr 0x#] [-seg_addr_table <filename>] [-seg_addr_table_filename <file_system_path>] [-all_load] [-noall_load]
Test failed: failed to run gdb

Apple's /usr/bin/libtool is some special OS X tool, not the usual libtool system we all know. I do have a /usr/bin/glibtool and of course glib-2.34.0/libtool generated by the build system. Both of these seem to have a CLI that matches what run-assert-msg-test.sh is using (but the former appears to be a fairly old version). Putting PATH=$(top_builddir):$${PATH}} into TESTS_ENVIRONMENT resolves the problem, allowing the test to find a modern "libtool" program generated by the glib build process itself and therefore of a predictable version and interface regardless of what old and/or oddly-named stuff might be on base system.
Comment 1 Daniel Macks 2012-09-24 16:04:35 UTC
...but the test still fails even if it uses a viable libtool program:

Running assert-msg-test
Running gdb on assert-msg-test
Checking if assert message is in __glib_assert_msg
Test failed: __glib_assert_msg does not have assertion message
FAIL: run-assert-msg-test.sh

The $OUT variable contains:

Reading symbols for shared libraries ....... done

My gdb is /usr/bin/gdb, which reports (--version) itself to be:

GNU gdb 6.3.50-20050815 (Apple version gdb-1708) (Mon Aug 15 16:03:10 UTC 2011)

Do I need some newer gdb or a different flavor of it altogether? Is the gdb feature in glib generally not likely to be viable on non-linux/non-ELF systems?
Comment 2 Daniel Macks 2012-11-18 18:00:46 UTC
Ping? Still failing on 2.34.2
Comment 3 Dan Winship 2012-11-20 14:25:30 UTC
Created attachment 229474 [details] [review]
tests: multiple fixes to run-assert-msg-test.sh

1) use "../libtool" rather than "libtool" to avoid problems
with wacky OS X not-actually-libtool

2) Use libtool on the libtool script, not the binary, so that it
actually does anything

3) Don't use "gdb --ex" since it's apparently new-ish/non-portable.
Comment 4 Daniel Macks 2012-11-21 04:50:31 UTC
Thanks! Passes with either apple's or fink's gdb. (os x 10.6/32-bit)
Comment 5 Dan Winship 2012-12-19 13:34:12 UTC
pushed
Comment 6 Philip Withnall 2017-05-16 08:18:45 UTC
*** Bug 629164 has been marked as a duplicate of this bug. ***