[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: RFH for cross-building saclib



On 2022-07-06 16:37 +0530, Nilesh Patra wrote:
> 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?
> 
> 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.

OK. I've had a proper look now and you are right it is being really perverse.

On thing, this package doesn't clear up so testing is tiresome

I added a debian/clean
*.o
*.lo
include/sysdep.h
src/GC.c
libsaclib.la
.libs/

using libtool --config and libtool --debug may be helpful

But what's interesting is that you get the fomat error at link time only when the rpath option is specified.
So (I think) it's actually the (re-)writing of the rpaths that is giving a format error, not the linking.
and the message it prints out saying 'gcc' is a misleading attempt to summarise and it really does use the right gcc.

Fortunately setting rpaths is usually wrong in debian unless it is a private library. It's not
installed in a private location so that line should probably be:
libtool --mode=link --tag=CC $(CC) $(CPPFLAGS) $(LDFLAGS) -o $@ $^ -lm
anyway, and that has the advantage of working fine :-)

There is probably a way to teach libtool to use the right
rpath-setting tool, but maybe we don't care enough right now :-)
(probably installing binutils-multiarch will do the trick?)

Now with the above fix the build still fails at binary-assembly time
because the rules file I have has only built the static lib, not the
dynamic lib (there is no target for libsaclib.so).

But it does now link properly, rather than trying to use x86 tools on arm64 object files.

HTH

Wookey
-- 
Principal hats:  Debian, Wookware, ARM
http://wookware.org/

Attachment: signature.asc
Description: PGP signature


Reply to: