Date: Sun, 04 Feb 1996 00:48:29 +0800 From: Peter Wemm <peter@jhome.DIALix.COM> To: "Rodney W. Grimes" <rgrimes@GndRsh.aac.dev.com> Cc: bde@zeta.org.au (Bruce Evans), CVS-committers@freebsd.org, cvs-lib@freebsd.org, jdp@polstra.com, nate@sri.MT.net Subject: Re: cvs commit: src/lib/csu/i386 crt0.c Message-ID: <199602031648.AAA25239@jhome.DIALix.COM> In-Reply-To: Your message of "Sat, 03 Feb 1996 08:26:33 PST." <199602031626.IAA22687@GndRsh.aac.dev.com>
next in thread | previous in thread | raw e-mail | index | archive | help
>>
>> >IMHO, the "safest" thing to do is ensure that we do all the compiling of th
>e
>> >utility programs to generate library code first, before we even touch
>> >anything in /usr/lib or /usr/include. ie: (cd lib ; make depend) before
>> >doing the CLOBBER in the libraries target.
>>
>> There's no guarantee that `make depend' creates all the utilities. It
>> has to create most of them to get the dependencies right, however.
>>
>> If I ran `make world' a lot (I haven't tried it yet!) then I would
>> remove the `make depend' step to speed it up a little. If NOCLEANDIR
>> isn't defined, the .depend files are almost never used for `make world'
>> because `make depend all' gives bogus dependencies for the `all' target
>> (the .depend files don't exist when the dependencies are determined).
>
>You keep saying this, but it is not totally true, _especially_ when
>this command is run from a high level in the source tree.
>
>Ie, cd /usr/src; make depend all; does infact DTRT as first a full sweep
>over the src tree creating .depends is run, then a full pass over the
>tree running make all (at this point the .depends do exist).
>
>There are several cases though that should be changed to:
>make depend && make all.
Like the kernel compile area for example. I use 'config -n' (because
I'm very aware of the dependency sideeffects when I do this and manually
clean either the files themselves or do a make clean.) and have always
done a "make depend ; make all". It's good to know I haven't been wasting
my keystrokes.. :-)
Anyway, a slight diversion.. :-) A question about the original topic. :-)
It seems that linker_sets are not constructed at run-time by the dynamic
linker.. (although I could be wrong)
Why can't we use a c++ style constructor? all gcc supplied "main()"
code contains calls to __main() in libgcc.a.
ie: foo.c:
main()
{}
becomes foo.s:
.file "foo.c"
gcc2_compiled.:
___gnu_compiled_c:
.text
.align 2
.globl _main
.type _main,@function
_main:
pushl %ebp
movl %esp,%ebp
call ___main
L1:
leave
ret
Lfe1:
.size _main,Lfe1-_main
So, 99.999% of the problems could be solved by using the built-in gcc
"glue" for linking and calling c++ code from a "c" main.
It also means we can put the init code inside only libc_r and it'll all
"just work" without messing with libc at all. A "c++" constructor will
appear and it will call the "c" thread_init() function.
This is, of course, assuming that c++ constructors in dynamic loaded
shared libs is "working"....
-Peter
>--
>Rod Grimes rgrimes@gndrsh.aac.dev.com
>Accurate Automation Company Reliable computers for FreeBSD
Cheers,
-Peter
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199602031648.AAA25239>