Make issue on mac os 10.9.4

[hegoku]

just like the image i uploaded,when i use "make",then it says:

clang: error: unknown argument: '-m128bit-long-double' [-Wunused-command-line-argument-hard-error-in-future]
clang: note: this will be a hard error (cannot be downgraded to a warning) in the future
make[2]: *** [decContext.lo] Error 1
make[1]: *** [all-recursive] Error 1
make: *** [all] Error 2

And i also use ARCHFLAGS=-Wno-error=unused-command-line-argument-hard-error-in-future make to solve the problem,but i didn't work....

[ghost]

working on it

[gavineadie]

The origin of the "clang: error: unknown argument: '-m128bit-long-double'" error is:

hc_gcc_level="`gcc -v 2>&1 | tail -1 | awk '{print $3}'`"
AC_MSG_NOTICE( [Detected GCC level is: ${hc_gcc_level}] )

because gcc (i.e. clang) emits version info that ends:

Thread model: posix

so hc_gcc_level is "posix" and not, as expected, a version like "4.2.0". But you probably figured this out by now!

[ghost]

fixed gcc/clang level detection, for the optimisation flags the work is in progress

[gavineadie]

Thanks for the start on this.

I'm walking on unfamiliar ground so please excuse any ignorance. Equal 'gcc' and 'clang' versions do not imply equal functionality. So while gcc may have implemented the flag '128bit-long-double' since v3.0.1, clang doesn't have it at v4.2.1.

Since autogen can determine the capabilities of the compiler (specifically, in this case, whether it accepts the '128bit-long-double' flag), I believe it would more reliable to append this flag conditioned on whether it was available (plus whatever other conditions are necessary), rather than on the compiler version.

If were versed in this stuff, I'd provide a patch which would be more useful than a suggestion!

[ghost]

do not worry... I am working on setting the optimisations flags based on what the compiler supports for example on clang 3.5 has different flags on apple and linux so setting flags based on the compiler kind and version does not always work

cheers enrico

[gavineadie]

.. and it's complicated, so I do appreciate your work on this. Thanks.

[dlrourke]

How are things progressing on resolving this issue? I understand how to get around the issue by removing the "-m128bit-long-double" option from line 2191 (as of 26-Jan-2015) of configure.ac, but wonder what the impact of this change is on the performance of the Hyperion version of Hercules on OS X Yosemite (and I suppose Mavericks).

[ghost]

but wonder what the impact of this change is on the performance of the Hyperion version of Hercules on OS X Yosemite

why worry since there is nothing that You/we can do about it ???

[hackob]

To bypass this error just use --enable-optimization=no as configure option:

example: $ ./configure --enable-optimization=no

[Fish-Git]

The workaround (offered by @herc4mac in another github issue) is to use:

./configure --enable-optimization="-O3 -march=native -fomit-frame-pointer" —prefix=whatever

@herc4mac is supposedly working on fixing configure.ac which is where the bug is.

[ghost]

Here is the procedure I've used to install Hyperion on OS X El Capitan:

cd util/bldlvlck

If you get an output like this one everything is fine: This utility will check the level of various utilities needed to build hercules. Checking is done against versions that are KNOWN to work. This doesn't mean a build will NOT succeed with older versions of the utilities, but will give a hint as to what package may need an upgrade if the build ever fails with some odd reason.

OK autoconf requires 2.64, found 2.69

OK automake requires 1.9, found 1.15

OK flex requires 2.5, found 2.5.35

OK gawk requires 3.0, found 4.1.3

Configured with: --prefix=/Applications/Xcode.app/Contents/Developer/usr --with-gxx-include-dir=/usr/include/c++/4.2.1 OK gcc requires 3, found 7.0.0

OK grep requires 1, found 2.5.1

Apple/Darwin ==> custom version parsing! OK m4 requires 1.4.6, found 1.4.6

OK make requires 3.79, found 3.81

OK perl requires 5.6, found 5.18.2

Apple/Darwin ==> sed changed to gsed! OK gsed requires 3.02, found 4.2

macbook:~ rkrause$

If you need a different or newer version the tool will tell you.

./autogen.sh CFLAGS="-O3 -D_FORTIFY_SOURCE=0" CC="gcc" ./configure --enable-optimization=no make

You will get some warning. But they can safely be ignored.

./hercules -f

Connect with a 3270 Emulator to hercules and ipl the system. If everything is fine perform the last step: sudo make install

That was it. For me everything was working fine and hercules is working as expected. I didn't had any problems with this procedure. And the best of all was that I didn't had to edit any file. I just had to install gawk and gsed.

I hope this helps!

[srorso]

Looking into this (don't ask why), it appears that the -m128bit-long-double determines the storage allocation for variables of the long double floating point type (128-bits versus the minimally required 96 bits). Long double is used only to hold intermediate results in the emulation of the Store System Information (STSI) instruction. The option is set only on x86 architectures. I suspect the coding in configure.ac to set this option can be removed.

[Fish-Git]

I agree, Steve.

To that end I've just committed a change (commit 9998029da3f1dddcfb01ac338792d39fc792ff37) that removes the -m128bit-long-double option altogether, so I am going to close this issue.

@herc4mac : feel free to re-open this issue if you feel it's necessary. Thanks.

[ivan-w]

I think it's simply because "clang" doesn't support this option...

Only a wild guess

--Ivan

On 10/24/2016 2:51 AM, srorso wrote:

Looking into this (don't ask why), it appears that the -m128bit-long-double determines the storage allocation for variables of the |long double| floating point type (128-bits versus the minimally required 96 bits). Long double is used only to hold intermediate results in the emulation of the Store System Information (STSI) instruction. The option is set only on x86 architectures. I suspect the coding in configure.ac to set this option can be removed.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/hercules-390/hyperion/issues/9#issuecomment-255626972, or mute the thread https://github.com/notifications/unsubscribe-auth/ABjMWwDjxaV-ZKqd-m5-D3TsTTYitueDks5q3AEbgaJpZM4CM7sT.

[Fish-Git]

I think it's simply because "clang" doesn't support this option...

That could well be true, but given Steve's findings it's simply not worth it (IMO) to go to the trouble of adding a configure.ac test to check whether the option is supported or not and then have to test for that in the auto-optimize logic (to prevent it from being used if it isn't) when simply removing the option altogether is a much more simple and straightforward solution.