On Tue, May 02, 2017 at 03:19:22PM +0000, Laurent Bercot wrote:
> > However, when I tried to build execline the compiler tried to include
> > libskarnet.a from the host machine when linking the programs:
> > (...)
> > exec armeb-linux-musleabi-gcc <snip> -L/path/to/staging/usr/local/lib \
> > -Wl,--gc-sections src/execline/cd.o
> > /usr/lib/x86_64-linux-gnu/libskarnet.a
> > /usr/lib/x86_64-linux-gnu/libskarnet.a: error adding symbols: File
> > format not recognized
> Agh! I knew I had squashed a good number of bugs with toolchains' link
> paths, but this is not a toolchain problem, this is a make problem.
> Could you please edit your generated config.mak file for execline,
> and add a line just containing
> right before the line starting with "vpath lib%.a" ? Then run make, and
> report the result. If it builds correctly, I'll know exactly what and
> where the bug is and have an easy workaround; if it doesn't, it will
> require more investigation.
Unfortunately, simply adding 'vpath' to config.mak doesn't solve the problem.
I tried a couple of things, however when I tried moving my host machine's
libskarnet.a out of the default library path on that machine, make failed with
make: *** No rule to make target '-lskarnet', needed by 'background'. Stop.
>From my experiments (and a bit of googling) it seems that make isn't picking
up the cross target's artificial library path over the host machine's