Home > Relocation Error > Relocation Error R_amd64_32 Solaris

Relocation Error R_amd64_32 Solaris

Contents

Is that to be expected - I thought you were implying that the got sections should be writable. Dynamic Object Versioning - specifying a version binding Changing Search Paths with crle(1) - they are a replacement Wrong ELF Class - requires consistent compiler flags C++ Dynamic Linking - symbol Anyways, when you execute a plugin, try using the syntax "plugin call myplugin " that should fix your problem. got this far with the following references:https://blogs.oracle.com/rie/entry/my_relocations_don_t_fithttp://gcc.gnu.org/ml/gcc-help/2009-02/msg00130.html Is this a linker bug, or a gcc bug? this contact form

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. Please don't fill out this field. No, thanks OSDir.com os.solaris.opensolaris.help Subject: Re: Compiling issue on x86! GBiz is too! Latest News Stories: Docker 1.0Heartbleed Redux: Another Gaping Wound in Web Encryption UncoveredThe Next Circle of Hell: Unpatchable SystemsGit 2.0.0 ReleasedThe Linux Foundation Announces Core Infrastructure

Relocation Error R_sparc_13

We are making use of Sun's EZQual virtualized servers to support our Solaris versions. For example, the ".rel.got" contains the information that must be applied" to the ".got" section. load &j into %o0 You can investigate the global offset table requirements of an object using elfdump(1) with the -G option.

Posted by Joe Ganley on May 28, 2010 at 01:54 AM PDT # Never mind. See Global Offset Table (Processor-Specific). I'm puzzled by section 11, which is a "got" section, but not writable. Value Does Not Fit Sparc Please let me know if you have any suggestions.

I think the SS12 binaries were still around and when I removed them completely and replaced them with SS11 everything fell in place. Relocation Error Sparc how can I copy files which are stored in one variable more hot questions question feed lang-perl about us tour help blog chat data legal privacy policy work here advertising info Hence the 'ld' issue is not a problem. More about the author COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/opt/pkg/gcc47/libexec/gcc/x86_64-sun-solaris2.11/4.7.2/lto-wrapper Target: x86_64-sun-solaris2.11 Configured with: ../gcc-4.7.2/configure --enable-languages='c obj-c++ objc fortran c++' --enable-shared --enable-long-long --with-local-prefix=/opt/pkg/gcc47 --enable-libssp --enable-threads=posix --with-boot-ldflags='-static-libstdc++ -static-libgcc -Wl,-R/opt/pkg/lib ' --disable-nls --enable-__cxa_atexit --with-gxx-include-dir=/opt/pkg/gcc47/include/c++/ --without-gnu-ld --with-ld=/usr/bin/ld --with-gnu-as --with-as=/opt/pkg/bin/gas --prefix=/opt/pkg/gcc47 --build=x86_64-sun-solaris2.11 --host=x86_64-sun-solaris2.11

Section 11 is interesting: Section Header[11]: sh_name: .rel.got sh_addr: 0x216c4 sh_flags: [ SHF_ALLOC SHF_INFO_LINK ] sh_size: 0x2c0 sh_type: [ SHT_REL ] sh_offset: 0x216c4 sh_entsize: 0x8 (88 entries) sh_link: 5 sh_info: 26 Menu Skip to content Home About Contact ReadyNAS iSCSI Support for ReadyNAS Visitors Porting For The Sun: The Zlib Problem (ld.so.1: exe: fatal: relocation error: R_AMD64_32:) Leave a reply With the http://ecls.sourceforge.net/resources.html (latest source is git clone git://ecls.git.sourceforge.net/gitroot/ecls/ecl ) I'm doing this 32-bit on a Xeon processor as that's the fastest machine I've got, and requires no messing around with CFLAGS, but In fact this does not happen if I create a shared library, but I need an executable..

Relocation Error Sparc

Compile some code without a PIC flag: % cat foo.c extern int bar(); int foo() { return (bar()); } % cc -c foo.c % elfdump -r foo.o Relocation Section: .rela.text type https://www.illumos.org/issues/3616 We are currently work with a Sun Fire V490 (Sparc) and a Solaris 08/07. Relocation Error R_sparc_13 the TEXTREL test should reveal nothing). Symbol .data (section): Value 0x21100 Does Not Fit Here's some >> of the output of the compiler commands I've tried: >> >> $ gcc -shared -DSYSTEM=OPUNIX -m64 stplugin.c hello.c -o hello.plugin >> Text relocation remains referenced >> against symbol

You seem to have CSS turned off. weblink Shared objects are typically built using position independent code, using compiler options such as -Kpic. 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. I haven't been able to use gcc to compile so switched to Sun CC which should be available on your EZQual hosts. .data (section): Value Does Not Fit

Sure that reference is coming from a crt object file added by gcc, I checked that file and it is PIC. mod_deflate is the only module that is having problems. Since shared objects are typically loaded at the top of memory, the upper 32-bits of an address are required. navigate here Cheers, Leif If you would like to refer to this comment somewhere else in this project, copy and paste the following link: Leif Mortenson - 2008-07-11 Logged In: YES user_id=228081 Originator:

Ok thank you very much anyway! Posted by guest on January 10, 2013 at 02:58 AM PST # Post a Comment: Name: E-Mail: URL: Notify me by email of new comments Remember Information? debug: collecting input relocations: section=.text, file=foo.o debug: type offset addend section symbol debug: in R_SPARC_WDISP30 0x14 0 [13].rela.text bar debug: out R_SPARC_WDISP30 0x14 0 .text bar This indicates that ld() is

It does in fact contain output relocations.

The most common culprits of text relocations are against .text, .rodata or .rodata1. I need to create a powerpc PIE executable, that is not a shared library, but a real executable linked as pie. jvm 1 | WrapperManager: One common cause of this problem is running a 32-bit version jvm 1 | WrapperManager: of the Wrapper with a 64-bit version of Java, or vica versa. Look for the "out" diagnostics that are against any read-only section.

On Solaris you can run pic, and non-pic code as an executable or shared object (although non-pic shared objects can have some address restrictions). This can happen if you have a table of addresses, and the table is defined const. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/opt/pkg/gcc47/libexec/gcc/x86_64-sun-solaris2.11/4.7.2/lto-wrapper Target: x86_64-sun-solaris2.11 Configured with: ../gcc-4.7.2/configure --enable-languages='c obj-c++ objc fortran c++' --enable-shared --enable-long-long --with-local-prefix=/opt/pkg/gcc47 --enable-libssp --enable-threads=posix --with-boot-ldflags='-static-libstdc++ -static-libgcc -Wl,-R/opt/pkg/lib ' --disable-nls --enable-__cxa_atexit --with-gxx-include-dir=/opt/pkg/gcc47/include/c++/ --without-gnu-ld --with-ld=/usr/bin/ld --with-gnu-as --with-as=/opt/pkg/bin/gas --prefix=/opt/pkg/gcc47 --build=x86_64-sun-solaris2.11 --host=x86_64-sun-solaris2.11 his comment is here did you give any try with "gld". #2 Updated by Aakash Saini over 3 years ago try linking with libgcov.a:gcc -ggdb3 -fprofile-arcs -ftest-coverage -Wl,-b -Wl,-m tmp.c -lgcov #3 Updated by Richard

actually. Position-independent code is recommended for the creation of shared objects. Relocation section '.rel.plt' at offset 0x264 contains 2 entries: Offset Info Type Sym.Value Sym.