First Last Prev Next    No search results available
Details
: gccld does not link objects/archives in order specified o...
Bug#: 139
: libraries
: Linker
Status: RESOLVED
Resolution: FIXED
: All
: All
: 1.0
: P2
: normal
: 1.4

:
: compile-fail
:
:
  Show dependency tree - Show dependency graph
People
Reporter: Brian R. Gaeke <gaeke+bugs@uiuc.edu>
Assigned To: Reid Spencer <rspencer@reidspencer.com>
:

Attachments


Note

You need to log in before you can comment on or make changes to this bug.

Related actions


Description:   Opened: 2003-11-19 16:48
If you say gccld .... foo.a ... foo.a ... foo.a, it may give you back symbol
redefinition errors, but what we want is for it to search foo.a 3 times, and
only link in any particular member of foo.a once.
------- Comment #1 From Chris Lattner 2003-11-29 03:02:35 -------
The reported problem above is a small part of the larger problems with gccld. 
Currently gccld links together all .o files first, then links in any .a files
needed at the end.  This causes problems like those described in Bug 142, and is
horribly broken otherwise.

Instead of the current behavior, gccld should link objects together in the order
they are specified.  As an archive is encountered, any needed objects should be
linked in, and this fact should be remembered.  Later, if the archive comes up
again, the remaining objects in it should be searched to see if they are needed.
 If any are, they should be linked in.  This should continue until we run out of
archives.

Note that this is also a first step to implementing linkage groups, which are
used by the linux kernel, among others.

-Chris
------- Comment #2 From Chris Lattner 2003-12-19 23:43:40 -------
Unless someone takes ownership for fixing this for 1.2, it's not going to be a
1.2 bug.  :)

-Chris
------- Comment #3 From Chris Lattner 2004-02-25 10:52:20 -------
downgrading this to normal.  This has never effected me :), though it would be
nice to get it fixed eventually.

-Chris
------- Comment #4 From Chris Lattner 2004-02-26 15:30:26 -------
Changing all of these bugs who do not have people looking at them to be assigned
to "unassignedbugs", indicating that if someone is feeling ambitious, they can
take ownership of the bug.

If I stole your bug, and you still want it, feel free to take ownership back.

-Chris
------- Comment #5 From Chris Lattner 2004-02-26 15:31:52 -------
Changing all of these bugs who do not have people looking at them to be assigned
to "unassignedbugs", indicating that if someone is feeling ambitious, they can
take ownership of the bug.

If I stole your bug, and you still want it, feel free to take ownership back.

-Chris
------- Comment #6 From Chris Lattner 2004-02-26 15:34:52 -------
Changing all of these bugs who do not have people looking at them to be assigned
to "unassignedbugs", indicating that if someone is feeling ambitious, they can
take ownership of the bug.

If I stole your bug, and you still want it, feel free to take ownership back.

-Chris
------- Comment #7 From Reid Spencer 2004-12-02 04:19:45 -------
The original test case (first description entry below) seems to be working fine,
as evidenced by this shell session:

bash-2.05b$ cat nada.cpp
#include <iostream>
int main() { std::cout << "Hello, World\n"; return 0; }
bash-2.05b$ llvmgcc -o nada nada.cpp -lc -lc -lc
bash-2.05b$ ./nada
Hello, World
bash-2.05b$

This is the case after bug 466 was fixed.

There is still the issue remaining that the file/library link order is not
preserved. I'll work on that tomorrow.

First Last Prev Next    No search results available