You receive this bug because this package does not respect my system's LD (x86_64-pc-linux-gnu-gcc) and calls directly /usr/bin/ld (or similar)
The possible solutions to fix this issue are:
1)Fix the buildsystem, if you can;
2)inherit toolchain-funcs and use tc-export LD If you strictly need ld
3)inherit toolchain-funcs and use emake LD="$(tc-getCC)"
From the build log:
ld -r -o braille.o eu_braille.o eu_io.o eu_serial.o eu_usb.o eu_bluetooth.o eu_net.o eu_protocol.o eu_clio.o eu_esysiris.o
It respects LD when the value is an absolute path.
But when LD is a relative path, it is ignored.
Is this not standard behavior?
I'm guessing that you were using a relative path.
The other ar bug is definitely a bug though, because the call is
(In reply to Chris Brannon from comment #1)
> It respects LD when the value is an absolute path.
> But when LD is a relative path, it is ignored.
> Is this not standard behavior?
> I'm guessing that you were using a relative path.
> The other ar bug is definitely a bug though, because the call is
ld at link time should be called by the CC. Works in this case something like that?
the correct order should be:
$(CC) $(CFLAGS) $(LDFLAGS) $(OBJECTS) $(LIBS)
In the brltty build system, ld isn't always called by cc.
Instead, it is sometimes called like this:
$(MKOBJ) $@ $(OBJ_FILES)
where MKOBJ is defined as:
$(LD) -r -o
The build output that you included in your original bug report
was using one of these MKOBJ calls, so it should have been using the
value of LD that you gave at configure-time.
Fixed in app-accessibility/brltty-4.5-r2.
Thanks for the report.