On 7/6/22 4:14 PM, Wookey wrote:
It compiles with host complier, but during mode=link it uses gcc (as in from build target) instead. More precisely, it uses the right compiler while linking the static lib; but it changes to gcc while doing a shared linking. From the logs: | libtool --mode=link --tag=CC aarch64-linux-gnu-gcc -Wdate-time -D_FORTIFY_SOURCE=2 -Wl,-z,relro -Wl,-z,now -o libsaclib.la AADV.lo ABS.lo ACLOCK.lo [.. huge list ..] | libtool: link: gcc -shared -fPIC -DPIC .libs/AADV.o .libs/ABS.o[.. huge list ..] ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Is there a way to change that?Hmm. This is quite odd. Not sure why libtool would think that the dynamic link should be done natively, but then libtool is a law unto itself. On modern linux is much easier to just define a working link line than it is to persuade libtool to DTRT in it's very complicated way :-)
Yeah, right.
that --tag=CC is telling libtool to use the C variables (like $CC $LD etc.) If your CC isn't set to aarch64-linux-gnu-gcc then it'll do the wrong thing. But it's working for the rest of the script, so I'm not sure if this is what's actually going wrong.
Hmmm.
I note that /usr/share/dpkg/buildtools.mk says # The variables are not exported by default. This can be changed by # defining DPKG_EXPORT_BUILDTOOLS. So you might find that defining that before loading /usr/share/dpkg/buildtools.mk will help.
ACK, I tried this as well, but it chokes with same error :/ TBH, I want to find the reason at this point as to why libtool does not take the needed variables :) and if there is a way to fix it. I suppose using a proper makefile will mitigate this (as with most other packages) but I am curious to know if there is some other way around it.
Just an idea.
Thank you for chiming in! -- Best, Nilesh
Attachment:
OpenPGP_signature
Description: OpenPGP digital signature