Home > Relocation Error > Relocation Error R_sparc_wdisp30

Relocation Error R_sparc_wdisp30

Contents

Then using the options -cN.text to elfdump I see: [email protected]:~/ecl$ elfdump -cN.text ./build/libecl.so Section Header[13]: sh_name: .text sh_addr: 0x37540 sh_flags: [ SHF_ALLOC SHF_EXECINSTR ] sh_size: 0x11bc0c sh_type: [ SHT_PROGBITS ] sh_offset: Previous message View by thread View by date Next message [tools-linking] Re: non-PIC objects within ".so" ... Posted by Stefano B on February 21, 2011 at 06:34 AM PST # Sorry, but I don't think there's anything I can offer. Isn't it? :) There is nothing wrong in the current behavior of --disable-shared: it builds static libraries the way static libraries should be built. this contact form

Sometimes. Good idea. The approach works fine for 32 bit on Solaris. Anyway, option --disable-shared exists, and is documented. check over here

Relocation Error R_sparc_13

a PIC executable is even not run by the shell. We should probably add links to Google in the manual. :-) Format For Printing -XML -Clone This Bug -Top of page Home | New | Browse | Search | [?] | I suspect the reference to __libc_start_main is coming from one of the crt files provided by the compiler driver. not very easy for me to understand (i can post it if it can help) I really can't understand how it happens that from all PIC object files (if I checked

What I'd do next is run your link-edit with LD_OPTIONS=-Dreloc,detail and trace back where the "0xc02d0" offset originates from (ie, which input file requires this relocation). Update - Wednesday April 14, 2010 A question arose on how to interpret the diagnostic output so as to determine which input file is non-pic. what does "/usr/bin/perl: relocation error:" mean? 8. Value Does Not Fit Sparc What relocation titles did you see in the output?

Posted by David Kirkby on September 18, 2010 at 12:31 AM PDT # The R_386_JMP_SLOT relocations are fine. Relocation Error Sparc It doesn't help - the problem remains. Position-dependent code typically requires more runtime relocations than the corresponding position-independent code. https://blogs.oracle.com/rie/entry/my_relocations_don_t_fit No. > 4) Could building non-PIC libraries or using > "ld -r" on the inputs cause "silent failures"? > By that, I mean incorrectly-executing code which > doesn't cause either "ld"

Comment 1 Vladimir Kondratyev 2005-04-29 07:38:52 UTC Forgot to say: binutils 2.15 Comment 2 Andrew Pinski 2005-04-29 07:39:31 UTC So you are not building with --with-pic? When we made .SUNW_reloc generation the default we added the -z argument too. I am trying to build apache on solaris AMD64 platform. Try to configure at toplevel --with-pic, but I'm not sure the option is valid there.

Relocation Error Sparc

The non-pic relocations will probably be against the .text section. click site Fun. Relocation Error R_sparc_13 For example, the ".rel.got" contains the information that must be applied" to the ".got" section. Symbol .data (section): Value 0x21100 Does Not Fit We're not affiliated or endorsed by the Mozilla Corporation but we love them just the same.

First, I'd try and identify what the text relocations reference. http://supercgis.com/relocation-error/relocation-error.html Another aid might be to also use the link-editors -znocombreloc option. Is this a known issue? I'll try it now, and will let you know whether it helps. .data (section): Value Does Not Fit

Are you sure the kernel sources you are using are for the same kernel version as on the system (ie, uname -a) ? But shared objects also have a cost. If a shared object is built from position-dependent code, the text segment can require modification at runtime. http://supercgis.com/relocation-error/relocation-error-ld-so-1.html Try to configure at toplevel --with-pic, but I'm not sure the option is valid there.

Thanks for this post; I'm sure it will now help me nail down the issue. This means that it isunable to create a working executable and so it issues the errormessages. However, some relocations can not be satisfied at runtime.

Index Nav: [DateIndex] [SubjectIndex] [AuthorIndex] [ThreadIndex] Message Nav: [DatePrev][DateNext] [ThreadPrev][ThreadNext] Other format: [Raw text] fatal: relocation error: R_SPARC_WDISP30 From: Sunil To: binutils at sources dot redhat

ubuntu: cat > main.c void main(){} ubuntu: gcc main.c ubuntu: readelf -r a.out ... So I'll tell the perl people to update their Makefiles. The studio compilers recognize this condition and normally place the table in a .picdata section which is given write access, and gets places in the data segment. Try to follow through a simple example.

What I did is that I moved the 'case R_SPARC_DISP32' portion of code (the 4 lines) just after the line '#endif /* CONFIG_SPARC64 */' That's some bad hack Harry ;-) but If you can't build a simple a.out with pic, and have it execute, you're going to have to call in some other experts. These are the relocation records that are created in the output file, and must be processed at runtime. his comment is here Terms of Use | Your Privacy Rights | Developer Forum Board index idl-pvwave relocation error: R_SPARC_WDISP30 relocation error: R_SPARC_WDISP30 by cky » Fri, 01 Oct 2004 03:48:32 When I am running

Ifso you could post that and we could investigate further. (Does theproblem persist if you run the linker under Solaris running in 32-bitmode ?)CheersNick Sunil 2004-05-25 14:58:17 UTC PermalinkRaw Message Nick,I The intention is to make resulting shared library loadable on every target machine with no regard to availablity of shared libraries, and make the library as small as possible. Thus, position-dependent code sequences can exist within SPARCV9 shared objects. Name+added = __libc_start_main I tried using "LD_OPTIONS=-Dreloc,detail" but I do not get the same showed before..