Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Wed, 02 Oct 2002 20:14:22 -0500
From: Mark Hatle <fray@...sta.com>
To: xvendor@...ts.openwall.com
Subject: Re: stackguard?

Ahah!  I should have spoken up earlier..  We see this problem all of the time in 
our stuff.. (generally cross compiled.. or built for a set of libraries 
incompatable with the building system.. anyway..)

Our solution to these issues is to change almost all of the linking in the 
system to use "gcc" instead of "ld".  This makes sure that all of the 
appropriate symbols get linked in..  (primarily due to libgcc.a or crt*.o).. 
There are a few cases where you need to use "ld" still.. (mind you I can't think 
of any off hand.. but I know they exist)  For those you will need to carfully 
craft your ld line to include crt*.o or libgcc.a or both depending on your 
requirements..

But we make a point in our docs and customer conversations you should ALWAYS 
link w/ gcc..  This has significantly reduced support issues for things like 
this.  (This may be even more important w/ gcc 3.x because it does a few things 
differently..)

--Mark

> Alas, the symbol provided in glibc is visible internally to glibc only.
> The __canary_death_handler is also provided by the compiler in crtbegin.o
> and libgcc.a, but those are not commonly linked in when linking a shared
> library. 
> 
> Andreas, you'll either need to compile php and apache with stackguard,
> or link in a version of canary.o into imap.so.
> 



Powered by blists - more mailing lists

Your e-mail address:

Please check out the xvendor mailing list charter.