>
> Or use --print-libgcc-file-name:
>
> `gcc <options> --print-libgcc-file-name`
>
> where <options> are the options normally used to compile code (ie, for example
> on machines that optionally do not have a floating point use, adding
> -msoft-float would select the libgcc.a that was compiled with -msoft-float).
Tsk. Showing my age and ignorance, I guess. I was using the gcc -v trick back
at Auspex in '93. ...Guess the compiler driver has gotten smarter since.
You know how it goes- you do a trick once- you don't change it for years...
>
> > That is, unless somebody wants to write the support functions (specific to
> > gcc, ah, but which one?) into the linux kernel? Oh dear, I don't think so..
>
> Other than division, most of the 64 bit support functions are fairly easy to
> write. Obviously, if you do this and gcc 7.0 changes the interface to call
> different functions, you are hosed.
That's the point. The support routines are paired with the compiler, not the
kernel. And the support routines have to be able to link with the
kernel. Having 20 different kernel platforms duplicate code already in
libgcc.a is silly unless the code in libgcc.a is so bad for the kernel that
you have to do otherwise.
-matt
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Thu Sep 07 2000 - 21:00:11 EST