Declaring a global variable that ends up in a shared library, declaring it as extern from a main program and linking/using the shared library results in 2 different variables. GNU ld version 2.9.1 (with BFD 2.9.1.0.24) A demo: begin 666 demo.zip M4$L#!!0````(``^%=2DJ91@@T0```)@!```%`!``8G5I;&156`P``18;.OX5 M&SH```$`I9!-;L)`#(7W.84/4"<**HA-%@5&524$"(%8HHGY&^H91YE$B-LS M0VA5MG1EOT^VWK.)`"?CQ;KH#P>`A\77..CM1(W6G[%9*C5;+3]F*\!Y#G@$ MW&AF0(+&5KV4DJSU=58:E_$.T)]TO0]5@$UIKV$D]0*H`$?^:DMA\]@+D"FA M?WCG:;>_X3>D@+<_WA&HKN!%UPY)K!4':-^CB]5LC@Y9I/)%[U>?6_ND#ZVC MQHCS1?Y2QFA?5[HY(1OW760A\1_XT!(/Z8X)#YEVD.]_2VY02P,$%`````@` MUH)J*5:=I1_;````3P$```8`$`!T;7`Q+F-56`P``18;.E21##KVEP$`58Y- M2P,Q$$#/YE>,+97LLMC:8]<*A2H('GI7#^EFMAN(B>1C61#_NS.A1;V$R7O) M2^;&=39KA/N8M/&WPX.8_T76')D)G!(&!\8EZ+UOA>#I0QDG53AU#2UC):!X M!BW-W:`"U&Q>WUOQ163T1D/,1UE1`,[3U;*&./AL26&I0_*PAGK)O1[D-:&J M\"W<<?@ST#.]G/'SFR*4U@%CW,!J6DR%C,IFA(5^<[-&9A?-R:&N;D@UG&O/ M[5+=PIK__AL^J!B1KY9S:"/^TT^[YY?'_44'3#DXN:+-M_@!4$L#!!0````( M`-2":BGX_P@W<````(`````&`!``=&UP,BYC55@,``$6&SI0D0PZ]I<!`!V* MP0J#,!!$[_L5B\62@(AX3&J_I!?;C79!-L48$<1_[^IAX,V\N;%\IDP!'VDA MCO7W"<"RX!"C!U@C$Z;\-B=8W`%/@1VV7O$WZW,PA1[<M?=$L\-F*[>KKOV4 M@\.27E)4)DOB40+9N[I*8ST<\`=02P,$%`````@`%X5U*:IT825$````5P`` M``<`$`!T;7`N;W5T55@,``T6&SH-%ALZ```!`"LN3;)22,O/5TA,22FR4C"H M,#$P,#0Q-K$`"Y8EYI2F6BD8<>4F9N8AU*46%X.46AB86%H8&B!4*AARN3EZ M^KBZ<`$`4$L!`A4#%`````@`#X5U*2IE&"#1````F`$```4`#````````0`` M0/^!`````&)U:6QD55@(``$6&SK^%1LZ4$L!`A4#%`````@`UH)J*5:=I1_; M````3P$```8`#````````0``0+:!!`$``'1M<#$N8U58"``!%ALZ5)$,.E!+ M`0(5`Q0````(`-2":BGX_P@W<````(`````&``P```````$``$"V@1,"``!T M;7`R+F-56`@``18;.E"1##I02P$"%0,4````"``7A74IJG1A)40```!7```` M!P`,```````!``!`MH&W`@``=&UP+F]U=%58"``-%ALZ#18;.E!+!08````` .!``$```!```P`P`````` ` end This seems too obvious a bug to me to not see another bug report, but once I built and replaced the 'ld' with a newer version "GNU ld version 2.10.1 (with BFD 2.10.1)" then it works. But I'm suspicious about changing just /usr/bin/ld into RedHat 6.1. Perhaps its a dangerous move. -- brandon
Perhaps I've alienated the Linux gurus with the uuencoded posting, so here's the simple version, assuming that tmp1.c, tmp2.c, and tmp.h are put into /tmp: ------------- build script ----------- #!/bin/sh cc -fPIC -D_REENTRANT -O1 -g -Wall -c tmp2.c /usr/bin/ld -shared -o libmytmp.so -Bsymbolic tmp2.o cc -fPIC -D_REENTRANT -O1 -g -Wall -c tmp1.c cc -fPIC -D_REENTRANT -O1 -g -Wall -Wl,-rpath-link=/tmp -Wl,-rpath=/tmp -o tmp tmp1.o -L/tmp -lmytmp ----------- tmp1.c --------------------- #include <stdio.h> #include "tmp.h" int main(argc,argv) int argc; char *argv[]; { void sub(); sub(); /*sets foo to 2*/ if (!foo) foo = 1; printf("%d\n",foo); if (foo == 2) { printf("Passed\n"); return(0); } else { printf("FAILED\n"); return(1); } } --------------------- tmp2.c --------------- #define DO_DEFINES #include "tmp.h" void sub(void) { foo = 2; } ------------------- tmp.h ------------------- #ifdef DO_DEFINES int foo; #else extern int foo; #endif
IMHO you just should upgrade to ld which works for you. I don't have 6.1 installed anywhere, I've checked 6.2 and this passes there (binutils-2.9.5.0.22-6), so you could e.g. upgrade to that binutils rpm. BTW: You should use cc -shared, not ld directly when linking shared libraries.
I agree, we should use 6.2, but it was still under discussion for other reasons. Wanted to make sure I wasn't missing something obvious -- seemed too blatant a bug. You just led me to the answer, though, thanks! Using ld or cc to link, and dumping the -Bsymbolic makes it work. I would have guessed the opposite from the man page, but it should really have NO effect, since I only have a definition within the shared library. I'll mark this as closed.