https://llvm.org/bugs/show_bug.cgi?id=26807
Bug ID: 26807
Summary: --start-lib/--end-lib sometimes ignored with LTO
Product: libraries
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: Linker
Assignee: unassignedb...@nondot.org
Reporter: eugeni.stepa...@gmail.com
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified
This is similar to PR26674, but the problem happens in a different place and
the proposed fix for PR26674 does not affect this. I'm almost sure the bug is
actually in gold, but I can only reproduce it with the LLVM plugin at this
point, so I'm filing the C++-level test case here.
$ cat 1.h
struct A {
A(void *);
};
$ cat 1.cc
#include <stdio.h>
#include "1.h"
A::A(void *p) { printf("register %p\n", p); }
$ cat 2.cc
#include "1.h"
bool q;
static A a(&q);
int main() {}
$ cat 3.cc
#include "1.h"
bool z;
static A a(&z);
$ ./bin/clang++ 1.cc 2.cc 3.cc -flto -c
$ ./bin/clang++ -flto -fuse-ld=gold 2.o -Wl,--start-lib 3.o -Wl,--end-lib
-Wl,--start-lib 3.o -Wl,--end-lib 1.o
/usr/bin/ld.gold: error: 3.o: multiple definition of 'z'
/usr/bin/ld.gold: 3.o: previous definition here
Basically, gold decided to link 3.o even though it does not resolve any new
symbols.
If the second instance of 3.o is removed from the link line, then the link
succeeds, but the resulting executable incorrectly runs the A::A(&z)
initializer (which proves that 3.o was included in the link).
This is the list of symbols that the plugin returns to gold for 3.o, both with
default visibility:
UNDEF _ZN1AC1EPv
DEF z
--
You are receiving this mail because:
You are on the CC list for the bug.
_______________________________________________
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
