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 usin
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 a
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 beh
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,
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 m
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
hav
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
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_syste
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
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
10 matches
Mail list logo
