This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] libjava, darwin - don't pass -allow_stack_execute for -dynamiclib or -bundle
- From: Mike Stump <mikestump at comcast dot net>
- To: Peter O'Gorman <peter at pogma dot com>
- Cc: GCC Patches <gcc-patches at gcc dot gnu dot org>
- Date: Thu, 10 Jun 2010 15:32:53 -0700
- Subject: Re: [PATCH] libjava, darwin - don't pass -allow_stack_execute for -dynamiclib or -bundle
- References: <4C0CFE33.8080507@pogma.com>
On Jun 7, 2010, at 7:12 AM, Peter O'Gorman wrote:
> When running the recently released libtool-2.2.8 testsuite on x86_64-apple-darwin10 with gcc-4.5, I noticed that a couple of tests failed. One of them was:
> ./convenience.at:275: $LIBTOOL --tag=GCJ --mode=link $GCJ $GCJFLAGS $LDFLAGS -o liba12.la liba1.la liba2.la -rpath /notexist
> stderr:
> ld: -allow_stack_execute option can only be used when linking a main executable
> collect2: ld returned 1 exit status
> stdout:
> libtool: link: gcj -dynamiclib -Wl,-undefined -Wl,dynamic_lookup -o .libs/liba12.0.dylib -Wl,-force_load,./.libs/liba1.a -Wl,-force_load,./.libs/liba2.a -L/sw/lib -install_name /notexist/liba12.0.dylib -compatibility_version 1 -current_version 1.0 -Wl,-single_module
> ./convenience.at:275: exit code was 1, expected 0
>
> This patch limits adding -allow_stack_execute to cases without -dynamiclib or -bundle.
>
> Tested on x86_64-apple-darwin10, no java regressions, and tested that gcj can successfully create a dylib and bundle.
>
> Ok for trunk?
Ok.
I'd like a clean way for a frontend to communicate this flag should be passed, and then java, or which ever front end generated the need for it, could just use that mechanism. Oh well.