search

jwt27 / build-gcc

Shell scripts to build various gcc cross-compilers (primarily djgpp)
https://jw.h4ck.me/debian/
GNU General Public License v3.0
41 stars 9 forks source link

fails on OSX High Sierra #3

Closed TheFakeMontyOnTheRun closed 5 years ago

TheFakeMontyOnTheRun commented 5 years ago

Hello! First of all, thanks for keeping this project going - it's awesome!

I did some tests with High Sierra, but apparently, it will get stuck with tar: Plenty of files giving me the same error, ending with

x tar-1.30/configure: Can't unlink already-existing object
x tar-1.30/THANKS: Can't unlink already-existing object
tar: Error exit delayed from previous errors.

I was trying to build gcc-8.2.0 as my regular user. Gonna try with Ubuntu and OSX Lion tonight.

jwt27 commented 5 years ago

Thanks for reporting this. That part (building tar) is untested on mac, and may fail on bsd too. I'm unable to look into this right now, if you can fix this (or work around it by using apple's tar), please submit a PR.

jwt27 commented 5 years ago

I've removed the dependency on GNU tar, which I hope resolves this issue. Can you try building again?

TheFakeMontyOnTheRun commented 5 years ago

Updated my Mac a while ago. Only have Mojave and Lion (on a older Mac) for testing - is it still worth the test?

(sorry for the delay)

jwt27 commented 5 years ago

Testing on any version of OSX is welcome since I don't believe that's been done in a while. Therefore I also don't know if this issue was specific to High Sierra.

TheFakeMontyOnTheRun commented 5 years ago

Hey - tried on my OSX Lion machine, but I'm having all kinds of issues due to it's age and some certificates not playing nice with HTTPS. That test will have to wait.

Regarding Mojave, I tried building DJGPP, but had issues with the first download (binutils? Sorry, can't exactly remember - will report it later for you). I'm currently building ia16-gcc and will report back very soon.

TheFakeMontyOnTheRun commented 5 years ago

Got myself a new Mac and it's gonna be a lot easier to try this. Also, got a new issue: you use nproc, but that's not available on OSX. From what I understand, it's equivalent to this: sysctl -n hw.physicalcpu

TheFakeMontyOnTheRun commented 5 years ago

Building now fails at the unpack-gcc.sh stage, with status 254.

TheFakeMontyOnTheRun commented 5 years ago

building binutils-2.32 seems to succeed, but fails because the script attempts to copy i586-pc-msdosdjgpp-gcc and i586-pc-msdosdjgpp-g++ into it's final place. Gonna test the other components and add into this comment as I continue.

Same goes for djgpp. gdb fails due to libreadline missing tilde.h

jwt27 commented 5 years ago

Also, got a new issue: you use nproc, but that's not available on OSX. From what I understand, it's equivalent to this: sysctl -n hw.physicalcpu

Thank you, that's fixed now.

Building now fails at the unpack-gcc.sh stage, with status 254.

No error messages? I don't see anything that could cause a status 254. Does it fail at the point where unpack-gcc.sh is invoked, or in the script itself? If the error occurs inside unpack-gcc.sh, you could try adding --verbose-shell to line 199 in build-djgpp.sh like so:

sh unpack-gcc.sh --verbose-shell --no-djgpp-source ../../download/$(basename ${GCC_ARCHIVE}) || exit 1

gdb fails due to libreadline missing tilde.h

gdb was being built with --with-system-readline, IIRC that was necessary for mingw at one point but no longer is. I removed that flag now, can you try again? As an aside, you may want to use gdb 8.2.1 or earlier since 8.3 seems to crash on djgpp executables.

TheFakeMontyOnTheRun commented 5 years ago

One clue that might help with the unpack stage is that later I went to build my fork of the original repo, by Andrew Wu, and it complained about the LZMA library. I went on to install xz, zx and lzip - and everything worked. Gonna try again building your fork and perhaps it will work this time.

Thank you for still caring. We need to keep this toolchain alive :)

jwt27 commented 5 years ago

Ah yes, you'll definitely need tar, xz, bzip2 and unzip. Newlib requires gzip too. Those aren't listed in the readme. Now I'll have to figure out what the package names for those programs are on ubuntu, fedora, and mingw32, so I can update that section.

TheFakeMontyOnTheRun commented 5 years ago

Gonna try on Ubuntu - it's been a while since I last tried. BTW, the version of binutils required by the djgpp target on master is no longer available. Tried the 2.32 release with Andrew Wu's repo with success. Maybe this is a good replacement.

jwt27 commented 5 years ago

I don't follow - binutils 2.32 should be the default already (bnu232s.zip), and it's available on the mirror we're using: http://www.mirrorservice.org/sites/ftp.delorie.com/pub/djgpp/current/v2gnu/bnu232s.zip

TheFakeMontyOnTheRun commented 5 years ago

My bad - it's fetching the correct files. I'll report later on with more concise data, instead of rushing and stumbling along the way.

edit: finished. Works flawlessly on Ubuntu.

jwt27 commented 5 years ago

I now have travis-ci set up to run automated test builds, and I'm seeing this error on OSX:
https://travis-ci.org/jwt27/build-gcc/jobs/558755001

Running unpack-gcc.sh
tar: Unrecognized archive format
tar: Error exit delayed from previous errors.
Cannot unpack GCC sources
The command "./script/test.sh" exited with 1.

Do you get the same message?

TheFakeMontyOnTheRun commented 5 years ago

You probably needs to add support for LZMA. I suspect you need xz, zx and lzip. Have you installed those?

jwt27 commented 5 years ago

xz is installed, and that should be enough to decompress .tar.xz files. Seems like tar on OSX doesn't understand the --use=xz parameter which unpack-gcc.sh wants to use. I committed a workaround in 6ed5f4e, and this builds on travis: https://travis-ci.org/jwt27/build-gcc/builds/559100603 I think that resolves this issue. Can you confirm that it works on your end?

TheFakeMontyOnTheRun commented 5 years ago

Sorry for taking so long to answer. And with fresh checkout, everything seems to be working fine 👍