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 314776 - Use of backtrace() breaks OS X support
Use of backtrace() breaks OS X support
Status: RESOLVED FIXED
Product: epiphany
Classification: Core
Component: General
1.7.x
Other All
: Normal normal
: ---
Assigned To: Epiphany Maintainers
Marco Pesenti Gritti
Depends on:
Blocks:
 
 
Reported: 2005-08-29 15:19 UTC by Steve Przybylski
Modified: 2005-08-31 12:01 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Proposed patch (1.15 KB, patch)
2005-08-29 19:08 UTC, Steve Przybylski
committed Details | Review
Revised patch (1.39 KB, patch)
2005-08-30 22:29 UTC, Steve Przybylski
none Details | Review

Description Steve Przybylski 2005-08-29 15:19:06 UTC
Please describe the problem:
Another casualty of Darwin's incomplete libc...building Epiphany fails in
ephy-debug.c, with backtrace being undefined.  Would it be worth adding back in
the old version of trap_handler as a fallback for those systems which don't have
execinfo.h?

Steps to reproduce:
1. ./configure
2. make
3. 


Actual results:
Error - undefined symbol 'backtrace'.
Build fails.

Expected results:
Build completes without error.

Does this happen every time?
Yes.

Other information:
Comment 1 Christian Persch 2005-08-29 15:32:34 UTC
Thanks for the bug report.

I'm not sure what you mean with 'the old version of trap_handler' ?

Would a configure check AC_CHECK_HEADER([execinfo.h]) and then
#ifdef HAVE_EXECINFO_H ... #endif'ing the code be sufficient?
Comment 2 Steve Przybylski 2005-08-29 18:36:22 UTC
That was what I'd thought, but I'm new enough at this that I wanted to hear what
someone else would do.  By the "old version" of trap_handler, I had meant the
section that backtrace had replaced...this:

#ifdef HAVE_DUMPSTACKTOFILE
			DumpStackToFile (stderr);
#else
			g_on_error_stack_trace (g_get_prgname ());
#endif

Sorry, that wasn't very clear, was it? :)
Comment 3 Steve Przybylski 2005-08-29 19:08:53 UTC
Created attachment 51519 [details] [review]
Proposed patch

Would this be the correct fix?	(This is my first patch, so it probably
isn't...)
Comment 4 Christian Persch 2005-08-29 19:18:55 UTC
Yes, that patch is exactly what I meant. I assume you've tested it and it
produces the desired result?
I'll commit it when producing 1.8.0 tarball next monday.

Thanks for the patch!

The 'old method' was a hack; I'd rather not go back to using it.
Comment 5 Christian Persch 2005-08-29 20:13:27 UTC
Checked in.
Comment 6 Steve Przybylski 2005-08-30 22:29:42 UTC
Created attachment 51589 [details] [review]
Revised patch

Sorry, wasn't able to get this to you yesterday - I found one silly mistake in
the original patch.  This compiles correctly on my system, but could you check
that configure does indeed define HAVE_EXECINFO_H on a machine that does have
it?
Comment 7 Christian Persch 2005-08-31 10:13:51 UTC
It's indeed defined.

When I applied the patch I added #ifdef around the #include; any other changes
in your new patch?
Comment 8 Steve Przybylski 2005-08-31 12:01:36 UTC
No, that was it - I had removed the #include while I was puttering around, and
forgot about it until I tried to build from a clean copy.  Thanks for your help
on this!