Link failure on amd64
Adam Thomason
compiled with -fPIC, which is a requirement of assembling a shared
library on that platform. This came up once before and was fixed, but
seemingly it was undone on account of win32 and I hadn't noticed until
now. Some history follows.
An excerpt from
http://groups.google.com/groups?hl=en&lr=&c2coff=1&safe=off&selm=200405081141.i48BfAf04107%40thu8.leo.home:
Leopold Toetsch <l...@toetsch.at> wrote:
> Adam Thomason <thom...@xencor.com> wrote:
>
> > It's not the library that's the trouble, it's the contained objects.
>
> The build rule shouldn't contain nci_test$(O) but just
>
> path/libnci$(SO) : nci_test.c
> $(LD) $(LD_SHARED) $(LIBNCI_DEF_FILE) ...
>
> No need to have a CC_SHARED with -fPIC (not yet).
>
> > Adam
>
> leo
But shortly thereafter, the following was committed with log message
"#30401 win32 building fix (libnci.dll)":
http://cvs.perl.org/cgi/cvsweb.cgi/parrot/config/gen/makefiles/root.in.diff?r1=1.222&r2=1.223
-$(LIBNCI_SO): $(SRC)/nci_test.c
+$(LIBNCI_SO): $(SRC)/nci_test$(O)
$(LD) $(LD_SHARED) ${ncilib_link_extra} $(LDFLAGS) \
- $(LD_OUT)$@ $(SRC)/nci_test.c
+ $(LD_OUT)$@ $(SRC)/nci_test$(O)
Clearly there are conflicting requirements here. Is a CC_SHARED
required after all?
Adam
Leopold Toetsch
> libnci.so fails to build on amd64/Linux because nci_test.o isn't
> compiled with -fPIC, which is a requirement of assembling a shared
> library on that platform.
It's linked with -fPIC [1], but that might be wrong of course. If we've
to compile with -fPIC, we have to build all $(O) files (and not only
nci_test.o) twice: once for the static parrot and once for a shared
libparrot.so.
> ... Is a CC_SHARED
> required after all?
s/CC_SHARED/CC_SHARE_FLAGS/ for consistency or CC_LOAD_FLAGS?.
Seems so. -fPIC is listed under Code Generation in "info gcc".
> Adam
leo
[1] i386/linux:
cc -shared -L/usr/local/lib -fPIC -L/usr/local/lib -g \
-o runtime/parrot/dynext/libnci.so src/nci_test.o