relocation R_X86_64_32 against `.rodata.str1.1' can not be used when making a shared object; recompile with -fPIC

[marco bra]

Hi, compiling harbour  git updated src on Ubuntu 64 bit, give me...

/home/ubuntu/src/harbour-core/bin/linux/gcc/hbmk2 -quiet -width=0 -autohbm- @hbpre -inc -jobs=8 -hbdyn hbgd/hbgd.hbp @hbpost hbgd/hbgd.hbc
/usr/bin/ld: ../lib/linux/gcc/libhbct.a(ctmath2.o): relocation R_X86_64_32 against `.rodata.str1.1' can not be used when making a shared object; recompile with -fPIC
../lib/linux/gcc/libhbct.a: could not read symbols: Bad value
collect2: ld returned 1 exit status
hbmk2[hbgd]: Error: Running dynamic lib link command. 1
hbmk2[hbgd]: Exit code: 7: failed in final assembly (linker or library manager)

Any hints ?

Thanks, best regards

Marco

 

[Alain Aupeix]

Hi, there is a few month that the problems occurs, here is what I wrote :

2) I have always errors on some contribs

/usr/bin/ld: ../lib/linux/gcc/librddsql.a(sqlbase.o): relocation R_X86_64_32 against `.bss' can not be used when making a shared object; recompile with -fPIC
../lib/linux/gcc/librddsql.a: could not read symbols: Bad value
collect2: ld a retourné 1 code d'état d'exécution
hbmk2[sddsqlt3]: Error: Running dynamic lib link command. 1
hbmk2[sddsqlt3]: Exit code: 7: failed in final assembly (linker or library manager)
  
I have this error with : sddsql3, sddpg, sddodbc, sddmy, sddfb, hbziparc, hbmagic, hbgs and hbgd.
When Przemyslaw came back, he talked about this problem, but it seems to forget it.
Is this problem going to be solved ?

But no answer from anybody.
It occurs only for dynamic libs.

Hope that Przemyslaw will be able to do something.

A+

--

---

Alain Aupeix
http://jujuland.pagesperso-orange.fr/
http://pissobi-lacassagne.pagesperso-orange.fr/

---

U.buntu 12.04 | G.ramps 3.4.4-1 | H.arbour 3.2.0dev (r2013-05-17 14:20) | HbIDE (Rev.222)

---

[elch]

Hi Marco,

i avoid this problematic with building static contrib libs, as i want to have. This can be done with:

export HB_BUILD_CONTRIB_DYN=no

or changing the default in:

harbour/config/global.mk

--

Sure i'm not the compiler experienced and outside deeper knowledge ..

So maybe it seem something special to the AMD64 platform, as if i read this text - scroll a bit down to: case 4

http://www.gentoo.org/proj/en/base/amd64/howtos/index.xml?part=1&chap=3

Regards

Rolf

[Przemyslaw Czerpak]

On Fri, 24 May 2013, Alain Aupeix wrote:

Hi,

> Hi, there is a few month that the problems occurs, here is what I wrote :
> 2) I have always errors on some contribs
> /usr/bin/ld: ../lib/linux/gcc/librddsql.a(sqlbase.o): relocation
> R_X86_64_32 against `.bss' can not be used when making a shared object;
> recompile with -fPIC
> ../lib/linux/gcc/librddsql.a: could not read symbols: Bad value

> collect2: ld a retourne 1 code d'etat d'execution

> hbmk2[sddsqlt3]: Error: Running dynamic lib link command. 1
> hbmk2[sddsqlt3]: Exit code: 7: failed in final assembly (linker or library
> manager)
> I have this error with : sddsql3, sddpg, sddodbc, sddmy, sddfb, hbziparc,
> hbmagic, hbgs and hbgd.
> When Przemyslaw came back, he talked about this problem, but it seems to
> forget it.

I still remember about it. I only wanted to see what was the goal of
shared contrib libraries in Harbour. Current state is completly broken.
To make it usable it's necessary to strongly change build process to
fully separate libraries which are part of static and shared builds
because they cannot be mixed on some architectures (above error is
result of such mix) and define our new file system directory tree
localization for different *nixes so we can use shared and static
libraries. For some systems it will be necessary to use different
names for static and libraries ones to avoid collisions.
For some platforms which strictly forbid local shared libraries it's
also necessary to define second build pass for binaries linked with
shared Harbour libraries because they can be used in build process
but only after system wide shared library installation.

> Is this problem going to be solved ?

Potentially yes. But in current state Harbour build system is not ready
for it and enabling shared contrib libraries by default broke most of
non Windows builds.

> But no answer from anybody.

I haven't made any of the modifications which created the problem and
I haven't seen any info how new problems are planed to be resolved so
I decided to not put my fingers in it.

> It occurs only for dynamic libs.

Yes and the problem can be eliminated with shared contrib libs by:

export HB_BUILD_CONTRIB_DYN="no"

> Hope that Przemyslaw will be able to do something.

The easiest workaround for above error message is:

export HB_USER_CFLAGS="-fPIC"

but it only fix the Harbour build time problem. It does not resolve
the problem with shared and static library names conflict when user
wants to link final application with static ones so for many users
the Harbour binaries with shared contrib libs are still unusable and
export HB_BUILD_CONTRIB_DYN="no"
is the only one choice.
BTW on some architectures -fPIC switch causes noticable speed overhead,
i.e. build harbour with:
export HB_BUILD_CONTRIB_DYN="no"
export HB_USER_CFLAGS=""
make clean
make install
and create static binaries from test/speedtst.prg by:
hbmk2 -n -w -es2 -gc3 -kmo -static speedtst.prg -o speedtst1

then
export HB_BUILD_CONTRIB_DYN="no"
export HB_USER_CFLAGS="-fPIC"
make clean
make install
and create static binaries from test/speedtst.prg by:
hbmk2 -n -w -es2 -gc3 -kmo -static speedtst.prg -o speedtst2

Finally execute speedtst1 and speedtst2 to compare results.

best regards,
Przemek