Closed stsp closed 4 years ago
@skitt What will the new version number be? Can I set Depends: binutils-djgpp (>> 2.33.1-1ubuntu1+1.1)
in my control file?
edit: also, will your binutils include symlinks from i586-*
-> i386-*
? If not then I can add a separate package for that.
@jwt27 the Focal version ended up being 2.34-1ubuntu1+1.3. My package includes i586-*
symlinks.
Thanks. My updated ppa should be live now.
We still have some problems:
jw@jw-UbuntuVM:~$ echo 'int main(){}' > nop.c
jw@jw-UbuntuVM:~$ i386-pc-msdosdjgpp-gcc nop.c
/usr/lib/gcc/i386-pc-msdosdjgpp/9.2.0/../../../../i386-pc-msdosdjgpp/bin/ld: /usr/lib/gcc/i386-pc-msdosdjgpp/9.2.0/../../../../i386-pc-msdosdjgpp/lib/libc.a(crt1.o):(.text+0xb8): undefined reference to `_environ'
/usr/lib/gcc/i386-pc-msdosdjgpp/9.2.0/../../../../i386-pc-msdosdjgpp/bin/ld: /usr/lib/gcc/i386-pc-msdosdjgpp/9.2.0/../../../../i386-pc-msdosdjgpp/lib/libc.a(crt1.o):(.text+0x168): undefined reference to `_environ'
/usr/lib/gcc/i386-pc-msdosdjgpp/9.2.0/../../../../i386-pc-msdosdjgpp/bin/ld: /usr/lib/gcc/i386-pc-msdosdjgpp/9.2.0/../../../../i386-pc-msdosdjgpp/lib/libc.a(crt1.o):(.text+0x3ab): undefined reference to `_environ'
/usr/lib/gcc/i386-pc-msdosdjgpp/9.2.0/../../../../i386-pc-msdosdjgpp/bin/ld: /usr/lib/gcc/i386-pc-msdosdjgpp/9.2.0/../../../../i386-pc-msdosdjgpp/lib/libc.a(getenv.o):(.text+0x3): undefined reference to `_environ'
/usr/lib/gcc/i386-pc-msdosdjgpp/9.2.0/../../../../i386-pc-msdosdjgpp/bin/ld: /usr/lib/gcc/i386-pc-msdosdjgpp/9.2.0/../../../../i386-pc-msdosdjgpp/lib/libc.a(putenv.o):(.text+0x43): undefined reference to `_environ'
/usr/lib/gcc/i386-pc-msdosdjgpp/9.2.0/../../../../i386-pc-msdosdjgpp/bin/ld: /usr/lib/gcc/i386-pc-msdosdjgpp/9.2.0/../../../../i386-pc-msdosdjgpp/lib/libc.a(putenv.o):(.text+0x227): more undefined references to `_environ' follow
collect2: error: ld returned 1 exit status
Looks like you're building from the official binutils sources right? Unfortunately that doesn't work, djgpp binutils requires special patches that for some reason aren't being upstreamed. For one the ldscripts end up broken, they are missing the _environ
symbol. There are probably other things that break in more subtle ways.
You can find these patches at ftp://ftp.delorie.com/pub/djgpp/current/v2gnu/bnu2331s.zip
in the djgpp/
directory.
We still have some problems:
jw@jw-UbuntuVM:~$ echo 'int main(){}' > nop.c jw@jw-UbuntuVM:~$ i386-pc-msdosdjgpp-gcc nop.c /usr/lib/gcc/i386-pc-msdosdjgpp/9.2.0/../../../../i386-pc-msdosdjgpp/bin/ld: /usr/lib/gcc/i386-pc-msdosdjgpp/9.2.0/../../../../i386-pc-msdosdjgpp/lib/libc.a(crt1.o):(.text+0xb8): undefined reference to `_environ' /usr/lib/gcc/i386-pc-msdosdjgpp/9.2.0/../../../../i386-pc-msdosdjgpp/bin/ld: /usr/lib/gcc/i386-pc-msdosdjgpp/9.2.0/../../../../i386-pc-msdosdjgpp/lib/libc.a(crt1.o):(.text+0x168): undefined reference to `_environ' /usr/lib/gcc/i386-pc-msdosdjgpp/9.2.0/../../../../i386-pc-msdosdjgpp/bin/ld: /usr/lib/gcc/i386-pc-msdosdjgpp/9.2.0/../../../../i386-pc-msdosdjgpp/lib/libc.a(crt1.o):(.text+0x3ab): undefined reference to `_environ' /usr/lib/gcc/i386-pc-msdosdjgpp/9.2.0/../../../../i386-pc-msdosdjgpp/bin/ld: /usr/lib/gcc/i386-pc-msdosdjgpp/9.2.0/../../../../i386-pc-msdosdjgpp/lib/libc.a(getenv.o):(.text+0x3): undefined reference to `_environ' /usr/lib/gcc/i386-pc-msdosdjgpp/9.2.0/../../../../i386-pc-msdosdjgpp/bin/ld: /usr/lib/gcc/i386-pc-msdosdjgpp/9.2.0/../../../../i386-pc-msdosdjgpp/lib/libc.a(putenv.o):(.text+0x43): undefined reference to `_environ' /usr/lib/gcc/i386-pc-msdosdjgpp/9.2.0/../../../../i386-pc-msdosdjgpp/bin/ld: /usr/lib/gcc/i386-pc-msdosdjgpp/9.2.0/../../../../i386-pc-msdosdjgpp/lib/libc.a(putenv.o):(.text+0x227): more undefined references to `_environ' follow collect2: error: ld returned 1 exit status
Looks like you're building from the official binutils sources right? Unfortunately that doesn't work, djgpp binutils requires special patches that for some reason aren't being upstreamed. For one the ldscripts end up broken, they are missing the
_environ
symbol. There are probably other things that break in more subtle ways. You can find these patches atftp://ftp.delorie.com/pub/djgpp/current/v2gnu/bnu2331s.zip
in thedjgpp/
directory.
Ah, yes, thanks! I had noted at some point that I needed to take those patches into account, but then it slipped my mind... And I was trying to find the source of the _environ
issue in the GCC patches :-(.
I’ve added the binutils patches, adapted them to 2.34 (there are very few changes), but they fail some of the built-in test suite. I’m looking into that...
And I was trying to find the source of the
_environ
issue in the GCC patches :-(.
Ha, yes it's not immediately obvious that symbols can come from ldscripts. That took me a while to figure out too.
The djgpp patches don't introduce any additional failures for me. The tests I see failing are:
FAIL: copy with setting section flags 3
FAIL: dotnet-assemblies (ordinary x86 DLL)
FAIL: objdump -p (build)
and all the windres
tests but I think that is to be expected (even though they are listed as unexpected)
I noticed binutils-djgpp 1.4 with the target-specific patches is now in Focal. Thank you @skitt! Everything works so I think I we can close this now.
I noticed binutils-djgpp 1.4 with the target-specific patches is now in Focal. Thank you @skitt! Everything works so I think I we can close this now.
You’re welcome, thanks for checking! I meant to ping you to let you know, but didn’t.
Oh and I meant to ask, did you find out what caused the failing test cases you were seeing?
Oh and I meant to ask, did you find out what caused the failing test cases you were seeing?
Yes, changes to bfd
in binutils 2.34 which resulted in null dereferences in code added by the DJGPP-specific patches.
Awesome, that is very quick. My Focal VM hasn't even finished installing yet. I don't think we need a transitional package then for such a short time frame.