Re: alberta on powerpc: R_PPC_REL24 relocation out of range
On 05/22/2015 12:07 PM, Ansgar Burchardt wrote: Maybe there was a bug in the (non-standard) clang toolchain when alberta_3.0.1-1 was built on powerpc which has since been fixed? I have requested a binNMU for alberta and hope this will make the issue go away (#786500). As a follow-up: this seems to have worked. The linker no longer complains when executing a program linked against libalberta_utilities. Ansgar -- To UNSUBSCRIBE, email to debian-powerpc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/5564746a.4080...@debian.org
Re: alberta on powerpc: R_PPC_REL24 relocation out of range
On 22.05.2015 16:58, Ansgar Burchardt wrote: Hi, while looking at a test failure for dune-grid[1] on powerpc I encountered this issue: gmshtest: error while loading shared libraries: /usr/lib/powerpc-linux-gnu/libalberta_utilities.so.4: R_PPC_REL24 relocation at 0x0fcde034 for symbol `time' out of range The internet suggests this happens when -fPIC is not used when building the shared library, but this flag is set, cf. the build log for alberta[2]. It looks like not all files are always compiled with -fPIC though. Have you double-checked that all object files which end up linked into libalberta_utilities.so.4 are compiled with -fPIC? Note that I had to use clang to build alberta as gcc misses a particular feature (constant folding for long double[3]). It might be interesting to see if the problem happens with gcc as well if possible, e.g. disabling any code using long double. Another possibility might be an issue in binutils. -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Mesa and X developer -- To UNSUBSCRIBE, email to debian-powerpc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/555ef15b.5040...@daenzer.net
alberta on powerpc: R_PPC_REL24 relocation out of range
Hi,
while looking at a test failure for dune-grid[1] on powerpc I encountered
this issue:
gmshtest: error while loading shared libraries:
/usr/lib/powerpc-linux-gnu/libalberta_utilities.so.4:
R_PPC_REL24 relocation at 0x0fcde034 for symbol `time' out of range
The internet suggests this happens when -fPIC is not used when building
the shared library, but this flag is set, cf. the build log for
alberta[2].
Note that I had to use clang to build alberta as gcc misses a particular
feature (constant folding for long double[3]).
The same problem didn't happen when building an older version of
dune-grid against an older version of alberta[4]. As even the trivial
problem
int main() { return 0; }
built with -lalberta_utilities fails with the same error, I think
dune-grid is not to blame. But the changes between alberta 3.0.0-3 and
3.0.1-1 are quite small and don't look related :/
Any idea what might be cause this problem?
Ansgar
[1]
https://buildd.debian.org/status/fetch.php?pkg=dune-gridarch=powerpcver=2.4~20150506gd3c1350-1stamp=1432250732
[2]
https://buildd.debian.org/status/fetch.php?pkg=albertaarch=powerpcver=3.0.1-1stamp=1406848636
[3] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26374
[4]
https://buildd.debian.org/status/fetch.php?pkg=dune-gridarch=powerpcver=2.3.1-1stamp=1403036577
--
To UNSUBSCRIBE, email to debian-powerpc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/87fv6p11su@deep-thought.43-1.org
Re: alberta on powerpc: R_PPC_REL24 relocation out of range
[ Please CC me in replies. ] On 05/22/2015 11:05 AM, Michel Dänzer wrote: On 22.05.2015 16:58, Ansgar Burchardt wrote: while looking at a test failure for dune-grid[1] on powerpc I encountered this issue: gmshtest: error while loading shared libraries: /usr/lib/powerpc-linux-gnu/libalberta_utilities.so.4: R_PPC_REL24 relocation at 0x0fcde034 for symbol `time' out of range The internet suggests this happens when -fPIC is not used when building the shared library, but this flag is set, cf. the build log for alberta[2]. It looks like not all files are always compiled with -fPIC though. Have you double-checked that all object files which end up linked into libalberta_utilities.so.4 are compiled with -fPIC? I think they are: libtool should build all files twice (w/o -fPIC for the static library and w/ -fPIC for the shared library). I also tried rebuilding the package just now on partch.d.o and it looks like this made the problematic relocation disappear. At least the output from readelf -a no longer contained any references to R_PPC_REL24. Maybe there was a bug in the (non-standard) clang toolchain when alberta_3.0.1-1 was built on powerpc which has since been fixed? I have requested a binNMU for alberta and hope this will make the issue go away (#786500). Ansgar -- To UNSUBSCRIBE, email to debian-powerpc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/555effc5.7050...@debian.org
Re: R_PPC_REL24 relocation ... out of range
Sex, 18Jun2010, brian m. carlson sand...@crustytoothpaste.net escreveu:, brian m. carlson sand...@crustytoothpaste.net escreveu: On Thu, Jun 17, 2010 at 09:44:28PM -0300, Gunther Furtado wrote: Hi, After the latest update mplayer is giving me: mplayer: error while loading shared libraries: /usr/lib/libvpx.so.0: R_PPC_REL24 relocation at 0x48040a68 for symbol `memset' out of range It appears that some code in a shared library is not being built with -fPIC. That might work on i386, but it certainly will not on powerpc. If this is the Debian mplayer, you should file a bug report on the mplayer package and include the error you got. If it's not the Debian package, then you need to contact whomever you got it from and report it there. Yes, it is the debian package and I will report the bug as soon as I can. Thanks, -- brian m. carlson / brian with sandals: Houston, Texas, US +1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187 -- ...agora, só nos sobrou o futuro..., visto em www.manuchao.net Gunther Furtado Curitiba - Paraná - Brasil gunfurt...@gmail.com -- To UNSUBSCRIBE, email to debian-powerpc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100618063354.3bcb5...@papel.gfcm.net
Re: R_PPC_REL24 relocation ... out of range
Oi, 2010/6/18 Gunther Furtado gunfurt...@gmail.com: [...] Yes, it is the debian package and I will report the bug as soon as I can. Funny thing: the safe-upgrade I ran today fixed the problem without upgrading mplayer. If anyone is interested I'll show aptitude's log. Cheers, -- ...agora, só nos sobrou o futuro..., visto em www.manuchao.net Gunther Furtado Curitiba - Paraná - Brasil gunfurt...@gmail.com -- To UNSUBSCRIBE, email to debian-powerpc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlktimgpqid1s1chhvehaixsb_bwmubfpwyzm0cm...@mail.gmail.com
Re: R_PPC_REL24 relocation ... out of range
On Fre, 2010-06-18 at 10:25 -0300, Gunther Furtado wrote: 2010/6/18 Gunther Furtado gunfurt...@gmail.com: [...] Yes, it is the debian package and I will report the bug as soon as I can. Funny thing: the safe-upgrade I ran today fixed the problem without upgrading mplayer. If anyone is interested I'll show aptitude's log. It could just be luck, the problem could return later. BTW, I think the error indicates the problem is in /usr/lib/libvpx.so.0, or maybe a static library linked into it (static libraries are usually built without -fPIC). Either way it should be a bug in the libvpx0 package. Might have been #583765, but I suspect more likely the fix for that is just hiding the problem for now. (If you report the bug, a shared library with code built without -fPIC is a policy violation = severity 'serious') -- Earthling Michel Dänzer |http://www.vmware.com Libre software enthusiast | Debian, X and DRI developer -- To UNSUBSCRIBE, email to debian-powerpc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1276873782.1300.147.ca...@thor.local
Re: R_PPC_REL24 relocation ... out of range
2010/6/18 Michel Dänzer daen...@debian.org: On Fre, 2010-06-18 at 10:25 -0300, Gunther Furtado wrote: 2010/6/18 Gunther Furtado gunfurt...@gmail.com: [...] Yes, it is the debian package and I will report the bug as soon as I can. Funny thing: the safe-upgrade I ran today fixed the problem without upgrading mplayer. If anyone is interested I'll show aptitude's log. It could just be luck, the problem could return later. BTW, I think the error indicates the problem is in /usr/lib/libvpx.so.0, or maybe a static library linked into it (static libraries are usually built without -fPIC). Either way it should be a bug in the libvpx0 package. Might have been #583765, but I suspect more likely the fix for that is just hiding the problem for now. (If you report the bug, a shared library with code built without -fPIC is a policy violation = severity 'serious') I'll try. It could be tricky since I cannot reproduce it anymore. -- ...agora, só nos sobrou o futuro..., visto em www.manuchao.net Gunther Furtado Curitiba - Paraná - Brasil gunfurt...@gmail.com -- To UNSUBSCRIBE, email to debian-powerpc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlktilgb2tjpxrti5tlxzzadmscamszsvmhuphwk...@mail.gmail.com
R_PPC_REL24 relocation ... out of range
Hi, After the latest update mplayer is giving me: mplayer: error while loading shared libraries: /usr/lib/libvpx.so.0: R_PPC_REL24 relocation at 0x48040a68 for symbol `memset' out of range imac ppc 600MHz sid any hints? Cheers, Gunther -- ...agora, só nos sobrou o futuro..., visto em www.manuchao.net Gunther Furtado Curitiba - Paraná - Brasil gunfurt...@gmail.com -- To UNSUBSCRIBE, email to debian-powerpc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100617214428.11eb8...@papel.gfcm.net
Re: R_PPC_REL24 relocation ... out of range
On Thu, Jun 17, 2010 at 09:44:28PM -0300, Gunther Furtado wrote: Hi, After the latest update mplayer is giving me: mplayer: error while loading shared libraries: /usr/lib/libvpx.so.0: R_PPC_REL24 relocation at 0x48040a68 for symbol `memset' out of range It appears that some code in a shared library is not being built with -fPIC. That might work on i386, but it certainly will not on powerpc. If this is the Debian mplayer, you should file a bug report on the mplayer package and include the error you got. If it's not the Debian package, then you need to contact whomever you got it from and report it there. -- brian m. carlson / brian with sandals: Houston, Texas, US +1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187 signature.asc Description: Digital signature
Re: R_PPC_REL24 relocation out of range
hi does anyone know what the equivalent error message looks like on other archs? i am going to write up this problem and wanted to be able to catch web searches for the different forms of the error. -- [EMAIL PROTECTED] Brad Midgley
Re: R_PPC_REL24 relocation out of range
if the contents of a libfoo.a were created without -fPIC, then any .so created with -lfoo will have REL24 relocations and fail. but debian policy i have another question along these lines. why doesn't gcc fail when it's told to create a .so using objects that are not PIC? is it because it might possibly work? it would be a lot easier to track down a compilation failure than backtracking after a dlopen problem and the underlying problem wouldn't be ignored as much as it is now. -- [EMAIL PROTECTED] Brad Midgley
Re: R_PPC_REL24 relocation out of range
On Thu, Aug 02, 2001 at 12:22:38PM -0600, Bradley C. Midgley wrote: if the contents of a libfoo.a were created without -fPIC, then any .so created with -lfoo will have REL24 relocations and fail. but debian policy i have another question along these lines. why doesn't gcc fail when it's told to create a .so using objects that are not PIC? is it because it might possibly work? it would be a lot easier to track down a compilation failure than backtracking after a dlopen problem and the underlying problem wouldn't be ignored as much as it is now. On some architectures, it will work anyway; also, the shared object could be used for some other purpose besides dynamic linking (i think?). You've just got to know what you're doing. It can also be a little tricky to tell. -- Daniel Jacobowitz Carnegie Mellon University MontaVista Software Debian GNU/Linux Developer
Re: R_PPC_REL24 relocation out of range
On Thu, Aug 02, 2001 at 11:21:59AM -0700, Daniel Jacobowitz wrote: On Thu, Aug 02, 2001 at 12:22:38PM -0600, Bradley C. Midgley wrote: On some architectures, it will work anyway; also, the shared object could be used for some other purpose besides dynamic linking (i think?). You've just got to know what you're doing. It works, if you consider not actually sharing the shared object is working. =) On that other architecture, when a non-PIC shared object is loaded, the relocs are fixed in-place, i.e., the fixups are written to read-only pages that are normally shared between processes. Suddenly, you have code pages that a) just got paged in from disk, b) aren't shared, and c) have to be written to swap instead of just dropped and reread from the fs. It can also be a little tricky to tell. I think this is the main reason. dave...
Re: R_PPC_REL24 relocation out of range
Bastien Nocera wrote: Bradley C. Midgley wrote: what is the story with this error? i'm seeing it at dynamic-lib-loadtime in a project i build for work that has lots of dynamically loaded modules. in a web search i see mention of the problem popping up for people all over the place -- one of the first is a message from 1998 in which dan jacobowitz is suggesting that a sign extension is causing an overflow... how is it people are stepping around the problem? Check the archives, it's a libc6 bug, I posted a link to a fix. BenC still hasn't released a new version of the libc6 with the fix, and that simply sucks. http://sources.redhat.com/ml/libc-alpha/2001-06/msg00238.html like Gerd said, you can also compile with -fPIC to solve this problem... This is reversed. -fPIC is required for all code in a shared object. Any 'fix' in libc is really a workaround. -- Earthling Michel Dänzer (MrCooper)\ Debian GNU/Linux (powerpc) developer CS student, Free Software enthusiast \XFree86 and DRI project member
Re: R_PPC_REL24 relocation out of range
On Fri, Jul 27, 2001 at 05:48:24PM -0600, Bradley C. Midgley wrote: solved by creating another repository? No. Did it occur to you to look at what's there? -- G. Branden Robinson| Debian GNU/Linux | // // // / / [EMAIL PROTECTED] | EI 'AANIIGOO 'AHOOT'E http://people.debian.org/~branden/ | pgpAscLKmzZJw.pgp Description: PGP signature
Re: R_PPC_REL24 relocation out of range
daniel, Sure. But if you're using DynaLoader from 5.6.0, see the archives of debian-perl for your problem. Use current 5.6.1 packages from for those reading along, the thread is here: http://lists.debian.org/debian-perl-0105/msg00012.html unstable; DynaLoader contained non-PIC code. unless i'm mistaken, there's a fundamental conflict here. if the contents of a libfoo.a were created without -fPIC, then any .so created with -lfoo will have REL24 relocations and fail. but debian policy dictates that static libraries be built exactly this way: http://www.debian.org/doc/debian-policy/ch-files.html#s11.2 although upgrading perl avoided the REL24 relocations in one .so, i am now seeing the problem caused by bind-dev. do i send bug reports because this package is adhering to misguided policy? -- [EMAIL PROTECTED] Brad Midgley
Re: R_PPC_REL24 relocation out of range
On Fri, Jul 27, 2001 at 12:51:35AM -0600, Bradley C. Midgley wrote: daniel, Sure. But if you're using DynaLoader from 5.6.0, see the archives of debian-perl for your problem. Use current 5.6.1 packages from for those reading along, the thread is here: http://lists.debian.org/debian-perl-0105/msg00012.html unstable; DynaLoader contained non-PIC code. unless i'm mistaken, there's a fundamental conflict here. if the contents of a libfoo.a were created without -fPIC, then any .so created with -lfoo will have REL24 relocations and fail. but debian policy dictates that static libraries be built exactly this way: http://www.debian.org/doc/debian-policy/ch-files.html#s11.2 although upgrading perl avoided the REL24 relocations in one .so, i am now seeing the problem caused by bind-dev. do i send bug reports because this package is adhering to misguided policy? This may need to be discussed further. If a library is only provided statically, a PIC version needs to be provided or it can not be used for shared libraries. X has a similar issue. -- Daniel Jacobowitz Carnegie Mellon University MontaVista Software Debian GNU/Linux Developer
Re: R_PPC_REL24 relocation out of range
On Thu, Jul 26, 2001 at 11:55:35PM -0700, Daniel Jacobowitz wrote: This may need to be discussed further. If a library is only provided statically, a PIC version needs to be provided or it can not be used for shared libraries. X has a similar issue. I think I have this solved. See http://people.debian.org/~branden/woody/powerpc. -- G. Branden Robinson| If you wish to strive for peace of soul, Debian GNU/Linux | then believe; if you wish to be a [EMAIL PROTECTED] | devotee of truth, then inquire. http://people.debian.org/~branden/ | -- Friedrich Nietzsche pgpyiUmBTrj7n.pgp Description: PGP signature
Re: R_PPC_REL24 relocation out of range
solved by creating another repository? for now, i will rebuild the packages i need with gcc aliased to gcc -fPIC. fixing this for an entire multiplatform distro is going to be a mess. I think I have this solved. See http://people.debian.org/~branden/woody/powerpc. -- [EMAIL PROTECTED] Brad Midgley
Re: R_PPC_REL24 relocation out of range
On Wed, Jul 25, 2001 at 10:02:37PM -0600, Bradley C. Midgley wrote: Use 'readelf -r' to determine the various types of relocations in a shared object file. In a properly compiled PPC .so file, you it seems that -fPIC doesn't suppress REL24 type relocations: First, I'm not sure it's supposed to, but more importantly, R_PPC_REL32 and R_PPC_PLTREL24 are not R_PPC_REL24 relocations. -- Daniel Jacobowitz Carnegie Mellon University MontaVista Software Debian GNU/Linux Developer
Re: R_PPC_REL24 relocation out of range
Dan, thanks for weighing in. people at work are suggesting that this kind of problem shows that ppc isn't stable enough for real work but i want to show them it's not *representative* -- it's *anomalous* :) On Wed, 25 Jul 2001, Daniel Jacobowitz wrote: On Wed, Jul 25, 2001 at 10:02:37PM -0600, Bradley C. Midgley wrote: it seems that -fPIC doesn't suppress REL24 type relocations: First, I'm not sure it's supposed to is there another way i can tell the compiler that 24-bit relocations are likely to be out of range? i thought -fPIC did that but if it doesn't fit this purpose, please let me know. , but more importantly, R_PPC_REL32 and R_PPC_PLTREL24 are not R_PPC_REL24 relocations. i have to admit i don't know the difference. i only noticed that .o files didn't have any R_PPC_REL24 relocations but the .so generated from them doesn't have any R_PPC_PLTREL24 so i figured they were the same thing in different forms: [EMAIL PROTECTED]:~/cockpit/build/linuxgcc/scripting$ readelf -r PerlWrapper.o | grep getenv 0128 07612 R_PPC_PLTREL24 getenv + 0 [EMAIL PROTECTED]:~/cockpit/build/linuxgcc/scripting$ readelf -r ../modules/libscripting-1-0.so | grep getenv 000177b0 0850a R_PPC_REL24 getenv + 0 0003b57c 08515 R_PPC_JMP_SLOT getenv + 0 -- [EMAIL PROTECTED] Brad Midgley
Re: R_PPC_REL24 relocation out of range
On Thu, Jul 26, 2001 at 05:58:28PM -0600, Bradley C. Midgley wrote: Dan, thanks for weighing in. people at work are suggesting that this kind of problem shows that ppc isn't stable enough for real work but i want to show them it's not *representative* -- it's *anomalous* :) Actually, it shows me that your build scripts are not clean enough to handle a decent architecture. =) is there another way i can tell the compiler that 24-bit relocations are likely to be out of range? i thought -fPIC did that but if it doesn't fit this purpose, please let me know. i have to admit i don't know the difference. i only noticed that .o files didn't have any R_PPC_REL24 relocations but the .so generated from them doesn't have any R_PPC_PLTREL24 so i figured they were the same thing in different forms: The differences are subtle. In .so executables, all the symbol resolution is done at run time -- this is how it is possible to redefine malloc() in an application, and libc will use _that_ instead of it's internal malloc(). The mechanism to do this is the R_PPC_PLTREL24 reloc (which occurs in .o files, but gets converted to a R_PPC_JMP_SLOT in executables). This indicates to the final linker that the branch should always go through the PLT (procedure link table), in case the user wants to redefine the symbol. Note that it may go through the PLT for other reasons, i.e., if the symbol is resolved in a different shared object. However, unlike normal executables, when the linker makes a .so executable, it doesn't resolve external references (i.e., like getenv below) that are R_PPC_REL24 relocs into jumps to the PLT table, and thereby converting them to R_PPC_JMP_SLOT, which is a trampoline that will jump anywhere in the address space. It's most likely this way because the ABI tells the linker to be overly pedantic. But then, I've seen a lot of pedantry in the PowerPC toolchain -- many things are more strict than That Other Architecture, and for good reason. I don't suppose you could provide source code and build scripts? [EMAIL PROTECTED]:~/cockpit/build/linuxgcc/scripting$ readelf -r PerlWrapper.o | grep getenv 0128 07612 R_PPC_PLTREL24 getenv This is ok. [EMAIL PROTECTED]:~/cockpit/build/linuxgcc/scripting$ readelf -r ../modules/libscripting-1-0.so | grep getenv 000177b0 0850a R_PPC_REL24 getenv This is a problem. I doubt this reloc comes from PerlWrapper.o. dave...
Re: R_PPC_REL24 relocation out of range
i've found that the invocation of the shared-object creation line makes a difference. the original invocation, pulling DynaLoader.a explicitly has getenv in a REL24 relocation: [EMAIL PROTECTED]:~/cockpit/build/linuxgcc/scripting$ g++ -fpic -shared -o libscripting-1-0.so PerlScriptingDef.o PerlWrapper.o ScriptingModuleDef.o -rdynamic /usr/lib/perl/5.6.0/auto/DynaLoader/DynaLoader.a readelf -r libscripting-1-0.so | grep getenv 00016890 0840a R_PPC_REL24 getenv + 0 00038d9c 08415 R_PPC_JMP_SLOT getenv + 0 without naming DynaLoader.a, getenv has no R_PPC_REL24 relocation entry. [EMAIL PROTECTED]:~/cockpit/build/linuxgcc/scripting$ g++ -fpic -shared -o libscripting-1-0.so PerlScriptingDef.o PerlWrapper.o ScriptingModuleDef.o -rdynamic readelf -r libscripting-1-0.so | grep getenv 00036864 07915 R_PPC_JMP_SLOT getenv + 0 is it legal to invoke a .a when creating a .so? it seems to make the difference in creating a valid .so Actually, it shows me that your build scripts are not clean enough to handle a decent architecture. =) maybe that's it thanks -- [EMAIL PROTECTED] Brad Midgley
Re: R_PPC_REL24 relocation out of range
On Thu, Jul 26, 2001 at 07:09:51PM -0600, Bradley C. Midgley wrote: i've found that the invocation of the shared-object creation line makes a difference. the original invocation, pulling DynaLoader.a explicitly has getenv in a REL24 relocation: [EMAIL PROTECTED]:~/cockpit/build/linuxgcc/scripting$ g++ -fpic -shared -o libscripting-1-0.so PerlScriptingDef.o PerlWrapper.o ScriptingModuleDef.o -rdynamic /usr/lib/perl/5.6.0/auto/DynaLoader/DynaLoader.a readelf -r libscripting-1-0.so | grep getenv 00016890 0840a R_PPC_REL24 getenv + 0 00038d9c 08415 R_PPC_JMP_SLOT getenv + 0 without naming DynaLoader.a, getenv has no R_PPC_REL24 relocation entry. [EMAIL PROTECTED]:~/cockpit/build/linuxgcc/scripting$ g++ -fpic -shared -o libscripting-1-0.so PerlScriptingDef.o PerlWrapper.o ScriptingModuleDef.o -rdynamic readelf -r libscripting-1-0.so | grep getenv 00036864 07915 R_PPC_JMP_SLOT getenv + 0 is it legal to invoke a .a when creating a .so? it seems to make the difference in creating a valid .so Sure. But if you're using DynaLoader from 5.6.0, see the archives of debian-perl for your problem. Use current 5.6.1 packages from unstable; DynaLoader contained non-PIC code. (If you've got 5.6.1 installed, why on earth are you using 5.6.0's DynaLoader? I'm guessing you're actually running testing.) -- Daniel Jacobowitz Carnegie Mellon University MontaVista Software Debian GNU/Linux Developer
Re: R_PPC_REL24 relocation out of range
David
thanks for your reply
What version of gcc are you using? Older 2.95 versions are known
to have issues outputting R_PPC_REL24 relocs in PIC code.
2.95.4 (from -unstable)
Use 'readelf -r' to determine the various types of relocations in
a shared object file. In a properly compiled PPC .so file, you
it seems that -fPIC doesn't suppress REL24 type relocations:
$ make
g++ -D_LARGEFILE64_SOURCE -D_LARGEFILE_SOURCE -fPIC -DTL_PRINTDEBUG
-I/home/bmidgley/cockpit/build/linuxgcc-ppc/
-I/home/bmidgley/cockpit/packages/ -I/usr/lib/sigc++/include
-I/home/bmidgley/cockpit/packages/messaging/src
-I/home/bmidgley/cockpit/packages/multicast/src -I/usr/lib/perl/5.6.0/CORE
-I/usr/lib/gtkmm/include -I/usr/include -I/usr/include/gtk-1.2
-I/usr/include/glib-1.2 -I/usr/lib/glib/include -I/usr/X11R6/include
-I/usr/lib/sigc++/include -Wall -g -fPIC -c
/home/bmidgley/cockpit/packages/scripting/src/PerlWrapper.cpp -o
PerlWrapper.o
$ readelf -r PerlWrapper.o | head -20
Relocation section '.rela.text' at offset 0x62770 contains 139 entries:
OffsetInfo TypeSymbol's Value Symbol's Name
Addend
0071a R_PPC_REL32 .got2
+ 7fe0
0040 06e12 R_PPC_PLTREL24 Perl_newXS
+ 0
0060 0071a R_PPC_REL32 .got2
+ 7fd0
00d0 07212 R_PPC_PLTREL24 __t9allocator1ZPc
+ 0
00e4 07312 R_PPC_PLTREL24
__t6vector2ZPcZt9allocato + 0
00ec 06c12 R_PPC_PLTREL24 __throw
+ 0
00fc 07412 R_PPC_PLTREL24 _._t9allocator1ZPc
+ 0
0120 07512 R_PPC_PLTREL24
push_back__t6vector2ZPcZt + 0
0128 07612 R_PPC_PLTREL24 getenv
+ 0
0140 07712 R_PPC_PLTREL240004
__t12basic_string3ZcZt18s + 0
0160 07812 R_PPC_PLTREL24
__apl__t12basic_string3Zc + 0
0170 07912 R_PPC_PLTREL240004
c_str__Ct12basic_string3Z + 0
0184 07512 R_PPC_PLTREL24
push_back__t6vector2ZPcZt + 0
01b0 07712 R_PPC_PLTREL240004
__t12basic_string3ZcZt18s + 0
01e4 07a12 R_PPC_PLTREL24
__eq__H3ZcZt18string_char + 0
0200 07a12 R_PPC_PLTREL24
__eq__H3ZcZt18string_char + 0
0240 07512 R_PPC_PLTREL24
push_back__t6vector2ZPcZt + 0
$ gcc --version
2.95.4
$ dpkg -s gcc-2.95
Package: gcc-2.95
Status: install ok installed
Priority: standard
Section: devel
Installed-Size: 3152
Maintainer: Debian GCC maintainers debian-gcc@lists.debian.org
Source: gcc-2.95 (2.95.4.ds4-0.010703)
Version: 1:2.95.4-0.010703
Provides: c-compiler
Depends: gcc (= 1:2.95.3-2), libc6 (= 2.2.3-1), cpp-2.95 (= 1:2.95.4),
cpp-2.95 ( 1:2.95.5), binutils (= 2.11.90.0.1-1)
Recommends: libc-dev
Suggests: gcc-2.95-doc (= 1:2.95.4), task-devel-common
Conflicts: libc5-dev
Description: The GNU C compiler.
NOTE: This is not a final release, but taken from the CVS gcc-2_95-branch
(dated 20010522).
.
This is the GNU C compiler, a fairly portable optimizing compiler which
supports multiple languages. This package includes support for C, C++,
and Objective C.
$ dpkg -s gcc
Package: gcc
Status: install ok installed
Priority: standard
Section: devel
Installed-Size: 52
Maintainer: Debian GCC maintainers debian-gcc@lists.debian.org
Source: gcc-defaults (0.11)
Version: 2:2.95.4-4
Provides: c-compiler
Depends: cpp (= 2:2.95.4-4), gcc-2.95, cpp-2.95
Recommends: libc-dev
Suggests: task-c-dev
Description: The GNU C compiler.
The default GNU C compiler for Debian GNU/Linux systems.
.
This is currently version 2.95.4 for this architecture (powerpc).
--
[EMAIL PROTECTED]
Brad Midgley
Re: R_PPC_REL24 relocation out of range
On Sat, Jul 21, 2001 at 09:15:53AM -0600, Bradley C. Midgley wrote: this code works on x86 so i believe it's a ppc-specific problem. using -fPIC everywhere reduced the number of these errors but didn't eliminate them. (i may try rebuilding libc6 with the recommended patch to see if it helps) What version of gcc are you using? Older 2.95 versions are known to have issues outputting R_PPC_REL24 relocs in PIC code. Use 'readelf -r' to determine the various types of relocations in a shared object file. In a properly compiled PPC .so file, you shouldn't get R_PPC_REL24, because that kind of reloc only allows a 24 bit signed offset (+2 because instructions are aligned), thus +/- 32 MB. The binary and libraries are typically mapped at 0x1000 and 0x3000, so things like R_PPC_JMP_SLOT are used in .so code to jump from one library to another. It works on i386 because that architecture has 32 bit offsets. this thing i'm running probably really pushes everything. the memory footprint is about 50MB with almost everything loaded. The in-core size is not the problem itself, but probably triggers the problem. dave...
Re: R_PPC_REL24 relocation out of range
this code works on x86 so i believe it's a ppc-specific problem. using -fPIC everywhere reduced the number of these errors but didn't eliminate them. (i may try rebuilding libc6 with the recommended patch to see if it helps) these are modules that are being loaded manually using dlopen: dlopen(fullname.c_str(), RTLD_NOW ); and the dlerror() output looks like: R_PPC_REL24 relocation at 0x6ccdd774 for symbol `g_char_traits1ZcZt24__default_alloc_template2b1i0UiUi' out of range this thing i'm running probably really pushes everything. the memory footprint is about 50MB with almost everything loaded. On Thu, 19 Jul 2001, Michael Schmitz wrote: what is the story with this error? i'm seeing it at dynamic-lib-loadtime in a project i build for work that has lots of dynamically loaded modules. Post the errors. This may be due to undeclared symbols, or it may be because of improper use of varargs (gcc emits a bogus symbol to catch this but it only shows up at link time). Michael -- [EMAIL PROTECTED] Brad Midgley
Re: R_PPC_REL24 relocation out of range
this code works on x86 so i believe it's a ppc-specific problem. using -fPIC everywhere reduced the number of these errors but didn't eliminate them. (i may try rebuilding libc6 with the recommended patch to see if it helps) The symbol wasn't va_arg_type_violation so it's not what I suspected. Trying the patch to libc seems like a good idea here. Michael
Re: R_PPC_REL24 relocation out of range
Bradley C. Midgley wrote: what is the story with this error? i'm seeing it at dynamic-lib-loadtime in a project i build for work that has lots of dynamically loaded modules. You didn't compile stuff with -fPIC. Gerd -- Gerd Knorr [EMAIL PROTECTED]
Re: R_PPC_REL24 relocation out of range
what is the story with this error? i'm seeing it at dynamic-lib-loadtime in a project i build for work that has lots of dynamically loaded modules. Post the errors. This may be due to undeclared symbols, or it may be because of improper use of varargs (gcc emits a bogus symbol to catch this but it only shows up at link time). Michael
R_PPC_REL24 relocation out of range
what is the story with this error? i'm seeing it at dynamic-lib-loadtime in a project i build for work that has lots of dynamically loaded modules. in a web search i see mention of the problem popping up for people all over the place -- one of the first is a message from 1998 in which dan jacobowitz is suggesting that a sign extension is causing an overflow... how is it people are stepping around the problem? -- [EMAIL PROTECTED] Brad Midgley
