https://sourceware.org/bugzilla/show_bug.cgi?id=25494
--- Comment #3 from YunQiang Su <syq at debian dot org> --- (In reply to Maciej W. Rozycki from comment #2) > For linking in raw binary chunks of data the best approach is to use GAS > and its .incbin pseudo-op, e.g.: > > $ cat xx.s > .incbin xx.dat > $ mipsisa32r6el-linux-gnu-as -o xx.o xx.s > > because even if we decide to make the default ABI configurable `ld -r -b > binary' won't be able to set all the various ABI flags a given build may > require. > > As to making the default ABI/ISA configurable I would recommend reusing > the approach we have taken with GCC, that is to provide `--with-abi=', > `--with-arch=', `--with-arch-32=' and `--with-arch-64=' configuration > options. This way the toolchain will remain consistent and will not > depend on the target triplet in a different way across packages, and also > we won't have to invent more and more complicated target triplets to > handle new cases as they arise. As I recall this design decision has > been discussed a few times over the years. > > Please note that GAS/LD are low-level tools however and in ordinary use > cases they are supposed to be driven by GCC, which will set correct flags > according to its configuration and any additional options requested. I'm > not therefore sure we need to change the semantics in the first place. > What is your use case that requires GAS/LD to be invoked directly rather > than via GCC? > > Cf. PR 25136. Yes. It is right. While, we meet some problem in other software, for example gnome glib, which use the `ld' to produce object from data in its Makefile. If the result is MIPS I, and then, ld will refused to link it with other normal object files. -- You are receiving this mail because: You are on the CC list for the bug.