Bug#578831: link failure with LTO: ???invalid DSO for symbol `pthread_cancel@@GLIBC_2.0' definition???
forwarded 578831 http://gcc.gnu.org/PR41376 thanks On Sat, Aug 14, 2010 at 03:57:36PM +0200, Matthias Klose wrote: > retitle 578831 collect2 does not handle static libraries > forwarded 578831 http://bugs.debian.org/PR578831 > tag 578831 + upstream > thanks I assume that was the URL you meant (the bugs.debian.org URL points to a 404 page). /* Steinar */ -- Homepage: http://www.sesse.net/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#578831: link failure with LTO: ???invalid DSO for symbol `pthread_cancel@@GLIBC_2.0' definition???
retitle 578831 collect2 does not handle static libraries
forwarded 578831 http://bugs.debian.org/PR578831
tag 578831 + upstream
thanks
On 08.08.2010 13:40, Kirill Smelkov wrote:
On Sun, Aug 08, 2010 at 12:24:58PM +0200, Steinar H. Gunderson wrote:
OK, I think I've spotted the problem -- it doesn't like that .a files
reference variables in .o files.
fugl:~/dev/lto> cat a.cpp
int var;
fugl:~/dev/lto> cat b.cpp
#include
extern int var;
int main(void)
{
printf("hello: %d\n", var);
}
fugl:~/dev/lto> g++-4.5 -flto -o a.o -c a.cpp
fugl:~/dev/lto> g++-4.5 -flto -o b.o -c b.cpp
fugl:~/dev/lto> ar rc libwhatever.a b.o
fugl:~/dev/lto> ranlib libwhatever.a
fugl:~/dev/lto> g++-4.5 -flto -fwhole-program -Wl,--gc-sections -o prog
-Wl,--start-group a.o libwhatever.a -Wl,--end-group
libwhatever.a(b.o): In function `main':
b.cpp:(.text+0xa): undefined reference to `var'
collect2: ld returned 1 exit status
If I put a.o into an .a file, it works. The order of a.o and libwhatever.a
doess not matter. Removing -fwhole-program fixes it.
This is a bug, right?
On Sun, Aug 08, 2010 at 12:59:51PM +0200, Steinar H. Gunderson wrote:
On Sun, Aug 08, 2010 at 12:46:54PM +0200, Steinar H. Gunderson wrote:
OK, I think I've spotted the problem -- it doesn't like that .a files
reference variables in .o files.
Actually, .a files are not recompiled for LTO at all. If I stick everything
in .a files and link, linking is very fast; if I give the same .o files on
the command line, the machine chugs for a long time and then a smaller
result comes out.
I have not tried -flto for myself yet, but what is maybe happening here
is that if lto skips archives, when you try to link a.o and
libwhatever.a through lto with -fwhole-program, lto takes only a.o and
then yes, var is optimized away, because there is no link-chain from
main to it (remember we passed -fwhole-program to it).
And then ld sees main, but does not see var.
What is ranted here is completely untested, but maybe somehow related to
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41376
yes, either use gold, or link all .o files directly.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#578831: link failure with LTO: ???invalid DSO for symbol `pthread_cancel@@GLIBC_2.0' definition???
On Sun, Aug 08, 2010 at 12:24:58PM +0200, Steinar H. Gunderson wrote:
> On Sun, Aug 08, 2010 at 02:20:38PM +0400, Kirill Smelkov wrote:
> > No thanks, I can't afford NDA for myself.
>
> I wouldn't require an NDA to be signed -- it would be on honor code. :-)
> (It's not a commercial product, but I wouldn't want the source code
> distributed regardless, especially as I'd have to confer with the 4-5 others
> who has code rights.)
Still it would be an agreement where one party promises not to
disclose...
On Sun, Aug 08, 2010 at 12:46:54PM +0200, Steinar H. Gunderson wrote:
> On Sun, Aug 08, 2010 at 12:24:58PM +0200, Steinar H. Gunderson wrote:
> >> Though I may suggest to try latest upstream binutils and gcc-4.5 to see
> >> whether it works there, and if not, try harder to still disentangle the
> >> testcase.
> > I'll give probably give it a shot, eventually.
>
> OK, I think I've spotted the problem -- it doesn't like that .a files
> reference variables in .o files.
>
> fugl:~/dev/lto> cat a.cpp
> int var;
> fugl:~/dev/lto> cat b.cpp
> #include
>
> extern int var;
>
> int main(void)
> {
> printf("hello: %d\n", var);
> }
> fugl:~/dev/lto> g++-4.5 -flto -o a.o -c a.cpp
> fugl:~/dev/lto> g++-4.5 -flto -o b.o -c b.cpp
> fugl:~/dev/lto> ar rc libwhatever.a b.o
> fugl:~/dev/lto> ranlib libwhatever.a
> fugl:~/dev/lto> g++-4.5 -flto -fwhole-program -Wl,--gc-sections -o prog
> -Wl,--start-group a.o libwhatever.a -Wl,--end-group
> libwhatever.a(b.o): In function `main':
> b.cpp:(.text+0xa): undefined reference to `var'
> collect2: ld returned 1 exit status
>
> If I put a.o into an .a file, it works. The order of a.o and libwhatever.a
> doess not matter. Removing -fwhole-program fixes it.
>
> This is a bug, right?
On Sun, Aug 08, 2010 at 12:59:51PM +0200, Steinar H. Gunderson wrote:
> On Sun, Aug 08, 2010 at 12:46:54PM +0200, Steinar H. Gunderson wrote:
> > OK, I think I've spotted the problem -- it doesn't like that .a files
> > reference variables in .o files.
>
> Actually, .a files are not recompiled for LTO at all. If I stick everything
> in .a files and link, linking is very fast; if I give the same .o files on
> the command line, the machine chugs for a long time and then a smaller
> result comes out.
I have not tried -flto for myself yet, but what is maybe happening here
is that if lto skips archives, when you try to link a.o and
libwhatever.a through lto with -fwhole-program, lto takes only a.o and
then yes, var is optimized away, because there is no link-chain from
main to it (remember we passed -fwhole-program to it).
And then ld sees main, but does not see var.
What is ranted here is completely untested, but maybe somehow related to
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41376
> -frepo still makes everything crash and burn, but I guess that's for a
> separate bug.
Probably yes. All those new gc features need time to get into shape...
Thanks,
Kirill
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#578831: link failure with LTO: ???invalid DSO for symbol `pthread_cancel@@GLIBC_2.0' definition???
On Sun, Aug 08, 2010 at 12:46:54PM +0200, Steinar H. Gunderson wrote: > OK, I think I've spotted the problem -- it doesn't like that .a files > reference variables in .o files. Actually, .a files are not recompiled for LTO at all. If I stick everything in .a files and link, linking is very fast; if I give the same .o files on the command line, the machine chugs for a long time and then a smaller result comes out. -frepo still makes everything crash and burn, but I guess that's for a separate bug. /* Steinar */ -- Homepage: http://www.sesse.net/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#578831: link failure with LTO: ???invalid DSO for symbol `pthread_cancel@@GLIBC_2.0' definition???
On Sun, Aug 08, 2010 at 12:24:58PM +0200, Steinar H. Gunderson wrote:
>> Though I may suggest to try latest upstream binutils and gcc-4.5 to see
>> whether it works there, and if not, try harder to still disentangle the
>> testcase.
> I'll give probably give it a shot, eventually.
OK, I think I've spotted the problem -- it doesn't like that .a files
reference variables in .o files.
fugl:~/dev/lto> cat a.cpp
int var;
fugl:~/dev/lto> cat b.cpp
#include
extern int var;
int main(void)
{
printf("hello: %d\n", var);
}
fugl:~/dev/lto> g++-4.5 -flto -o a.o -c a.cpp
fugl:~/dev/lto> g++-4.5 -flto -o b.o -c b.cpp
fugl:~/dev/lto> ar rc libwhatever.a b.o
fugl:~/dev/lto> ranlib libwhatever.a
fugl:~/dev/lto> g++-4.5 -flto -fwhole-program -Wl,--gc-sections -o prog
-Wl,--start-group a.o libwhatever.a -Wl,--end-group
libwhatever.a(b.o): In function `main':
b.cpp:(.text+0xa): undefined reference to `var'
collect2: ld returned 1 exit status
If I put a.o into an .a file, it works. The order of a.o and libwhatever.a
doess not matter. Removing -fwhole-program fixes it.
This is a bug, right?
/* Steinar */
--
Homepage: http://www.sesse.net/
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#578831: link failure with LTO: ???invalid DSO for symbol `pthread_cancel@@GLIBC_2.0' definition???
On Sun, Aug 08, 2010 at 02:20:38PM +0400, Kirill Smelkov wrote: > Just a note - if your program uses pthread you should pass -pthread > explicitly, even if some other library you link to uses pthread, because > with -Wl,-no-add-needed (which is the default in Fedora, and may be some > time in Debian too) you'll get link errors. > > http://fedoraproject.org/wiki/UnderstandingDSOLinkChange Thanks for the heads-up. >> I can give you a test case, but I'm afraid I cannot make it public. (Also, >> it's pretty hard to disentangle, I'm afraid.) Let me know if it would be >> helpful to you. > No thanks, I can't afford NDA for myself. I wouldn't require an NDA to be signed -- it would be on honor code. :-) (It's not a commercial product, but I wouldn't want the source code distributed regardless, especially as I'd have to confer with the 4-5 others who has code rights.) > Though I may suggest to try latest upstream binutils and gcc-4.5 to see > whether it works there, and if not, try harder to still disentangle the > testcase. I'll give probably give it a shot, eventually. /* Steinar */ -- Homepage: http://www.sesse.net/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#578831: link failure with LTO: ???invalid DSO for symbol `pthread_cancel@@GLIBC_2.0' definition???
On Sun, Aug 08, 2010 at 11:55:28AM +0200, Steinar H. Gunderson wrote: > On Sun, Aug 08, 2010 at 01:47:09PM +0400, Kirill Smelkov wrote: > > The fix Matthias reffered to, is that you no longer need to pass -pthread > > explicitly if your program does not use pthreads. Please try it out -- > > it should not complain about pthread_cancel. > > Well, my program uses pthreads, so it's not a relevant fix. In any case, good > that it's fixed. I see, thanks. I asked because your original sympthom (about pthread_cancel) was very similiar to mine. Just a note - if your program uses pthread you should pass -pthread explicitly, even if some other library you link to uses pthread, because with -Wl,-no-add-needed (which is the default in Fedora, and may be some time in Debian too) you'll get link errors. http://fedoraproject.org/wiki/UnderstandingDSOLinkChange > > As to -flto -- I can't say, but could you please provide self-contained > > testcase, preferably minimized, so we could try it out by ourselves too. > > I can give you a test case, but I'm afraid I cannot make it public. (Also, > it's pretty hard to disentangle, I'm afraid.) Let me know if it would be > helpful to you. No thanks, I can't afford NDA for myself. Though I may suggest to try latest upstream binutils and gcc-4.5 to see whether it works there, and if not, try harder to still disentangle the testcase. Thanks, Kirill -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#578831: link failure with LTO: “invalid DSO for symbol `pthread_cancel@@GLIBC_2.0' definition”
On Sun, Aug 08, 2010 at 01:47:09PM +0400, Kirill Smelkov wrote: > The fix Matthias reffered to, is that you no longer need to pass -pthread > explicitly if your program does not use pthreads. Please try it out -- > it should not complain about pthread_cancel. Well, my program uses pthreads, so it's not a relevant fix. In any case, good that it's fixed. > As to -flto -- I can't say, but could you please provide self-contained > testcase, preferably minimized, so we could try it out by ourselves too. I can give you a test case, but I'm afraid I cannot make it public. (Also, it's pretty hard to disentangle, I'm afraid.) Let me know if it would be helpful to you. /* Steinar */ -- Homepage: http://www.sesse.net/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#578831: link failure with LTO: “invalid DSO for symbol `pthread_cancel@@GLIBC_2.0' definition”
On Sat, Aug 07, 2010 at 10:08:27PM +0200, Steinar H. Gunderson wrote: > On Sat, Aug 07, 2010 at 09:46:31PM +0200, Matthias Klose wrote: > > fixed in binutils 2.20.1-13 (and in binutils from experimental). > > I'm afraid it's not: > > fugl:~/dev/tehintro> ld -v > GNU ld (GNU Binutils for Debian) 2.20.51-system.20100710 > fugl:~/dev/tehintro> make > Generating dependencies > Warning: waveform_asm.cpp not found > g++-4.5 -o intro script/engine.o script/progressbar.o mumps/mumps_glx.o > engine/fbo_rtt.o mumps/XF86VMode.o script.o -flto -pthread -Wall -Os > -fno-exceptions -felide-constructors -fstrict-aliasing -fno-rtti > -fno-keep-static-consts -fsingle-precision-constant -ffast-math > -fno-threadsafe-statics -pthread -flto -fomit-frame-pointer -fconserve-space > -ffunction-sections -fdata-sections -march=pentium3 -mtune=generic -msse > -mfpmath=sse -ftree-vectorize -I/usr/include/freetype2 -I. -DUSE_BSB_DATA > -DUSE_LPC=1 -DASM_WAVEFORMS -fwhole-program -fno-exceptions -Wl,--gc-sections > -lGL -lGLU -L/usr/X11R6/lib -lXext -lX11 -lfreetype -lz -Wl,--start-group > engine/engine.a texgen/texgen.a meshgen/meshgen.a common/common.a > effects/effects.a script/script.a sanestation/libsanestation.a -Wl,--end-group > script/script.a(curve.o): In function `_ZN6script5Curve13make_tangentsEv': > curve.cpp:(.text._ZN6script5Curve13make_tangentsEv+0x3f2): undefined > reference to `_ZN6script6engine13get_num_paramENS_5Curve8knottypeE' > script/script.a(curve.o): In function `_ZN6script5Curve9get_valueEfPf': > curve.cpp:(.text._ZN6script5Curve9get_valueEfPf+0x226): undefined reference > to `_ZN6script6engine7targetsE' > curve.cpp:(.text._ZN6script5Curve9get_valueEfPf+0x236): undefined reference > to `_ZN6script6engine8texturesE' > curve.cpp:(.text._ZN6script5Curve9get_valueEfPf+0x262): undefined reference > to `_ZN6script6engine6meshesE' > curve.cpp:(.text._ZN6script5Curve9get_valueEfPf+0x28b): undefined reference > to `_ZN6script6engine9materialsE' > curve.cpp:(.text._ZN6script5Curve9get_valueEfPf+0x2a1): undefined reference > to `_ZN6script6engine13get_num_paramENS_5Curve8knottypeE' > collect2: ld returned 1 exit status > make: *** [intro] Error 1 > > IOW, exactly zero change for me. :-/ The fix Matthias reffered to, is that you no longer need to pass -pthread explicitly if your program does not use pthreads. Please try it out -- it should not complain about pthread_cancel. As to -flto -- I can't say, but could you please provide self-contained testcase, preferably minimized, so we could try it out by ourselves too. Thanks, Kirill -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#578831: link failure with LTO: “invalid DSO for symbol `pthread_cancel@@GLIBC_2.0' definition”
reopen 578831 thanks On Sat, Aug 07, 2010 at 09:46:31PM +0200, Matthias Klose wrote: > fixed in binutils 2.20.1-13 (and in binutils from experimental). I'm afraid it's not: fugl:~/dev/tehintro> ld -v GNU ld (GNU Binutils for Debian) 2.20.51-system.20100710 fugl:~/dev/tehintro> make Generating dependencies Warning: waveform_asm.cpp not found g++-4.5 -o intro script/engine.o script/progressbar.o mumps/mumps_glx.o engine/fbo_rtt.o mumps/XF86VMode.o script.o -flto -pthread -Wall -Os -fno-exceptions -felide-constructors -fstrict-aliasing -fno-rtti -fno-keep-static-consts -fsingle-precision-constant -ffast-math -fno-threadsafe-statics -pthread -flto -fomit-frame-pointer -fconserve-space -ffunction-sections -fdata-sections -march=pentium3 -mtune=generic -msse -mfpmath=sse -ftree-vectorize -I/usr/include/freetype2 -I. -DUSE_BSB_DATA -DUSE_LPC=1 -DASM_WAVEFORMS -fwhole-program -fno-exceptions -Wl,--gc-sections -lGL -lGLU -L/usr/X11R6/lib -lXext -lX11 -lfreetype -lz -Wl,--start-group engine/engine.a texgen/texgen.a meshgen/meshgen.a common/common.a effects/effects.a script/script.a sanestation/libsanestation.a -Wl,--end-group script/script.a(curve.o): In function `_ZN6script5Curve13make_tangentsEv': curve.cpp:(.text._ZN6script5Curve13make_tangentsEv+0x3f2): undefined reference to `_ZN6script6engine13get_num_paramENS_5Curve8knottypeE' script/script.a(curve.o): In function `_ZN6script5Curve9get_valueEfPf': curve.cpp:(.text._ZN6script5Curve9get_valueEfPf+0x226): undefined reference to `_ZN6script6engine7targetsE' curve.cpp:(.text._ZN6script5Curve9get_valueEfPf+0x236): undefined reference to `_ZN6script6engine8texturesE' curve.cpp:(.text._ZN6script5Curve9get_valueEfPf+0x262): undefined reference to `_ZN6script6engine6meshesE' curve.cpp:(.text._ZN6script5Curve9get_valueEfPf+0x28b): undefined reference to `_ZN6script6engine9materialsE' curve.cpp:(.text._ZN6script5Curve9get_valueEfPf+0x2a1): undefined reference to `_ZN6script6engine13get_num_paramENS_5Curve8knottypeE' collect2: ld returned 1 exit status make: *** [intro] Error 1 IOW, exactly zero change for me. :-/ /* Steinar */ -- Homepage: http://www.sesse.net/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#578831: link failure with LTO: “invalid DSO for symbol `pthread_cancel@@GLIBC_2.0' definition”
On Tue, Jun 22, 2010 at 02:53:24PM +0200, Matthias Klose wrote: > please recheck with the current g++-4.5 in experimental. -lpthread > shouldn't be used directly, but pass -pthread to both CXXFLAGS and > LDFLAGS. Pretty much no change. With CXXFLAGS including -pthread and LDFLAGS including -pthread -flto -fwhole-program: script/script.a(curve.o): In function `_ZN6script5Curve13make_tangentsEv': curve.cpp:(.text._ZN6script5Curve13make_tangentsEv+0x3f2): undefined reference to `_ZN6script6engine13get_num_paramENS_5Curve8knottypeE' script/script.a(curve.o): In function `_ZN6script5Curve9get_valueEfPf': curve.cpp:(.text._ZN6script5Curve9get_valueEfPf+0x226): undefined reference to `_ZN6script6engine7targetsE' curve.cpp:(.text._ZN6script5Curve9get_valueEfPf+0x236): undefined reference to `_ZN6script6engine8texturesE' curve.cpp:(.text._ZN6script5Curve9get_valueEfPf+0x262): undefined reference to `_ZN6script6engine6meshesE' curve.cpp:(.text._ZN6script5Curve9get_valueEfPf+0x28b): undefined reference to `_ZN6script6engine9materialsE' curve.cpp:(.text._ZN6script5Curve9get_valueEfPf+0x2a1): undefined reference to `_ZN6script6engine13get_num_paramENS_5Curve8knottypeE' collect2: ld returned 1 exit status make: *** [intro] Error 1 Without -fwhole-program in LDFLAGS it links, as before. With -frepo in the mix, it's chaos as usual, with tons and tons of messages like script/parser.o: In function `_ZNSt8_Rb_treeISsSt4pairIKSsN6script6parser4meshEESt10_Select1stIS5_ESt4lessISsESaIS5_EE4findERS1_.clone.30': parser.cpp:(.text._ZNSt8_Rb_treeISsSt4pairIKSsN6script6parser4meshEESt10_Select1stIS5_ESt4lessISsESaIS5_EE4findERS1_.clone.30+0x38): undefined reference to `bool std::operator< , std::allocator >(std::basic_string, std::allocator > const&, std::basic_string, std::allocator > const&)' and other mising templates. /* Steinar */ -- Homepage: http://www.sesse.net/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#578831: link failure with LTO: “invalid DSO for symbol `pthread_cancel@@GLIBC_2.0' definition”
On 28.04.2010 10:37, Vincent Danjean wrote: On 27/04/2010 01:26, Matthias Klose wrote: On 23.04.2010 10:22, Steinar H. Gunderson wrote: On Fri, Apr 23, 2010 at 08:41:53AM +0200, Vincent Danjean wrote: Please, look at #577961. It seems to me that this is the same bug (and now, I think the bug belong to gcc-4.5) OK, adding -lpthread makes the error go away. please make sure that *all* flags (except preprocessor flags) passed to cc1 are also passed to lto1. For common build systems, this does mean passing $(CFLAGS) to the link command. I do not know for #578831 but, for #577961 the application must not be required to link to -lpthread (and lto1 is not used). please recheck with the current g++-4.5 in experimental. -lpthread shouldn't be used directly, but pass -pthread to both CXXFLAGS and LDFLAGS. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#577961: Bug#578831: link failure with LTO: “invalid DSO for symbol `pthread_cancel@@GLIBC_2.0' definition”
On 27/04/2010 01:26, Matthias Klose wrote: > On 23.04.2010 10:22, Steinar H. Gunderson wrote: >> On Fri, Apr 23, 2010 at 08:41:53AM +0200, Vincent Danjean wrote: >>> Please, look at #577961. It seems to me that this is the same bug (and >>> now, I think the bug belong to gcc-4.5) >> >> OK, adding -lpthread makes the error go away. > > please make sure that *all* flags (except preprocessor flags) passed to > cc1 are also passed to lto1. For common build systems, this does mean > passing $(CFLAGS) to the link command. I do not know for #578831 but, for #577961 the application must not be required to link to -lpthread (and lto1 is not used). Regards, Vincent > Matthias -- Vincent Danjean GPG key ID 0x9D025E87 vdanj...@debian.org GPG key fingerprint: FC95 08A6 854D DB48 4B9A 8A94 0BF7 7867 9D02 5E87 Unofficial packages: http://moais.imag.fr/membres/vincent.danjean/deb.html APT repo: deb http://perso.debian.org/~vdanjean/debian unstable main -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#578831: link failure with LTO: “invalid DSO for symbol `pthread_cancel@@GLIBC_2.0' definition”
On Tue, Apr 27, 2010 at 01:26:00AM +0200, Matthias Klose wrote: > please make sure that *all* flags (except preprocessor flags) passed > to cc1 are also passed to lto1. For common build systems, this does > mean passing $(CFLAGS) to the link command. OK. This made no change at all to the undefined references with -fwhole-program, though. /* Steinar */ -- Homepage: http://www.sesse.net/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#578831: link failure with LTO: “invalid DSO for symbol `pthread_cancel@@GLIBC_2.0' definition”
On 23.04.2010 10:22, Steinar H. Gunderson wrote: On Fri, Apr 23, 2010 at 08:41:53AM +0200, Vincent Danjean wrote: Please, look at #577961. It seems to me that this is the same bug (and now, I think the bug belong to gcc-4.5) OK, adding -lpthread makes the error go away. please make sure that *all* flags (except preprocessor flags) passed to cc1 are also passed to lto1. For common build systems, this does mean passing $(CFLAGS) to the link command. Matthias -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#578831: link failure with LTO: “invalid DSO for symbol `pthread_cancel@@GLIBC_2.0' definition”
On Fri, Apr 23, 2010 at 08:41:53AM +0200, Vincent Danjean wrote: > Please, look at #577961. It seems to me that this is the same bug (and > now, I think the bug belong to gcc-4.5) OK, adding -lpthread makes the error go away. Now let me try adding -fwhole-program to the link (which is the point of the LTO exercise :-) ): g++-4.5 -o intro script/engine.o script/progressbar.o mumps/mumps_glx.o engine/fbo_rtt.o mumps/XF86VMode.o script.o -flto -lpthread -fwhole-program -fno-exceptions -Wl,--gc-sections -lGL -lGLU -L/usr/X11R6/lib -lXext -lX11 -lfreetype -lz -Wl,--start-group engine/engine.a texgen/texgen.a meshgen/meshgen.a common/common.a effects/effects.a script/script.a sanestation/libsanestation.a -Wl,--end-group script/script.a(curve.o): In function `_ZN6script5Curve13make_tangentsEv': curve.cpp:(.text._ZN6script5Curve13make_tangentsEv+0x391): undefined reference to `_ZN6script6engine13get_num_paramENS_5Curve8knottypeE' script/script.a(curve.o): In function `_ZN6script5Curve9get_valueEfPf': curve.cpp:(.text._ZN6script5Curve9get_valueEfPf+0x1d6): undefined reference to `_ZN6script6engine7targetsE' curve.cpp:(.text._ZN6script5Curve9get_valueEfPf+0x1e6): undefined reference to `_ZN6script6engine8texturesE' curve.cpp:(.text._ZN6script5Curve9get_valueEfPf+0x214): undefined reference to `_ZN6script6engine6meshesE' curve.cpp:(.text._ZN6script5Curve9get_valueEfPf+0x23f): undefined reference to `_ZN6script6engine9materialsE' curve.cpp:(.text._ZN6script5Curve9get_valueEfPf+0x253): undefined reference to `_ZN6script6engine13get_num_paramENS_5Curve8knottypeE' collect2: ld returned 1 exit status make: *** [intro] Error 1 It's actually a bit curious the missing symbols don't even get demangled. /* Steinar */ -- Homepage: http://www.sesse.net/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#578831: link failure with LTO: “invalid DSO for symbol `pthread_cancel@@GLIBC_2.0' definition”
On 23/04/2010 00:54, Steinar H. Gunderson wrote: > On Fri, Apr 23, 2010 at 12:19:41AM +0200, Steinar H. Gunderson wrote: >> It works with no errors if I remove -flto. (There's lots of other chaos if I >> throw -frepo into the mix, but I'll keep that for a later bug. :-) ) > > Actually that's wrong -- I did a full recompile, and now it fails even > without -flto. Same error. > > /* Steinar */ Please, look at #577961. It seems to me that this is the same bug (and now, I think the bug belong to gcc-4.5) Regards, Vincent -- Vincent Danjean GPG key ID 0x9D025E87 vdanj...@debian.org GPG key fingerprint: FC95 08A6 854D DB48 4B9A 8A94 0BF7 7867 9D02 5E87 Unofficial packages: http://moais.imag.fr/membres/vincent.danjean/deb.html APT repo: deb http://perso.debian.org/~vdanjean/debian unstable main -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#578831: link failure with LTO: “invalid DSO for symbol `pthread_cancel@@GLIBC_2.0' definition”
On Fri, Apr 23, 2010 at 12:19:41AM +0200, Steinar H. Gunderson wrote: > It works with no errors if I remove -flto. (There's lots of other chaos if I > throw -frepo into the mix, but I'll keep that for a later bug. :-) ) Actually that's wrong -- I did a full recompile, and now it fails even without -flto. Same error. /* Steinar */ -- Homepage: http://www.sesse.net/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#578831: link failure with LTO: “invalid DSO for symbol `pthread_cancel@@GLIBC_2.0' definition”
Severity: normal Package: gcc-4.5 Version: 4.5.0-1 Hi, I'm trying to link a project with g++-4.5 and LTO: $ g++-4.5 -flto -fno-exceptions -Wl,--gc-sections -lGL -lGLU -L/usr/X11R6/lib -lXext -lX11 -lfreetype -lz -o parser script/parser.o common/common.a texgen/texgen.a meshgen/meshgen.a texgen/texturescript.o meshgen/meshscript.o /usr/bin/ld: Ñ: invalid DSO for symbol `pthread_cancel@@GLIBC_2.0' definition /lib/libpthread.so.0: could not read symbols: Bad value collect2: ld returned 1 exit status It works with no errors if I remove -flto. (There's lots of other chaos if I throw -frepo into the mix, but I'll keep that for a later bug. :-) ) Unfortunately these sources are private, so I cannot post them to the bug. I'd be happy providing a tarball to the GCC Debian maintainers or upstream, though, provided that they are not made public. /* Steinar */ -- Chief, Tech:Server http://www.sesse.net/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
