camdusbmidi: build the class on arm and aarch64 - #1111
Closed
bsek wants to merge 1 commit into
Closed
Conversation
The arm rule was disabled in e4b16b1 over a link failure. That failure is now just two wrong flags reaching ld: lld names the ARM emulations armelf/aarch64elf rather than elf_arm/elf_aarch64, and LDFLAGS carries a -Wl, option on aarch64 that ld cannot parse. Compile-tested on both; the driver blob itself is still untested.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
camdusbmidi.classhas not been built for ARM since e4b16b1, whichdisabled the rule with:
That is no longer what happens. The object links fine; what fails is two
flags reaching
ldin a form it cannot parse.1. lld emulation name.
camd/mmakefile.srcpassed-m elf_$(AROS_TARGET_CPU).That is correct for i386 and x86_64 only — lld calls the ARM emulations
armelfandaarch64elf:2.
-Wl,in LDFLAGS on aarch64.%rule_link_binaryhands$(LDFLAGS)straight to
$(KERNEL_LD), but LDFLAGS is written for the compiler driver.On aarch64
config/make.cfg.inadds-Wl,--allow-multiple-definitionforclang's weak
__aros_libreq_marker, so:The other targets never hit this because none of them put a
-Wl,option inLDFLAGS.
With both fixed, the arm rule is re-enabled and an aarch64 rule added.
Testing
Compile-tested on both, each with
poseidonusb.bin.oand the class binarydeleted first to force a full relink:
raspi-arm-smp(llvm-armhf, lld 11) —Building Module AROS/Classes/USB/camdusbmidi.classraspi-aarch64(llvm-aarch64-20)The resulting
poseidonusb.bin.oexports the symbols the class expects(
_binary_poseidonusb_start/_end/_size).What this does not cover
Only that it builds.
camd/poseidonusb.c— the CAMD driver blob thatcamd.library loads and relocates — has never been run on any architecture; it
went in as "highly experimental and needs testing" (ea4b45f), and m68k
still uses the hardcoded hunk blob in
CAMDDriver.c. So this makes the classavailable on ARM, it does not claim USB MIDI works there. No behaviour change
on i386/x86_64/ppc/m68k: the emulation mapping falls through to the old
elf_$(cpu)for them, and their LDFLAGS contain no-Wl,options.