mailing list of musl libc
 help / color / mirror / code / Atom feed
* -fno-stack-protector and musl
@ 2013-10-21 15:20 Christopher Meng
  2013-10-21 15:32 ` Rich Felker
  0 siblings, 1 reply; 3+ messages in thread
From: Christopher Meng @ 2013-10-21 15:20 UTC (permalink / raw)
  To: musl

Hi all,

I'm going to package this c lib into Fedora for skalibs. However
Fedora forces us to package every pkg with optflags inserted:

[rpmaker@fab SPECS]$ rpm -E %{optflags}
-O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions
-fstack-protector-strong --param=ssp-buffer-size=4
-grecord-gcc-switches  -m32 -march=i686 -mtune=atom
-fasynchronous-unwind-tables

Which caused errors during linking:

src/aio/aio_readwrite.lo: In function `new_req':
/home/rpmaker/rpmbuild/BUILD/musl-0.9.14/src/aio/aio_readwrite.c:95:
undefined reference to `__stack_chk_fail_local'
src/aio/aio_readwrite.lo: In function `io_thread':
/home/rpmaker/rpmbuild/BUILD/musl-0.9.14/src/aio/aio_readwrite.c:64:
undefined reference to `__stack_chk_fail_local'
src/aio/aio_suspend.lo: In function `aio_suspend':
/home/rpmaker/rpmbuild/BUILD/musl-0.9.14/src/aio/aio_suspend.c:57:
undefined reference to `__stack_chk_fail_local'
src/aio/lio_listio.lo: In function `wait_thread':
/home/rpmaker/rpmbuild/BUILD/musl-0.9.14/src/aio/lio_listio.c:68:
undefined reference to `__stack_chk_fail_local'
src/aio/lio_listio.lo: In function `lio_listio':
/home/rpmaker/rpmbuild/BUILD/musl-0.9.14/src/aio/lio_listio.c:142:
undefined reference to `__stack_chk_fail_local'
src/complex/__cexp.lo:/home/rpmaker/rpmbuild/BUILD/musl-0.9.14/src/complex/__cexp.c:87:
more undefined references to `__stack_chk_fail_local' follow
collect2: error: ld returned 1 exit status
make: *** [lib/libc.so] Error 1
error: Bad exit status from /var/tmp/rpm-tmp.KSavLI (%build)


undefined reference to `__stack_chk_fail_local' is a well-known
problem related to stack protector. I know the solution is to change
it to:

-fno-stack-protector, however this will violate packaging guidelines.

Any help?

Thanks.

PS:

gcc-go-4.8.2-1.fc21.i686
glibc-2.18.90-11.fc21.i686
gcc-c++-4.8.2-1.fc21.i686
glibc-common-2.18.90-11.fc21.i686
glibc-headers-2.18.90-11.fc21.i686
gcc-objc-4.8.2-1.fc21.i686
glibc-devel-2.18.90-11.fc21.i686
libgcc-4.8.2-1.fc21.i686
gcc-4.8.2-1.fc21.i686
gcc-gfortran-4.8.2-1.fc21.i686




Yours sincerely,
Christopher Meng

Always playing in Fedora Project

http://cicku.me


^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: -fno-stack-protector and musl
  2013-10-21 15:20 -fno-stack-protector and musl Christopher Meng
@ 2013-10-21 15:32 ` Rich Felker
  2013-10-21 15:39   ` Christopher Meng
  0 siblings, 1 reply; 3+ messages in thread
From: Rich Felker @ 2013-10-21 15:32 UTC (permalink / raw)
  To: musl

On Mon, Oct 21, 2013 at 11:20:06PM +0800, Christopher Meng wrote:
> Hi all,
> 
> I'm going to package this c lib into Fedora for skalibs. However
> Fedora forces us to package every pkg with optflags inserted:

I can assure you glibc is not compiled with stack protector either, so
there are exceptions to this policy. :) You should just cite such an
exception.

It's my long-term goal to support compiling musl itself with stack
protector, but this is dependent on groundwork in two areas:

1. There needs to be a way to force stack protector off in at least a
   few files which are needed for early initialization, before the
   canary is available. This needs build system support and call tree
   analysis of what files need such special handling.

2. Since the canary is stored at a fixed offset from the thread
   pointer, the thread pointer must always be initialized when ssp is
   used. This is handled correctly now (modulo one gcc bug) for apps
   and libs that use ssp, but not for libc-internal use. In the 1.1
   series I plan to make the thread pointer always-initialized.

I expect the resolution of this issue somewhere in the early to mid
1.1 series. For what it's worth, we're no worse than glibc in this
regard right now, and hope to be better in the future.

Rich


^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: -fno-stack-protector and musl
  2013-10-21 15:32 ` Rich Felker
@ 2013-10-21 15:39   ` Christopher Meng
  0 siblings, 0 replies; 3+ messages in thread
From: Christopher Meng @ 2013-10-21 15:39 UTC (permalink / raw)
  To: musl

Yes, I just found that glibs is not compiled with that f**king option ;)

Solved.

Thanks!

-- 


*Yours sincerely,*
*Christopher Meng*

Always playing in Fedora Project

http://cicku.me


^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2013-10-21 15:39 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2013-10-21 15:20 -fno-stack-protector and musl Christopher Meng
2013-10-21 15:32 ` Rich Felker
2013-10-21 15:39   ` Christopher Meng

Code repositories for project(s) associated with this public inbox

	https://git.vuxu.org/mirror/musl/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).