[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <3D9B99EE.9090904@mvista.com>
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
Please check out the
xvendor mailing list charter.
