Thu 21 Sep 2017 11:03:17 PM UTC, comment #20:
Okay, 7 hours later the installer was built correctly. The issue was probably a combination of cruft from previous builds and dependency rules which didn't cover all situations. I'm going to close this report as it works now.
|
Thu 21 Sep 2017 04:20:35 PM UTC, comment #19:
I just did 'make clean' and am going to start from scratch and see if it was just gremlins.
|
Thu 21 Sep 2017 03:17:18 PM UTC, comment #18:
Rik: I had the same issue that I could "fix" locally by brute forcing compilation of some of the depending packages with "make build-only-*". I tried those that hadn't been re-compiled yet since the gcc update. Unfortunately, I don't remember which one was the culprit.
|
Thu 21 Sep 2017 10:14:36 AM UTC, comment #17:
It will be slow but perhaps a make clean, rerun configure and try compiling again may be in order
what OS are running it under ? using a VM? at one stage (quite a few months ago) I had issues with gcc crashing, which ended up being that gcc was running out of memory - or at least was fixed by increasing the memory used by the VM
|
Thu 21 Sep 2017 12:27:46 AM UTC, comment #16:
With the new patch I get a long way, but then fail to build gdal because of a segmentation fault in the linker.
|
Wed 20 Sep 2017 09:08:42 PM UTC, comment #15:
Whoops- forgot to not use $(PKG) in the name and folder part
Updated patch attached
(file #41850)
|
Wed 20 Sep 2017 08:54:42 PM UTC, comment #14:
I applied the nodeps patch and tried building, but I just get a hang when trying to download the first bit of code gcc-gmp. Are the PKG_URL locations correct?
|
Wed 20 Sep 2017 05:36:01 PM UTC, comment #13:
Something like this should fix
(file #41846)
|
Wed 20 Sep 2017 04:47:40 PM UTC, comment #12:
The naming of some of the targets is a little confusing which also doesn't help :)
isl isn't required by gcc, but is needed by native-gcc.
gcc-isl is needed by build-gcc.
Assuming that isl.mk was updated to 0.16.1 (when it gets to the native-gcc build), the real issue is just that there is not a dependency for make to rebuild gcc-isl if the version number changes (which currently only happens if isl.mk is updated)
The easiest solution is to explicitly put the version number in the files, rather than depending on the version number from elsewhere.
Most of the build-xxxxx tools are already like that, so no great change.
|
Wed 20 Sep 2017 04:31:12 PM UTC, comment #11:
So it looks like the problem is that there was no ordering dependency between the isl recipe and the gcc recipe. The gcc recipe needs isl, but that dependency was being met by the existing version of 0.12. And the isl recipe, which would have updated the version to 0.16, wasn't scheduled to run until after the gcc recipe.
|
Wed 20 Sep 2017 04:22:47 PM UTC, comment #10:
Mine:
isl.mk $(PKG)_VERSION := 0.16.1
gcc-isl.mk: $(PKG)_VERSION = $(isl_VERSION)
isl changed in commit 4467: http://hg.octave.org/mxe-octave/rev/b7d6a53fa46c
|
Wed 20 Sep 2017 04:19:40 PM UTC, comment #9:
We were working in parallel to find the same thing. I'll try your solution when I finish the current MXE build.
|
Wed 20 Sep 2017 04:15:28 PM UTC, comment #8:
Looking in the src directory, I see three isl related recipes
In isl.mk,
so this older version is being selected.
gcc-isl.mk is
|
Wed 20 Sep 2017 04:14:01 PM UTC, comment #7:
just touch src/gcc-isl.mk
I guess should change those targets to not use version from another package
|
Wed 20 Sep 2017 04:10:28 PM UTC, comment #6:
I updated and then re-ran configure. I can try doing a full clean and build, but that takes a few hours.
|
Wed 20 Sep 2017 04:05:59 PM UTC, comment #5:
Actually I just realized the issue - isl was updated and gcc-isl would then change version as well, HOWEVER, it just uses isl_VERSION for its version number and so the gcc-isl.mk file didn't change its time stamp, so never got rebuilt
|
Wed 20 Sep 2017 04:02:37 PM UTC, comment #4:
I will take a look - it doesn't happen on my system, and should be pulling the gcc-isl (0.16.1)
Checking in my pkg dir, I have isl-0.16.1.tar.bz2 and it was built.
Was this a clean build after your update, or just make after updating?
|
Wed 20 Sep 2017 03:51:13 PM UTC, comment #3:
Adding John D. to the CC list since he probably understands better than anyone else what is going on with the MXE system.
|
Wed 20 Sep 2017 03:49:17 PM UTC, comment #2:
More data. I rolled back to before the latest changes to the gcc build scripts and am now rebuilding. In the log for build-gcc I see
so it is MXE, rather than the host system, which is supplying isl.
In the MXE pkg/ directory I find that the isl version is 0.12.
This also squares with the config log from build-gcc which shows
|
Wed 20 Sep 2017 03:47:02 PM UTC, comment #1:
Maybe so, when I tested the gcc-7 patch I did not have any problems, but my host system has libisl 0.18.
|
Wed 20 Sep 2017 03:43:33 PM UTC, original submission:
I updated my local MXE repo to ID 4470 which includes an update to the gcc recipe.
When I try and build I get
Inside the log file there is this
Is libisl something that the host build system needs, or is this a package that MXE needs to build before attempting to build gcc? My host machine already has libisl-0.16.1 so I think this is a dependency issue in the recipe for gcc on MXE.
|