Greetings,
In the build sequence below, ld issues a relocation error for
libc.a(malloc.o), indicating it [libc.a, as I read it] should be
recompiled with -fPIC
Googling the key words in the message reveals a few of hits, all with
similar advice; but the advice is directed to an application specific
library, not libc
Is this a generic issue for amd64? In a cosmic sense, probably not, we
have a lot of shared libs building on the amd64. And FWIW I know that
the same build sequence works on i386.
A possibility is that there is a contradictory use of flags on the cc
line, at least for the amd64. Does anybody have insight on this?
Alternatively, should I take the advice and look for a work-around --
such as building my own libc with -fPIC ? This doesn't seem right for a
port. I'm concerned about what else might break.
The application in question is OpenBSD ports devel/eclipse-3.1p6, which
is not currently qualified for the amd64, but hey, we're giving it a
shot; there are only a about five cc compiles in the entire build,
we're about 2/3 of the way through, and most of the job is ant and ecj,
which are running quite happily on the amd64 jamvm/classpath.
I'm running
OpenBSD 3.9-current (GENERIC) #556: Sat May 27 18:32:05 MDT 2006
[EMAIL PROTECTED]:/usr/src/sys/arch/amd64/compile/GENERIC
Regards,
Fred Druseikis
build.jars:
[echo] Building libcore_3_1_0.so.2.0
[echo] cc -o libcore_3_1_0.so.2.0 -shared -fPIC
-I/home/hubert/openbsd/ports/devel/eclipse/sdk/w-eclipse-sdk-3.1p6/plugins/org.eclipse.core.resources.openbsd/../org.eclipse.core.resources.openbsd/src/
-I/usr/local/exodus/include -I/usr/local/exodus/include/openbsd
libcore_3_1_0.so.2.0 -static -lc
[apply] /usr/bin/ld: /usr/lib/libc.a(malloc.o): relocation
R_X86_64_32 can not be used when making a shared object; recompile with
-fPIC
[apply] /usr/lib/libc.a: could not read symbols: Bad value
[apply] collect2: ld returned 1 exit status
[apply] Result: 1
