I am trying to build latest fdpp : <div class="sni

Also found this mail by <a class="user-mention notranslate" data-hovercard-type="user"

For now you need build nasm-segelf manually from here: <a href="https

OK, [nasm-segelf is now an Arch Linux AUR package](<a href="http://aur.ar

Build fails with `kernel.asm:110: error: ELF format does not support segment base references` and subsequent errors.,about dosemu2/fdpp

Comments (28)

stsp commented on September 25, 2024 1

We have this temporary problem for
"unsupported" distros.
For now you need build nasm-segelf
manually from here:
https://github.com/stsp/nasm/tree/elf16
Eventually it should be pulled in automatically
during the build, for which I am going to
use xmake build system.

from fdpp.

stsp commented on September 25, 2024 1

Also found this mail by @hpax
https://lists.nasm.us/archives/nasm-devel/2023-August/000076.html

If you are really keen on helping us, the absolutely best thing would be
to fund a CDN service that we could put in front of www.nasm.us of course...

@hpax if money is the only problem,
please let me know. I am getting the
patreon donations from our respectful
users. The amount of the donations is
not too big, so I am using it exactly for
"re-donating" to the projects which are
critical for us.
nasm is critical, and dealing with fork
is an inconvenience for us and users.

from fdpp.

stsp commented on September 25, 2024

Another possibility is to ping the
nasm upstream. The last time I tried
to "sell" my patches to @hpax, he
refused to even look. :(
Maybe if more people would ping
nasm devs, they'll at least look into
the patch. It doesn't mean they have
to accept it, but at least looking in
is a must for any progress.

from fdpp.

dreirund commented on September 25, 2024

For now you need build nasm-segelf manually from here: https://github.com/stsp/nasm/tree/elf16

OK, nasm-segelf is now an Arch Linux AUR package, and AUR fdpp-git makedepends on it now.

Regards and thanks for the hint!

Another possibility is to ping the nasm upstream. The last time I tried to "sell" my patches to @hpax, he refused to even look. :(
Maybe if more people would ping nasm devs, they'll at least look into the patch.

Can you give me a "template" how to ping them? I am not a developer.

from fdpp.

dreirund commented on September 25, 2024

With nasm-segelf, my build fails with ==10946==ERROR: LeakSanitizer: detected memory leaks:

[...]
clang++ -std=c++11 -c -fno-threadsafe-statics -fpic -iquote /tmp/makepkg/build/fdpp-git/src/fdpp/fdpp/../hdr -DFDPP -DDEBUG -DWITHFAT32 -I . -I /tmp/makepkg/build/fdpp-git/src/fdpp/include/fdpp -I /tmp/makepkg/build/fdpp-git/src/fdpp/kernel -I /tmp/makepkg/build/fdpp-git/src/fdpp/fdpp -DFDPPKRNLDIR=/usr/share/fdpp -DKRNL_ELFNAME=fdppkrnl.34.10.elf -DKRNL_MAP_NAME=fdppkrnl.34.10.map -DKERNEL_VERSION="1.7 [GIT: 1.7-24-g53a1b24]" -Wall -Werror=packed-non-pod -Wno-unknown-warning-option -ggdb3 -O2 -Wno-format-invalid-specifier -Wno-c99-designator -o objtrace.o /tmp/makepkg/build/fdpp-git/src/fdpp/fdpp/objtrace.cpp
nasm -DWITHFAT32 -i/tmp/makepkg/build/fdpp-git/src/fdpp/fdpp/../hdr/ -DXCPU=186 -DFDPP -i/tmp/makepkg/build/fdpp-git/src/fdpp/kernel/ -f elf32 -o kernel.o /tmp/makepkg/build/fdpp-git/src/fdpp/kernel/kernel.asm
nasm -DWITHFAT32 -i/tmp/makepkg/build/fdpp-git/src/fdpp/fdpp/../hdr/ -DXCPU=186 -DFDPP -i/tmp/makepkg/build/fdpp-git/src/fdpp/kernel/ -f elf32 -o entry.o /tmp/makepkg/build/fdpp-git/src/fdpp/kernel/entry.asm

=================================================================
==10946==ERROR: LeakSanitizer: detected memory leaks

Direct leak of 141312 byte(s) in 736 object(s) allocated from:
    #0 0x7f83bb2e0cc1 in __interceptor_calloc /usr/src/debug/gcc/gcc/libsanitizer/asan/asan_malloc_linux.cpp:77
    #1 0x55b78b2cbb2e  (/usr/bin/nasm+0x352b2e) (BuildId: 27ec1c5f5e73315ba74d0667fbed7ec6ce0de095)
    #2 0x55b78b34a908  (/usr/bin/nasm+0x3d1908) (BuildId: 27ec1c5f5e73315ba74d0667fbed7ec6ce0de095)
    #3 0x55b78b36476c  (/usr/bin/nasm+0x3eb76c) (BuildId: 27ec1c5f5e73315ba74d0667fbed7ec6ce0de095)
    #4 0x55b78b2e3994  (/usr/bin/nasm+0x36a994) (BuildId: 27ec1c5f5e73315ba74d0667fbed7ec6ce0de095)
    #5 0x55b78b2c3ff2  (/usr/bin/nasm+0x34aff2) (BuildId: 27ec1c5f5e73315ba74d0667fbed7ec6ce0de095)
    #6 0x7f83bb045ccf  (/usr/lib/libc.so.6+0x27ccf) (BuildId: 8bfe03f6bf9b6a6e2591babd0bbc266837d8f658)

Direct leak of 7812 byte(s) in 1084 object(s) allocated from:
    #0 0x7f83bb2e1359 in __interceptor_malloc /usr/src/debug/gcc/gcc/libsanitizer/asan/asan_malloc_linux.cpp:69
    #1 0x55b78b2ca4f5  (/usr/bin/nasm+0x3514f5) (BuildId: 27ec1c5f5e73315ba74d0667fbed7ec6ce0de095)
    #2 0x55b78b3665cf  (/usr/bin/nasm+0x3ed5cf) (BuildId: 27ec1c5f5e73315ba74d0667fbed7ec6ce0de095)
    #3 0x55b78b2e3994  (/usr/bin/nasm+0x36a994) (BuildId: 27ec1c5f5e73315ba74d0667fbed7ec6ce0de095)
    #4 0x55b78b2c3ff2  (/usr/bin/nasm+0x34aff2) (BuildId: 27ec1c5f5e73315ba74d0667fbed7ec6ce0de095)
    #5 0x7f83bb045ccf  (/usr/lib/libc.so.6+0x27ccf) (BuildId: 8bfe03f6bf9b6a6e2591babd0bbc266837d8f658)

Direct leak of 2280 byte(s) in 19 object(s) allocated from:
    #0 0x7f83bb2e0cc1 in __interceptor_calloc /usr/src/debug/gcc/gcc/libsanitizer/asan/asan_malloc_linux.cpp:77
    #1 0x55b78b3c33d7  (/usr/bin/nasm+0x44a3d7) (BuildId: 27ec1c5f5e73315ba74d0667fbed7ec6ce0de095)
    #2 0x55b78b2dbb96  (/usr/bin/nasm+0x362b96) (BuildId: 27ec1c5f5e73315ba74d0667fbed7ec6ce0de095)
    #3 0x55b78b2e39d2  (/usr/bin/nasm+0x36a9d2) (BuildId: 27ec1c5f5e73315ba74d0667fbed7ec6ce0de095)
    #4 0x55b78b2c3ff2  (/usr/bin/nasm+0x34aff2) (BuildId: 27ec1c5f5e73315ba74d0667fbed7ec6ce0de095)
    #5 0x7f83bb045ccf  (/usr/lib/libc.so.6+0x27ccf) (BuildId: 8bfe03f6bf9b6a6e2591babd0bbc266837d8f658)

Direct leak of 1472 byte(s) in 736 object(s) allocated from:
    #0 0x7f83bb2e1359 in __interceptor_malloc /usr/src/debug/gcc/gcc/libsanitizer/asan/asan_malloc_linux.cpp:69
    #1 0x55b78b2cca0d  (/usr/bin/nasm+0x353a0d) (BuildId: 27ec1c5f5e73315ba74d0667fbed7ec6ce0de095)
    #2 0x55b78b2cccd3  (/usr/bin/nasm+0x353cd3) (BuildId: 27ec1c5f5e73315ba74d0667fbed7ec6ce0de095)
    #3 0x55b78b33dc21  (/usr/bin/nasm+0x3c4c21) (BuildId: 27ec1c5f5e73315ba74d0667fbed7ec6ce0de095)
    #4 0x55b78b365bfc  (/usr/bin/nasm+0x3ecbfc) (BuildId: 27ec1c5f5e73315ba74d0667fbed7ec6ce0de095)
    #5 0x55b78b2e3994  (/usr/bin/nasm+0x36a994) (BuildId: 27ec1c5f5e73315ba74d0667fbed7ec6ce0de095)
    #6 0x55b78b2c3ff2  (/usr/bin/nasm+0x34aff2) (BuildId: 27ec1c5f5e73315ba74d0667fbed7ec6ce0de095)
    #7 0x7f83bb045ccf  (/usr/lib/libc.so.6+0x27ccf) (BuildId: 8bfe03f6bf9b6a6e2591babd0bbc266837d8f658)

Direct leak of 208 byte(s) in 4 object(s) allocated from:
    #0 0x7f83bb2e1359 in __interceptor_malloc /usr/src/debug/gcc/gcc/libsanitizer/asan/asan_malloc_linux.cpp:69
    #1 0x55b78b31e90a  (/usr/bin/nasm+0x3a590a) (BuildId: 27ec1c5f5e73315ba74d0667fbed7ec6ce0de095)
    #2 0x55b78b31f743  (/usr/bin/nasm+0x3a6743) (BuildId: 27ec1c5f5e73315ba74d0667fbed7ec6ce0de095)
    #3 0x55b78b3654af  (/usr/bin/nasm+0x3ec4af) (BuildId: 27ec1c5f5e73315ba74d0667fbed7ec6ce0de095)
    #4 0x55b78b2e3994  (/usr/bin/nasm+0x36a994) (BuildId: 27ec1c5f5e73315ba74d0667fbed7ec6ce0de095)
    #5 0x55b78b2c3ff2  (/usr/bin/nasm+0x34aff2) (BuildId: 27ec1c5f5e73315ba74d0667fbed7ec6ce0de095)
    #6 0x7f83bb045ccf  (/usr/lib/libc.so.6+0x27ccf) (BuildId: 8bfe03f6bf9b6a6e2591babd0bbc266837d8f658)

Direct leak of 196 byte(s) in 12 object(s) allocated from:
    #0 0x7f83bb2e1359 in __interceptor_malloc /usr/src/debug/gcc/gcc/libsanitizer/asan/asan_malloc_linux.cpp:69
    #1 0x55b78b2cc827  (/usr/bin/nasm+0x353827) (BuildId: 27ec1c5f5e73315ba74d0667fbed7ec6ce0de095)
    #2 0x55b78b31219b  (/usr/bin/nasm+0x39919b) (BuildId: 27ec1c5f5e73315ba74d0667fbed7ec6ce0de095)
    #3 0x55b78b31288a  (/usr/bin/nasm+0x39988a) (BuildId: 27ec1c5f5e73315ba74d0667fbed7ec6ce0de095)
    #4 0x55b78b37a9ed  (/usr/bin/nasm+0x4019ed) (BuildId: 27ec1c5f5e73315ba74d0667fbed7ec6ce0de095)
    #5 0x55b78b37c106  (/usr/bin/nasm+0x403106) (BuildId: 27ec1c5f5e73315ba74d0667fbed7ec6ce0de095)
    #6 0x55b78b37f41b  (/usr/bin/nasm+0x40641b) (BuildId: 27ec1c5f5e73315ba74d0667fbed7ec6ce0de095)
    #7 0x55b78b37f4a6  (/usr/bin/nasm+0x4064a6) (BuildId: 27ec1c5f5e73315ba74d0667fbed7ec6ce0de095)
    #8 0x55b78b3812f6  (/usr/bin/nasm+0x4082f6) (BuildId: 27ec1c5f5e73315ba74d0667fbed7ec6ce0de095)
    #9 0x55b78b382156  (/usr/bin/nasm+0x409156) (BuildId: 27ec1c5f5e73315ba74d0667fbed7ec6ce0de095)
    #10 0x55b78b382fc6  (/usr/bin/nasm+0x409fc6) (BuildId: 27ec1c5f5e73315ba74d0667fbed7ec6ce0de095)
    #11 0x55b78b383e36  (/usr/bin/nasm+0x40ae36) (BuildId: 27ec1c5f5e73315ba74d0667fbed7ec6ce0de095)
    #12 0x55b78b384786  (/usr/bin/nasm+0x40b786) (BuildId: 27ec1c5f5e73315ba74d0667fbed7ec6ce0de095)
    #13 0x55b78b385656  (/usr/bin/nasm+0x40c656) (BuildId: 27ec1c5f5e73315ba74d0667fbed7ec6ce0de095)
    #14 0x55b78b3864ea  (/usr/bin/nasm+0x40d4ea) (BuildId: 27ec1c5f5e73315ba74d0667fbed7ec6ce0de095)
    #15 0x55b78b397d06  (/usr/bin/nasm+0x41ed06) (BuildId: 27ec1c5f5e73315ba74d0667fbed7ec6ce0de095)
    #16 0x55b78b2e4ec4  (/usr/bin/nasm+0x36bec4) (BuildId: 27ec1c5f5e73315ba74d0667fbed7ec6ce0de095)
    #17 0x55b78b2c3ff2  (/usr/bin/nasm+0x34aff2) (BuildId: 27ec1c5f5e73315ba74d0667fbed7ec6ce0de095)
    #18 0x7f83bb045ccf  (/usr/lib/libc.so.6+0x27ccf) (BuildId: 8bfe03f6bf9b6a6e2591babd0bbc266837d8f658)

Direct leak of 147 byte(s) in 9 object(s) allocated from:
    #0 0x7f83bb2e1359 in __interceptor_malloc /usr/src/debug/gcc/gcc/libsanitizer/asan/asan_malloc_linux.cpp:69
    #1 0x55b78b2cc827  (/usr/bin/nasm+0x353827) (BuildId: 27ec1c5f5e73315ba74d0667fbed7ec6ce0de095)
    #2 0x55b78b31219b  (/usr/bin/nasm+0x39919b) (BuildId: 27ec1c5f5e73315ba74d0667fbed7ec6ce0de095)
    #3 0x55b78b312c7d  (/usr/bin/nasm+0x399c7d) (BuildId: 27ec1c5f5e73315ba74d0667fbed7ec6ce0de095)
    #4 0x55b78b2e40b7  (/usr/bin/nasm+0x36b0b7) (BuildId: 27ec1c5f5e73315ba74d0667fbed7ec6ce0de095)
    #5 0x55b78b2c3ff2  (/usr/bin/nasm+0x34aff2) (BuildId: 27ec1c5f5e73315ba74d0667fbed7ec6ce0de095)
    #6 0x7f83bb045ccf  (/usr/lib/libc.so.6+0x27ccf) (BuildId: 8bfe03f6bf9b6a6e2591babd0bbc266837d8f658)

Direct leak of 55 byte(s) in 1 object(s) allocated from:
    #0 0x7f83bb2e1359 in __interceptor_malloc /usr/src/debug/gcc/gcc/libsanitizer/asan/asan_malloc_linux.cpp:69
    #1 0x7f83bb0c13de in __strdup (/usr/lib/libc.so.6+0xa33de) (BuildId: 8bfe03f6bf9b6a6e2591babd0bbc266837d8f658)
    #2 0x6975622f676b7064  (<unknown module>)

Direct leak of 45 byte(s) in 1 object(s) allocated from:
    #0 0x7f83bb2e1359 in __interceptor_malloc /usr/src/debug/gcc/gcc/libsanitizer/asan/asan_malloc_linux.cpp:69
    #1 0x55b78b2cc6b8  (/usr/bin/nasm+0x3536b8) (BuildId: 27ec1c5f5e73315ba74d0667fbed7ec6ce0de095)
    #2 0x55b78b4433ab  (/usr/bin/nasm+0x4ca3ab) (BuildId: 27ec1c5f5e73315ba74d0667fbed7ec6ce0de095)
    #3 0x55b78b3b4fee  (/usr/bin/nasm+0x43bfee) (BuildId: 27ec1c5f5e73315ba74d0667fbed7ec6ce0de095)
    #4 0x55b78b2c3fa1  (/usr/bin/nasm+0x34afa1) (BuildId: 27ec1c5f5e73315ba74d0667fbed7ec6ce0de095)
    #5 0x7f83bb045ccf  (/usr/lib/libc.so.6+0x27ccf) (BuildId: 8bfe03f6bf9b6a6e2591babd0bbc266837d8f658)

Indirect leak of 58880 byte(s) in 1472 object(s) allocated from:
    #0 0x7f83bb2e0cc1 in __interceptor_calloc /usr/src/debug/gcc/gcc/libsanitizer/asan/asan_malloc_linux.cpp:77
    #1 0x55b78b36430b  (/usr/bin/nasm+0x3eb30b) (BuildId: 27ec1c5f5e73315ba74d0667fbed7ec6ce0de095)
    #2 0x55b78b2e3994  (/usr/bin/nasm+0x36a994) (BuildId: 27ec1c5f5e73315ba74d0667fbed7ec6ce0de095)
    #3 0x55b78b2c3ff2  (/usr/bin/nasm+0x34aff2) (BuildId: 27ec1c5f5e73315ba74d0667fbed7ec6ce0de095)
    #4 0x7f83bb045ccf  (/usr/lib/libc.so.6+0x27ccf) (BuildId: 8bfe03f6bf9b6a6e2591babd0bbc266837d8f658)

Indirect leak of 172 byte(s) in 18 object(s) allocated from:
    #0 0x7f83bb2e1359 in __interceptor_malloc /usr/src/debug/gcc/gcc/libsanitizer/asan/asan_malloc_linux.cpp:69
    #1 0x55b78b2ca4f5  (/usr/bin/nasm+0x3514f5) (BuildId: 27ec1c5f5e73315ba74d0667fbed7ec6ce0de095)
    #2 0x55b78b3c34b9  (/usr/bin/nasm+0x44a4b9) (BuildId: 27ec1c5f5e73315ba74d0667fbed7ec6ce0de095)
    #3 0x55b78b2dbb96  (/usr/bin/nasm+0x362b96) (BuildId: 27ec1c5f5e73315ba74d0667fbed7ec6ce0de095)
    #4 0x55b78b2e39d2  (/usr/bin/nasm+0x36a9d2) (BuildId: 27ec1c5f5e73315ba74d0667fbed7ec6ce0de095)
    #5 0x55b78b2c3ff2  (/usr/bin/nasm+0x34aff2) (BuildId: 27ec1c5f5e73315ba74d0667fbed7ec6ce0de095)
    #6 0x7f83bb045ccf  (/usr/lib/libc.so.6+0x27ccf) (BuildId: 8bfe03f6bf9b6a6e2591babd0bbc266837d8f658)

SUMMARY: AddressSanitizer: 212579 byte(s) leaked in 4092 allocation(s).
make[1]: *** [makefile:189: kernel.o] Error 1
make[1]: *** Waiting for unfinished jobs....
make[1]: Leaving directory '/tmp/makepkg/build/fdpp-git/src/fdpp/fdpp'
make: *** [makefile:13: all] Error 2

I have compiled nasm-segelf with --enable-sanitizer (not really knowing what it does). With --disable-sanitizer this error is gone.

But I get x86_64-linux-gnu-ld: command not found:

[...]
clang++ -std=c++11 -c -fno-threadsafe-statics -fpic -iquote /tmp/makepkg/build/fdpp-git/src/fdpp/fdpp/../hdr -DFDPP -DDEBUG -DWITHFAT32 -I . -I /tmp/makepkg/build/fdpp-git/src/fdpp/include/fdpp -I /tmp/makepkg/build/fdpp-git/src/fdpp/kernel -I /tmp/makepkg/build/fdpp-git/src/fdpp/fdpp -DFDPPKRNLDIR=/usr/share/fdpp -DKRNL_ELFNAME=fdppkrnl.34.10.elf -DKRNL_MAP_NAME=fdppkrnl.34.10.map -DKERNEL_VERSION="1.7 [GIT: 1.7-24-g53a1b24]" -Wall -Werror=packed-non-pod -Wno-unknown-warning-option -ggdb3 -O2 -Wno-format-invalid-specifier -Wno-c99-designator -o thunks_a.o /tmp/makepkg/build/fdpp-git/src/fdpp/fdpp/thunks_a.cc
x86_64-linux-gnu-ld -melf_i386 -static -Map=fdppkrnl.34.10.map -o fdppkrnl.34.10.elf \
	--emit-relocs  -T/tmp/makepkg/build/fdpp-git/src/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
bash: line 1: x86_64-linux-gnu-ld: command not found
make[1]: *** [makefile:85: fdppkrnl.34.10.elf] Error 127

Regards!

from fdpp.

stsp commented on September 25, 2024

Leaks are an upstream bugs.
I build master with --enable-sanitizer
and get the same errors even when
fdpp cannot be compiled by that nasm.
So if you want, you may report them
to upstream.

As for x86_64-linux-gnu-ld you can
try make CROSS_LD=ld when building
fdpp.

from fdpp.

stsp commented on September 25, 2024

Can you give me a "template" how to ping them? I am not a developer.

I wanted to, but found that
http://bugzilla.nasm.us/
is disabled, and issues on
https://github.com/netwide-assembler/nasm
are disabled as well.
So seems like nasm upstream is
actively trying to avoid being pinged
for this problem. :)

from fdpp.

stsp commented on September 25, 2024

OK, [nasm-segelf is now an Arch Linux AUR package](http://aur.archlinux.org/packages
/nasm-segelf-git), and AUR fdpp-git
makedepends on it now.

Thanks, you may also want to
update the dependency list for fdpp.
lld should be replaced with binutils.
If aur is supposed to build dosemu2
for arm64 or other arches, it would
be good to also build-dep on cross-binutils,
so that x86_64-linux-gnu-ld to become
"available". If cross-builds are not in
a scope, use CROSS_LD=ld suggestion
above.

from fdpp.

dreirund commented on September 25, 2024

As for x86_64-linux-gnu-ld you can try make CROSS_LD=ld when building

Yes, this works.

If AUR is supposed to build dosemu2 for arm64 or other arches

It is not intended for cross compilation; if you build for ARM then the build would be carried out on ARM.

The "AUR" is intended to serve package recipes to be built and installed locally on a user's computer.

Would fdpp build on other architectures? If so, in which? Then I can add them to the arch-entry in the PKGBUILD.

dependency list for fdpp. lld should be replaced with binutils.

Thanks, done.

Also found ↗ this mail by @hpax:

If you are really keen on helping us, the absolutely best thing would be to fund a CDN service that we could put in front of www.nasm.us of course...

@hpax if money is the only problem, please let me know. [...]

Maybe you write the person via email? I don't know if it reads here …

I close this issue now since the build error has been clarified as not applicable to fdpp.

from fdpp.

stsp commented on September 25, 2024

Would fdpp build on other architectures?

Yes, but for that you need
cross-binutils. Like x86_64-linux-gnu-ld
on arm.

from fdpp.

dreirund commented on September 25, 2024

> Would fdpp build on other architectures? Yes, but for that you need cross-binutils. Like x86_64-linux-gnu-ld on arm.

I mean, would fdpp build natively on other architectures. e.g. would it build _for_ aarch64 _on_ aarch64. I think no cross compilation tools are needed then because it is native. If I am wrong, I would like to learn why. Regards!

from fdpp.

stsp commented on September 25, 2024

If I am wrong, I would like to learn why.

Because even on arm we need to
build some things for DOS, for which
on arm the cross-binutils is needed.

from fdpp.

stsp commented on September 25, 2024

Lets keep that open in case
someone else also hits that.

from fdpp.

dreirund commented on September 25, 2024

Lets keep that open in case someone else also hits that.

Closed issues can still be found via search.
The correct logic I think would be to close this, and to close this as "not planned" since it is not fdpps fault.

from fdpp.

stsp commented on September 25, 2024

Maybe you write the person via email? I don't know if it reads here …

See it from here:
#172
The discussion declined exactly when
I started to do the actual work, rather
than just chatting.
But I am no longer surprised with such
events. For example glibc community
made me a public torture for trying to
send any patches to them. They even
went to the private e-mails like "drop
all your patches immediately and
publically, or no one of us will ever
reply to you" and so on. Of course
they never looked into the patches,
they just tried to come up with some
"arguments", threats and abuses to
force me to drop them and apologize
for ever sending them. This is likely
because the public media journalists
seeks around the large communities
like glibc's, so if they are too negative
publically, they may end up as U.Drepper.
I think this is why they tried to press me
that much, but in private, to publically drop
all my patches. :)
And it all makes the challenge even funnier
to get things done nevertheless.

from fdpp.

dreirund commented on September 25, 2024

If I am wrong, I would like to learn why.

Because even on arm we need to build some things for DOS, for which on arm the cross-binutils is needed.

OK, I now added to the ↗ PKGBUILD (= Arch Linux package build recipe)

if [ "${CARCH}" == "x86_64" ]; then
  export CROSS_LD='ld'
else
  makedepends+=("x86_64-elf-binutils")
  export CROSS_LD='x86_64-elf-ld'
fi

but I don't know if it is correct (and I cannot test).
Can you comment on it?

Regards!

from fdpp.

stsp commented on September 25, 2024

I am not using arch.
If the package name and the
linker name are valid, then this
is supposed to work.
However, a much easier and reliable
check is to just assume that the
cross-compiler is always needed.
Remove the x86_64 special case,
always install cross-ld, and make
sure it works (and leave it as such).

from fdpp.

dreirund commented on September 25, 2024

I am not using arch. If the package name and the linker name are valid, then this is supposed to work. However, a much easier and reliable check is to just assume that the cross-compiler is always needed. Remove the x86_64 special case, always install cross-ld, and make sure it works (and leave it as such).

The bash scripting is fine and reliable.

What I really want to ask is if CROSS_LD='x86_64-elf-ld' would be correct, since without specifying it wants to call x86_64-linux-gnu-ld which is a different name, but I don't know which specific package provides that. I don't really know what the words in the executable name mean.

It is easier to not need the package that provides the x86_64-linux-gnu-ld executable, since on Arch the package x86_64-elf-binutils is not a default package and even not part of the repositories, but only in the AUR, so it needs to be compiled locally before usage. So it is more straight forward to use default binutils' ld if possible.

Regards!

from fdpp.

stsp commented on September 25, 2024

I think this can work, but the
only reliable check is to build
that cross-ld and do ld -m?,
which will show the list of
supported targets.
If elf_i386 is in the list, then
we are good, as presumably
the list of targets won't change
when someone builds it on an
actual aarch64.

from fdpp.

dreirund commented on September 25, 2024

On Thu, 02 Nov 2023 10:50:08 -0700, Stas Sergeev ***@***.***> wrote: `ld -m?`, which will show the list of supported targets. If `elf_i386` is in the list, then we are good,

OK, thanks, yes that is the case: `x86_64-elf-ld -m?`: ``` ld: unrecognised emulation mode: ? Supported emulations: elf_x86_64 elf_i386 elf_iamcu elf32_x86_64 ``` (Note that `-m?` seems to cause an error, though.) Thank you, now I think that my solution should work.

from fdpp.

hpax commented on September 25, 2024

On November 3, 2023 2:09:57 AM PDT, dreirund ***@***.***> wrote: On Thu, 02 Nov 2023 10:50:08 -0700, Stas Sergeev ***@***.***> wrote: > `ld -m?`, which will show the list of supported targets. > If `elf_i386` is in the list, then we are good, OK, thanks, yes that is the case: `x86_64-elf-ld -m?`: ``` ld: unrecognised emulation mode: ? Supported emulations: elf_x86_64 elf32_x86_64 elf_i386 elf_iamcu i386pep i386pe elf64bpf ``` (Note that `-m?` seems to cause an error, though.) Thank you, now I think that my solution should work.

As I have started, I want to have an agreement with the GNU people about the ABI, including the approach as opposed to just the implementation. HJL is probably the main person.

from fdpp.

stsp commented on September 25, 2024

What kind of agreement when there is
nothing to upstream to binutils?
HjL kindly allowed you to use RELC, I
promise. :)

from fdpp.

stsp commented on September 25, 2024

Please, @hpax be reasonable.
If there is something missing, like
"agreement" or whatever, then
please spell that out properly.
Spell out the technical problem,
proposed solution, how can I help,
and so on.
If the only "solution" is to ignore
my patch and not do any work on
your spec for 5 years (which is
exactly as the things are now), then
perhaps you are up to something
wrong?
I've got a solution in just 1 week!
And you don't even look.
Is this even polite to not look into
the proposed patches?

from fdpp.

hpax commented on September 25, 2024

On November 4, 2023 10:23:37 AM PDT, Stas Sergeev ***@***.***> wrote: Please, @hpax be reasonable. If there is something missing, like "agreement" or whatever, then please spell that out properly. Spell out the technical problem, proposed solution, how can I help, and so on. If the only "solution" is to ignore my patch and not do any work on your spec for 5 years (which is exactly as the things are now), then perhaps you are up to something wrong? I've got a solution in just 1 week! And you don't even look. Is this even polite to not look into the proposed patches?

The disconnect here is that you are trying to do bottom-up engineering for your use case, but standardization calls for a top-down approach. It's not an issue of *how* to implement something but *what* to implement. Calculated symbols are very powerful indeed, but they have issues; for example, at least with gas they lose any notion of a base section. This is the same disconnect that killed the momentum 5 years ago; if you want this to happen as anything other than a private fork you will need to have some patience and talk to the people involved in the psABI definition (there is a mailing list for the i386 psABI which really is the right forum.)

from fdpp.

stsp commented on September 25, 2024

have issues; for example, at least with gas they lose any notion of a base section.

Maybe in gas they have issues.
They are even disabled there.
Why not to use them in nasm first,
fix gas next? Not sure why the
issue with gas makes my nasm
patch unreviewable.

talk to the people involved in the psABI definition

Talk about what exactly?
About upstreaming the custom reloc
scheme? Or about gas issues with
RELC? What exactly do you want to
talk to them about?
I definitely don't want to tell them
"hi, I added RELC support to nasm,
but Hans asks me to talk to you first" -
this is not conclusive.

from fdpp.

stsp commented on September 25, 2024

Or maybe you want me to ask them
about the proposed spec updates?
Which I'd rather ask you first, as you
are the author of it.
Anyway, its unclear what do you want
me to ask them about.

from fdpp.

stsp commented on September 25, 2024

The disconnect here is that you are trying to do bottom-up engineering
for your use case, but standardization calls for a top-down approach.

I think you are putting things horribly
upside-down. Be your spec backed up
by 1024+ existing use-cases and ready-to-use
tools, then I'd probably tolerate your
abuse of pie mode (among other things),
and adjust my use-case instead.
But as the things are now, your spec is
orphaned. I am absolutely convinced
that its YOU, who should talk to me, to
elks, to ia16-gcc and all other potential
adopters. Cover all our needs in your spec.
Bring us to some common ground by
suggesting the adjustments to our
use-cases. Cooperate with us and make
your spec backed up by all the existing
use-cases. And now, with my patch,
also by the nasm. :)
THAT is a standardization.
Telling me to ask HjL about something
when I don't even know what to ask, is
not a standardization. Saying that the
disconnect with some potential adopter
(presumably ia16-gcc?) killed your momentum
5 years ago and now I also kill it, is nothing
but an attempt to keep your spec orphaned
forever.
If you want to present your spec to HjL,
then first make sure it suits the real-world
use cases. That alone would be a good
motivation in his eyes.

from fdpp.

stsp commented on September 25, 2024

For example when linux provides the
alternatives to posix apis, I am chosing
linux's in most cases. These apis are
practical, whereas posix apis are commonly
broken. Linus got to realize that real-world
use-cases, and not the paper-work, should
start the standardization processes.

from fdpp.

Build fails with `kernel.asm:110: error: ELF format does not support segment base references` and subsequent errors. about fdpp HOT 28 CLOSED

Comments (28)

Related Issues (20)

Recommend Projects

React

Vue.js

Typescript

TensorFlow

Django

Laravel

D3

Recommend Topics

javascript

web

server

Machine learning

Visualization

Game

Recommend Org

Facebook

Microsoft

Google

Alibaba

D3

Tencent