Building a port with math/superlu fails: linking a shared obj
library adding archive superlu.a fails
ohartman at zedat.fu-berlin.de
Sun Mar 11 21:53:21 UTC 2012
On 03/11/12 21:47, Mel Flynn wrote:
> On 3/11/2012 20:39, O. Hartmann wrote:
>> IsisInterfaceMapLineScan.cc:92:11: warning: variable 'lon_lat_radius'
>> set but not used [-Wunused-but-set-variable]
>> CXX IsisAdjustCameraModel.lo
>> CXXLD libaspIsisIO.la
>> /usr/local/bin/ld: /usr/local/lib/libsuperlu.a(dgssvx.o): relocation
>> R_X86_64_32 against `.rodata.str1.1' can not be used when making a
>> shared object; recompile with -fPIC
>> /usr/local/lib/libsuperlu.a: could not read symbols: Bad value
>> collect2: ld returned 1 exit status
>> *** [libaspIsisIO.la] Error code 1
> Are you using USE_AUTOTOOLS=libtool but not automake?
I need to run a script called "autogen" in the root folder provided with
the sources as a pre-configure tagged operation.
I tried using USE_AUTOTOOLS= autogen, but this fails.
I got it now working so far, except the described error.
It isn't possible to compile xxx_la_LTLIBRARIES by merging different
libraries with an archive.
As of my understanding, the archive of superlu needs to be treated like
an ordinary .o file that is compiled into a to-be-created shared object.
And in this task I fail, since the whole build logic does not consider
Could math/superlu be compiled that way that it produce a shared object
instead of this clumsy ordinary superlu.a archive?
> I'm seeing similar issues with zarafa if I do just that. If I let the
> port use the provided libtool *or* use the entire autotools toolchain,
> then all is well. Also, adding --with-pic to CONFIGURE_ARGS does not
> change either outcome.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 488 bytes
Desc: OpenPGP digital signature
Url : http://lists.freebsd.org/pipermail/freebsd-ports/attachments/20120311/45db33f4/signature.pgp
More information about the freebsd-ports