Messages in this thread |  | | Date | Fri, 1 Sep 2000 12:01:39 -0700 (PDT) | From | Matthew Jacob <> | Subject | Re: Large File support and blocks. |
| |
> > 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/
|  |