Partially support for darwin-64 #64
Conversation
There was a problem hiding this comment.
Sorry for the delay! With this change, binutils no longer builds in GUB on GNU/Linux, because of idiosyncrasies in GUB code for packaging which relied on that tar flag. Merging this change and keeping GUB able to build LilyPond on GNU/Linux requires cleaning up that, which I'll look into soon.
|
No worries! That’s good to know, I thought I had checked to make sure Linux still worked but I must have missed that. I see two easy solutions and one hard solution:
Option 1 would be the easiest and would not add any additional dependencies for running GUB on macOS. Option 2 would probably make building on Linux vs Darwin more consistent, but also would be more involved to do correctly. I can implement the change either way, so if you (or someone else) has a strong opinion on which solution would be better please speak up, otherwise I will probably use option 1 as it is the most straightforward. |
|
Today I dived into the packaging code to investigate on what you named Option 3, and I estimated this would mean rewriting the handling of GUP subpackages. This is not as hard as brain surgery, but given my available time it may take me 2 weeks before coming back with a patch. |
|
@jmander, I just pushed a patch which restores the use of However, are you sure that this flag was the issue? When I specifically tested building As I have noticed this, I am going to submit a separate patch fixing this issue as well as (potentially) updating |
| @@ -341,9 +342,23 @@ def execute (self, logger): | |||
| globs.append ('no-globs-for-%(dest)s' % locals ()) | |||
There was a problem hiding this comment.
IIUC it's because of this idiosyncracy that the --ignore-failed Tar flag is useful, maybe not only for linux-x86:binutils (this was the first package on which I got a consistent build failure without this flag).
Thanks, with this patch (and also all changes of this PR) GUB build is going much further (though I'm afraid the recent GCC upgrade on my GNU/Linux distro from 7.x to 8.3 break something). |
There was a problem hiding this comment.
Some OS-dependent casing should be added in GUB and/or the wrapping makefile to prevent this kind of error on GNU/Linux:
Traceback (most recent call last):
File "test-lily/upload.py", line 277, in <module>
main ()
File "test-lily/upload.py", line 264, in main
cmds = upload_binaries (repo, version_tup, version_db)
File "test-lily/upload.py", line 108, in upload_binaries
format = formats[platform]
KeyError: 'darwin-64'
make[1]: *** [lilypond.make:160: print-success] Error 1
make[1]: Leaving directory '/home/gub/gub'
make: *** [GNUmakefile:26: lilypond] Error 2
I got this error by running make lilypond.
I'll try finding time tomorrow to look into this.
| @@ -32,6 +32,7 @@ def argv0_relocation (): | |||
| 'linux-ppc', | |||
| 'darwin-ppc', | |||
| 'darwin-x86', | |||
| 'darwin-64', | |||
There was a problem hiding this comment.
@Jahrme, as Darwin64 can't be built on GNU/Linux yet, what do you think about replacing this list with a dictionary with current list a keys and supported building host OS/architecture as values? I'd provide a patch, but I don't know which targets you can easily build on Darwin 64, is it everything listed here, or only Darwin 64, or something in between?
|
I’m using some of this work in my attempt to get 64-bit builds working. Thanks! |
This is my initial work in getting GUB to build a
darwin-64(x86_64-apple-darwin) target in preparation for Apple discontinuing support for 32-bit binaries.The next step in successfully building for
darwin-64is adjusting/fixing the Perl spec to compile on macOS.