Re: R_X86_64_32S error building a shared library
On Sunday 2009-01-25 05:46, Adam Nielsen wrote: x86_64-pc-linux-gnu/bin/ld: .../lib64/libboost_system-mt-1_37.a(error_code.o): relocation R_X86_64_32S against `a local symbol' can not be used when making a shared object; recompile with -fPIC .../lib64/libboost_system-mt-1_37.a: could not read symbols: Bad value You do not need to have boost available as a shared library.
Re: R_X86_64_32S error building a shared library
x86_64-pc-linux-gnu/bin/ld: .../lib64/libboost_system-mt-1_37.a(error_code.o): relocation R_X86_64_32S against `a local symbol' can not be used when making a shared object; recompile with -fPIC .../lib64/libboost_system-mt-1_37.a: could not read symbols: Bad value You do not need to have boost available as a shared library. Sorry Jan, I don't understand - how can I link my library in with the user's local installation of Boost if it's not available as a shared library? Thanks, Adam.
Re: R_X86_64_32S error building a shared library
On Monday 2009-01-26 01:23, Adam Nielsen wrote: x86_64-pc-linux-gnu/bin/ld: .../lib64/libboost_system-mt-1_37.a(error_code.o): relocation R_X86_64_32S against `a local symbol' can not be used when making a shared object; recompile with -fPIC .../lib64/libboost_system-mt-1_37.a: could not read symbols: Bad value You do not need to have boost available as a shared library. Sorry Jan, I don't understand - how can I link my library in with the user's local installation of Boost if it's not available as a shared library? I do not truly have an answer for that. But if I remember correctly, I had seen .pic.a libraries previously which, I would say, would alleviate the problem, short of them being much less widespread in use than .a archives already are. It really seems uncommon to me for users not to have shared libraries these days..
Install to lib64
I'm maintaining an autotools-configured project, and I've noticed that the make install resulting from my build (on x86_64 arch, linux) puts generated libraries in prefix/lib instead of prefix/lib64 - is there something I should do differently, or is the the expected behaviour? Thanks, Jason
blank line following trailing backslash
Hello everybody, I just had an ingenious idea to limit conflicts in versioning systems. When you specify a list of files for a rule you put every file in a line like this. fileA.c \ fileB.c \ fileC.c now if 2 independent people add another file fileD and fileE to that list you have a conflict because both of them modify the line with fileC.c to add the necessary backslash. This is not nice so I thought well let's add a backslash after the last file and add an empty line at the end. Then there's no need to modify the fileC line and everybody just adds a line to the list. This can be resolved. But automake doesn't like this at all. Even though it is clearly visible that this is not wrong it complains. It doesn't even warn about this it produces an error. I think this is not nice. Is there a way around this problem? Can I do something to make all file list entries identical? Or can I tell automake to ignore this or only produce a warning? Thanks a lot Andreas
Re: blank line following trailing backslash
On Sunday 2009-01-25 18:42, Andreas wrote: When you specify a list of files for a rule you put every file in a line like this. fileA.c \ fileB.c \ fileC.c now if 2 independent people add another file fileD and fileE to that list you have a conflict because both of them modify the line with fileC.c to add the necessary backslash. I think this is not nice. Is there a way around this problem? Can I do something to make all file list entries identical? Or can I tell automake to ignore this or only produce a warning? foo_SOURCES = foo_SOURCES += fileA.c foo_SOURCES += fileB.c foo_SOURCES += fileC.c foo_SOURCES += fileD.c foo_SOURCES += fileE.c ...
Re: Install to lib64
On Sunday 2009-01-25 22:54, Jason Sewall wrote:
I'm maintaining an autotools-configured project, and I've noticed that
the make install resulting from my build (on x86_64 arch, linux) puts
generated libraries in prefix/lib instead of prefix/lib64 - is there
something I should do differently, or is the the expected behaviour?
Seems pretty expected. All distros that get it right have some sort of
mechanism to always call configure with --libdir='${prefix}/lib64'
(or similar, but still with lib64); rpm for example has
%configure which expands to all the fluff needed or wanted by the
distro, including correct libdir for a given %arch.
Re: Install to lib64
Jason Sewall wrote: I'm maintaining an autotools-configured project, and I've noticed that the make install resulting from my build (on x86_64 arch, linux) puts generated libraries in prefix/lib instead of prefix/lib64 - is there something I should do differently, or is the the expected behaviour? That is the expected behavior. On normal/pure 64-bit systems that is usually the normal expected location. On my 64-bit system lib and not lib64 is the correct location since there isn't any 32-bit version. 64-bit systems are first class citizens too. If you need it in a specific location then you should tell it that at configure time. You can always set up a site specific configuration so that it will default to a particular location for you on your system if you desire. The locations that the autotools default to using are the GNU standard locations. The GNU system is designed to be its own system and it has its own set of standards. This has been around a long time and predates both POSIX and the newer FHS. But the autotools are very configurable and everyone is free to set up installation locations as they see fit. The typical procedure for packagers is to set any system specific locations on the configure command line but to codify those locations in the package build script. This is usually done by package management systems in different ways. On RPM based systems (e.g. Red Hat, SuSE) look at using the %configure macro which is designed to do this for you easily. On DPKG based systems (e.g. Debian, Ubuntu) this is usually done in the rules file. The syntax and interface is standardized and well known. Bob
Re: R_X86_64_32S error building a shared library
x86_64-pc-linux-gnu/bin/ld: .../lib64/libboost_system-mt-1_37.a(error_code.o): relocation R_X86_64_32S against `a local symbol' can not be used when making a shared object; recompile with -fPIC .../lib64/libboost_system-mt-1_37.a: could not read symbols: Bad value You do not need to have boost available as a shared library. Sorry Jan, I don't understand - how can I link my library in with the user's local installation of Boost if it's not available as a shared library? I do not truly have an answer for that. But if I remember correctly, I had seen .pic.a libraries previously which, I would say, would alleviate the problem, short of them being much less widespread in use than .a archives already are. It really seems uncommon to me for users not to have shared libraries these days.. Sorry, I should've expressed that more clearly - I didn't think it was possible to link with a user's local installation of Boost if it wasn't in shared-library form. I have Boost installed on my system as a shared library, so I don't understand why libtool/gcc won't link to it. Thanks, Adam.
Re: R_X86_64_32S error building a shared library
I have Boost installed on my system as a shared library, so I don't understand why libtool/gcc won't link to it. Hmm okay, I think I've just discovered why - it seems my local installation of Boost was compiled without the -fPIC flag, as I have problems even with trivial compiles, without using automake/libtool: $ g++ -fPIC -c -o main.o main.cpp -I/usr/include/boost-1_37/ g++ -fPIC -o test.so main.o -shared -lboost_system-mt-1_37 -lboost_filesystem-mt-1_37 /usr/lib/gcc/x86_64-pc-linux-gnu/4.3.2/../../../../x86_64-pc-linux-gnu/bin/ld: /usr/lib/gcc/x86_64-pc-linux-gnu/4.3.2/../../../../lib64/libboost_system-mt-1_37.a(error_code.o): relocation R_X86_64_32S against `a local symbol' can not be used when making a shared object; recompile with -fPIC /usr/lib/gcc/x86_64-pc-linux-gnu/4.3.2/../../../../lib64/libboost_system-mt-1_37.a: could not read symbols: Bad value collect2: ld returned 1 exit status I think it must have been the way Boost was compiled, because I get the same error even when I don't link to any libraries: $ g++ -c -o main.o main.cpp -I/usr/include/boost-1_37/ g++ -o test.so main.o -shared /usr/lib/gcc/x86_64-pc-linux-gnu/4.3.2/../../../../x86_64-pc-linux-gnu/bin/ld: main.o: relocation R_X86_64_32 against `a local symbol' can not be used when making a shared object; recompile with -fPIC main.o: could not read symbols: Bad value collect2: ld returned 1 exit status But if I add -fPIC in that case, it works: $ g++ -fPIC -c -o main.o main.cpp -I/usr/include/boost-1_37/ g++ -o test.so main.o -shared Given that I've used -fPIC in the first command above, it would seem that my local installation of Boost was compiled without -fPIC, so it looks like all I need to do is figure out how to do that and everything should work... Thanks for all your help! Cheers, Adam.
