Sun 26 Jun 2016 11:20:15 PM UTC, comment #11:
Fix by commit: 720e7a6
OSX support is now available. This makes use of native gcc that comes with OSX. It does not make use clang or clang specific options. clang support has not been added
as part of this bug fix. Maybe for future enhancement ? :)
|
Thu 16 Jun 2016 12:52:47 PM UTC, comment #10:
I have been able to get install.sh to work on OSX El Capitan using the native gcc that comes with it. I have attached the patches, which are created against hash 64cad75.
Can someone try them out and conform that it works on their OSX system ?
(file #37498, file #37499)
|
Thu 09 Jun 2016 08:15:27 PM UTC, comment #9:
> What about "sysctl -n hw.ncpu"?
> "sysctl -n machdep.cpu.core_count" does not work on my old Mac
We could use:
as that gives the same response as
(hopefully this comment comes through this time.)
|
Thu 09 Jun 2016 08:12:29 PM UTC, comment #8:
> What about "sysctl -n hw.ncpu"?
> "sysctl -n machdep.cpu.core_count" does not work on my old Mac
|
Fri 25 Mar 2016 01:02:51 AM UTC, comment #7:
> For OSX the equivalent is to use sysctl -n machdep.cpu.core_count to figure out how many cores we have.
What about "sysctl -n hw.ncpu"?
"sysctl -n machdep.cpu.core_count" does not work on my old Mac.
|
Thu 24 Mar 2016 02:38:37 AM UTC, comment #6:
The latest problem seems to be here in install.sh:
compile_to_c.new is not created and the return code is 0 so it does not exit.
This is using the native OS X compiler in /usr/bin/gcc. The OSX provided gcc does not support the -fno-gcse option. The OSX linker does not support -no-as-needed option. Based on my understanding of the option and its use, it does not seem like it is needed on OSX. Maybe someone can confirm this ?
I have also used gcc5, 5.3.0 from MacPorts, and got the same results.
|
Thu 24 Mar 2016 02:29:03 AM UTC, comment #5:
- /proc/cpuinfo was being used to set the ${jobs} variable in work/tools.sh. For OSX the equivalent is to use sysctl -n machdep.cpu.core_count to figure out how many cores we have.
- /proc/version was being used to set the ${flavor} variable. This is not portable, and so has been replaced with the use of uname -s as a condition for a case statement.
- awk related errors: this was because of awk -vmax=$max vs awk -v max=$max. Notice the space after the -v which is the more portable method.
|
Sat 20 Feb 2016 10:20:38 PM UTC, comment #4:
your extract of the man page on MacOSX looks as it would support -a exactly similar as Linux.
I quickly checked about my comment from Dec - "-p" is not even necessary to keep the executable flag... I do not see why we need "-a" at all...
|
Fri 19 Feb 2016 04:06:01 AM UTC, comment #3:
I am documenting what I plan to do, in this bug so there is a trail of steps taken:
- manually run cp -a on Linux and Mac OS X and compare results to see what it does
- replace cp -l in install.sh with ln -s ?
- see if environment variables can be set that will alter behaviour on Linux to make it POSIX compliant. Can use POSIX-compliant cp command across the platforms.
- figure out the issue with awk -v not working on Mac OS X
- replace use of /proc/cpuinfo and /proc/version with something more appropriate and portable
- check for any other Linux vs Mac OS X (and probably by extension *BSD) issues.
Relevant section of Mac OS X man page for cp(1):
|
Wed 17 Feb 2016 01:22:50 AM UTC, comment #2:
I see the following "Linuxisms" as well:
grep: /proc/version: No such file or directory
grep: /proc/cpuinfo: No such file or directory
awk: invalid -v option
when I do "install.sh -bootstrap". The awk error shows up a lot.
I will look into the errors I get and take it from there in applying a fix.
|
Thu 17 Dec 2015 06:51:15 PM UTC, comment #1:
Thanks for reporting.
What about options "-dpR"? - I think only th "-p" is really relevant to keep the executable mode flag. On the other side on my linux system this is also preserved if no arguemtn is given, so the question stays whether we could completely remove the "-a" even on non MacosX/BSD systems...
Cyril, what was the reason for "-a"?
|
Sun 22 Mar 2015 02:14:06 PM UTC, original submission:
cp of MaxOS X does not accept -a option.
Maybe this is true on BSD variants.
install.sh on old MacOS X has one more problem, but it might be useful for other BSD variants to solve this cp's option problem.
I attach a patch.
|