Building FDPP on Aarch64 about fdpp

[stsp]

Try export LEX=flex before running
make. Maybe you have flex installed.
If not - install.

I have no idea why you need to change
nasm flags. We have aarch64 build on
LP, so the fewer changes you do, the
more chances to succeed.

[Nobody-Special]

Alright... I don't know what to say. It's kinda awkward, but after exporting LEX variable I tried to reproduce the bug which happened during linking.

Previously LD said that elf_i386 is unsupported and listed all aarch64 targets (e.g. aarch64linux, aarch64elf32...) - hence changes on line 76 and 81 - but then it complained about wrong elf format. Changing nasm format flag to elf64 seamed to fix it.

Unexpectedly, after exporting LEX variable and changing nasm format flag to elf32, it worked.

So I did git reset --hard and only removed -melf_i386 flags from LD. Now works like a charm.

Everything compiled. Clang constantly is screaming about macro redefinitions (but I know that I don't need to worry about those warnings).

The only thing that I'm unsure is one of the last messages:

clang++ -o libfdpp.so.32.10 blockio.o break.o chario.o dosfns.o dsk.o error.o fatdir.o fatfs.o fattab.o fcbfns.o hmamgr.o inthndlr.o ioctl.o memmgr.o misc.o newstuff.o network.o nls.o strings.o sysclk.o systime.o task.o config.o initoem.o main.o inithma.o dyninit.o initdisk.o initclk.o prf.o share.o smalloc.o farhlp_sta.o elf.o thunks.o thunks_c.o thunks_a.o thunks_p.o dosobj.o objhlp.o ctors.o farhlp.o objtrace.o -shared -Wl,-Bsymbolic -Wl,--build-id=sha1 -Wl,-soname=libfdpp.so.32.10 -L/data/data/com.termux/files/usr/lib -lelf
Have 84 undefined symbols

Is this to be expected?

[stsp]

Yes, this is informational-only msg.
Please run file *.elf to check the arch
of the resulting file after you removed
melf_i386.

[stsp]

Clang constantly is screaming about macro redefinitions

Which ones?

[stsp]

So what CROSS_LD was that?
lld?

[Nobody-Special]

Yes. LLD 16.0.6

[Nobody-Special]

Mea culpa. By trying to edit a comment, I've deleted it by accident. Do you want me to write down the list of macro redefinitions once again?

Recreation of deleted comment:

file ../fdpp/fdpp/*.elf:

../fdpp/fdpp/fdppkrnl.32.10.elf:
ELF 32-bit LSB executable,
Intel 80386, version 1 (SYSV),
statically linked, not stripped

---

Clang constantly is screaming about macro redefinitions

Which ones?

• O_SYNC
• O_TRUNC
• O_LARGEFILE
• O_CREATE
• O_ACCMODE
• O_RDWR
• O_RDONLY
• O_WRONLY

[stsp]

I've got your comment via email.
Does lld list the supported targets and
what option should be used?

[Nobody-Special]

I've played a little bit with $CROSS_LD.

Under Gnu ld (GNU Binutils 2.40) compilation fails:

ld -melf_i386 -static -Map=fdppkrnl.32.10.map -o fdppkrnl.32.10.elf \
-T/data/data/com.termux/files/home/Projects/fdpp/fdpp/kernel.ld kernel.o entry.o io.o console.o serial.o printer.o execrh.o nlssupt.o procsupt.o dosidle.o int2f.o nls_hc.o intr.o irqstack.o cpu.o plt.o cdata.o floppy.o rdpcclk.o wrpcclk.o wratclk.o --defsym=DOS_PSP=0x60

ld: unrecognised emulation mode: elf_i386
Supported emulations:
aarch64linux,
aarch64elf,
aarch64elf32,
aarch64elf32b,
aarch64elfb,
armelf,
armelfb,
aarch64linuxb,
aarch64linux32,
aarch64linux32b,
armelfb_linux_eabi,
armelf_linux_eabi

make[1]: *** [makefile:76: fdppkrnl.32.10.elf] Error 1
make[1]: Leaving directory '/data/data/com.termux/files/home/Projects/fdpp/fdpp'
make: *** [makefile:13: all] Error 2

While under ld.lld (clang/llvm) compiles without truble with no modifications to makefile.

[stsp]

Yes, that's the point.
cross-ld should be lld.
How it happened to be something else?

[stsp]

Macros should now be fixed.

[Nobody-Special]

I wish I would know. I've tried unsetting $CROSS_LD and reinstalling binutils, as well as looking for exports... but to no avail.

I think this issue can be closed now. Unless you want it to be mentioned in # 225 as I think it might be a road blocker.

Edit: Ups. My bad. You already did it.

[stsp]

But lld is not the part of binutils, that's
the problem.
What road blocker?

[Nobody-Special]

But lld is not the part of binutils, that's the problem.

But ld is. In short, i've tried reinstalling binutils to see if in Termux it sets $CROSS_LD to ld.

---

What raod blocker?

In my understanding if you want to migrate FDPP to GCC, you don't want a dependency on llvm through lld and instead use ld.

I'm not sure if this logic is sound, so please correct me if I'm wrong.

[stsp]

But ld is.

But its not needed.
makefile takes it only as a fallback,
when lld is unavailable. Such fallback
only works when you build for the same
arch, and otherwise error out as you've
seen before installed lld.

In my understanding if you want to migrate FDPP to GCC

I don't want to.
This is an entirely optional task to support
more compilers.

you don't want a dependency on llvm through lld and instead use ld.

No.
lld provides the support for cross-targets
out of the box. While binutils need a
separate package per every arch, and
such cross-packages are not always
available.
So lld and clang just do the work, and
binutils+gcc do not.

[Nobody-Special]

Ok. Thanks for clarification :)