1 |
On Tue, 04 Jun 2002 16:56, Prashanth Aditya Susarla wrote: |
2 |
> > It is precisely because it is a precompiled library that it does make a |
3 |
> > difference. To point out what perhaps is obvious: had it been source we'd |
4 |
> > never had the problem in the first place. |
5 |
> |
6 |
> Ok, thanks for clearing that up. I was under the impression that one has |
7 |
> to use -lgcc_s while compiling sources so that libgcc_s.so is linked |
8 |
> dynamically at runtime. Obviously, if we had the sources... |
9 |
> |
10 |
|
11 |
That is absolutely correct in the normal case -- unless you state the library |
12 |
on the link line you'll get a linker error. The tricky thing in this case is |
13 |
that it's the compiler itself that's generating the calls to functions in |
14 |
libgcc_s and not the user code directly. libgcc_s contains various |
15 |
housekeeping functions the compiler may call depending on the end-user code |
16 |
(some refer to it as a junk drawer that contains stuff that doesn't fit |
17 |
anywhere else). So as a developer you may not even know you are referencing |
18 |
stuff in that lib. |
19 |
|
20 |
The older binutils made up for that by re-exporting the symbols that were |
21 |
referenced in libgcc_s so you'd end up with a reference to libgcc_s |
22 |
implicitly. That does not happen anymore. I believe that if nvidia were to |
23 |
take the build environment they used to produce what we have and tries to do |
24 |
a build under the new binutils the library won't even build. |
25 |
|
26 |
Any linker gurus out there that could let me know if I'm talking shite? |
27 |
|
28 |
/Lasse |