This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] Re: A clue for the libstdc++ problem.
On Apr 2, 2001, "H . J . Lu" <hjl@lucon.org> wrote:
> On Sun, Apr 01, 2001 at 10:08:41PM -0300, Alexandre Oliva wrote:
>> On Apr 1, 2001, "H . J . Lu" <hjl@lucon.org> wrote:
>> > Can you tell me what is wrong with this patch?
>> Sure. When linking C-only executables, libtool sometimes runs the
>> linker directly, which causes dynamic constructors not to run.
> It is wrong for gcc. You do know you can have constructors in C
> with gcc, don't you?
I do. And libtool has been fixed so as to run GCC directly. But it
isn't always possible to do it without knowing why it was done that
way in the first place. In the particular case of Solaris, that
motivated the change, I knew what the reason was, and we already have
a patch from Mark Mitchell that arranges for ltcf-c.sh so as to link
using gcc. But I don't know about other OSs, and many have to use ld
directly, so there's not much I can do until someone steps ahead and
fixes the problem. Meanwhile, I'd rather have libstdc++ working
correctly even on such platforms, and telling libtool to link as C++
will accomplish that, while linking as C won't.
> If you use gcc, as CC, you cannot run the linker directly even for C
> code.
Only unportable C code, given that ordering constructors isn't
portable. But then, if your code is that unportable, why are you
using libtool in the first place?
> It is a bug in libtool if it runs the linker directly on C code with
> gcc.
Patches are always welcome :-) :-)
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicamp oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist *Please* write to mailing lists, not to me