On 3/13/2013 03:50, Dave Yeo wrote:> On 03/12/13 12:39 pm, Erik de Castro Lopo wrote: >> For the Linux -> Windows cross compile for instance, this detects >> SSP as working, but when I compile it fails with: >> >> CC stream_encoder_framing.lo >> CC window.lo >> CCLD libFLAC.la >> Creating library file: .libs/libFLAC.dll.a >> .libs/metadata_iterators.o:metadata_iterators.c:(.text+0x8d): undefined reference to `___stack_chk_guard' >> .libs/metadata_iterators.o:metadata_iterators.c:(.text+0x121): undefined reference to `___stack_chk_guard' >> .libs/metadata_iterators.o:metadata_iterators.c:(.text+0x14f): undefined reference to `___stack_chk_fail' >> >> The odd thinh is, if I use this MinGW cross-compiler to compile a small >> program, it works perfectly. The problem aboce is related to building >> a Windows DLL. > > I can get around the undefined symbol errors by doing make LDFLAGS=-lssp > Perhaps Windows and FreeBSD will also work if linked against ssp.a / > ssp.dll. OF course this introduces another dependency. > DaveDave, my toolchain automatically links libssp already, I am using vanilla sources. Erik, Why not also check if -lssp is required? If the toolchain has SSP disabled it should not be passing. Check onces without -lssp and another time with -lssp if it failed. Also, I don't think a trivial hello world will cause SSP code to be emitted, try adding some arrays in stack with a deliberate overrun possibility for the link test. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 834 bytes Desc: OpenPGP digital signature Url : http://lists.xiph.org/pipermail/flac-dev/attachments/20130313/a4039f91/attachment.pgp
JonY wrote:> Dave, my toolchain automatically links libssp already, I am using > vanilla sources.Are you doing a native Windows compile with MinGW or cross compiling from Linux?> Why not also check if -lssp is required? If the toolchain has SSP > disabled it should not be passing. Check onces without -lssp and another > time with -lssp if it failed.If we can easily force the linking of libssp then that maky work. I'm not real keen on having the Windows DLL require this extra libssp-X.dll.> Also, I don't think a trivial hello world will cause SSP code to be > emitted, try adding some arrays in stack with a deliberate overrun > possibility for the link test.Unfortunately its even more complicated than that. It can sucessfully link and create a valid executable (with and without -lssp) which then fails at run time because it can't find libssp-0.dll. This stuff is broken. I cannot see any reasonable way to make this work across the board. The best option I can suggest is a ./configure --enable-stack-smash-protect which is disabled by default. Erik -- ---------------------------------------------------------------------- Erik de Castro Lopo http://www.mega-nerd.com/
Erik de Castro Lopo wrote:> This stuff is broken. I cannot see any reasonable way to make this > work across the board. The best option I can suggest is a > > ./configure --enable-stack-smash-protect > > which is disabled by default.This is now in git. Erik -- ---------------------------------------------------------------------- Erik de Castro Lopo http://www.mega-nerd.com/
On 3/13/2013 06:50, Erik de Castro Lopo wrote:> JonY wrote: > >> Dave, my toolchain automatically links libssp already, I am using >> vanilla sources. > > Are you doing a native Windows compile with MinGW or cross compiling > from Linux? >Crossing from Cygwin, GCC built from vanilla FSF sources.>> Why not also check if -lssp is required? If the toolchain has SSP >> disabled it should not be passing. Check onces without -lssp and another >> time with -lssp if it failed. > > If we can easily force the linking of libssp then that maky work. I'm > not real keen on having the Windows DLL require this extra libssp-X.dll. >I guess that's libtool doing it. The link test that I used certainly did not require the DLL.>> Also, I don't think a trivial hello world will cause SSP code to be >> emitted, try adding some arrays in stack with a deliberate overrun >> possibility for the link test. > > Unfortunately its even more complicated than that. It can sucessfully > link and create a valid executable (with and without -lssp) which then > fails at run time because it can't find libssp-0.dll. >Libtool forces all DLL code to link to other DLLs.> This stuff is broken. I cannot see any reasonable way to make this > work across the board. The best option I can suggest is a > > ./configure --enable-stack-smash-protect > > which is disabled by default. >I am OK with this. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 834 bytes Desc: OpenPGP digital signature Url : http://lists.xiph.org/pipermail/flac-dev/attachments/20130313/5703fe3c/attachment.pgp