Discussion:
[hercules-390] Installation problem with Hyperion
dev@vietfeir.com [hercules-390]
2017-02-14 09:05:43 UTC
Permalink
I thought I'd have a look at Hyperion and tried to install it on a Linux virtual machine. I got through most of it then when I tried to do make install, it complained about not being able to find a certain SoftFloat file.


How do I install SoftFloat. The makefile for SoftFloat just installs it in my local directory There doesn't seem to be a make install target so I'm not sure what to do after that.


Here is the error message:


ieee.c:81:30: fatal error: SoftFloat-milieu.h: No such file or directory
compilation terminated.


In the latest release of SoftFloat I downloaded,I cannot find this file all all. Am I missing some instructions somewhere?


Dennis
Ivan Warren ivan@vmfacility.fr [hercules-390]
2017-02-14 09:57:28 UTC
Permalink
Post by ***@vietfeir.com [hercules-390]
ieee.c:81:30: fatal error: SoftFloat-milieu.h: No such file or directory
compilation terminated.
In the latest release of SoftFloat I downloaded,I cannot find this
file all all. Am I missing some instructions somewhere?
Good luck with the new batshit crazy build instructions !

hercules no longer uses standard SoftFloat but a custom version (no
issue there) which has to be located at specific locations relative to
the source and build *PARENT* directories (don't ask - it's insane).

The build instructions can be found in the file : README.BuildUNIX.txt
in the hyperion source directory and there is a build helper (1Stop)
which kind of steps everywhere in your directories, requires you to have
an active internet access, etc... You'll also need a new version of
cmake (>=3.2) , which most linux distributions do not yet carry, so
you'll have to build it for yourself.

Forget about the simple "autogen.sh/configure/make/make install" ...
These days are apparently long gone.

(It took me about a few hours to get it straight).

--Ivan


[Non-text portions of this message have been removed]
'\'Fish\' (David B. Trout)' david.b.trout@gmail.com [hercules-390]
2017-02-14 17:58:34 UTC
Permalink
Ivan Warren wrote:

[...]
Post by Ivan Warren ***@vmfacility.fr [hercules-390]
Forget about the simple "autogen.sh/configure/make/make install" ...
These days are apparently long gone.
FYI:

My Fish-Git Hyperion fork (https://github.com/Fish-Git/hyperion) still builds via the same autogen.sh, configure, make and make install method that Hercules has been using for the last, oh, 15+ years or more now?

It also has all of Bob Polmanter's latest ECPS:VM assist fixes too, as well as a couple of other minor fixes and enhancements.
--
"Fish" (David B. Trout)
Software Development Laboratories
http://www.softdevlabs.com
mail: ***@softdevlabs.com
Maarten Hoes hoes.maarten@gmail.com [hercules-390]
2017-02-14 18:53:00 UTC
Permalink
FYI:

I've been having *at least* as much trouble getting fish-git-hyperion to
build on Linux as I have with official-hyperion. I managed once, but have
forgotten since how I did it: but it looks like you want the SoftFloat
binaries installed in a subdirectory of the hyperion source git repo ?


/* start-of-rant */

The issues I have had with building recent versions of both
official-hyperion and fish-git-hyperion seems to be the total inflexibility
of where you want your sources (both softfloat and hyperion) and binaries
located, including but not limited to 'in source' and 'out of source'
builds. To my untrained eye, the root cause seems to be that people
(including me, for that matter) simply do not know enough about both the
cmake and autotools build systems to make that happen (or describe in the
build instructions how to do it). It would be great if I could tell cmake
to 'install' softfloat in any random directory of my own choosing, and then
tell autotools/configure to go look for them there (or perhaps even tell
configure to look for softfloat in the softfloat build directory without
the need of 'installing 'softfloat at all).

/* end-rant */



- Maarten




On Tue, Feb 14, 2017 at 6:58 PM, ''Fish' (David B. Trout)'
Post by '\'Fish\' (David B. Trout)' ***@gmail.com [hercules-390]
[...]
Post by Ivan Warren ***@vmfacility.fr [hercules-390]
Forget about the simple "autogen.sh/configure/make/make install" ...
These days are apparently long gone.
My Fish-Git Hyperion fork (https://github.com/Fish-Git/hyperion) still
builds via the same autogen.sh, configure, make and make install method
that Hercules has been using for the last, oh, 15+ years or more now?
It also has all of Bob Polmanter's latest ECPS:VM assist fixes too, as
well as a couple of other minor fixes and enhancements.
--
"Fish" (David B. Trout)
Software Development Laboratories
http://www.softdevlabs.com
Maarten Hoes hoes.maarten@gmail.com [hercules-390]
2017-02-14 19:21:09 UTC
Permalink
Oh, and now that I'm ranting and raving anyway: when it comes to doing a
build on Linux, I currently run into the following issues on Fedora 25 (GCC
6.3.1):


1.)
For fish-git-hyperion:

Building Hyperion with a 'debug build' fails with the following message (a
non-debug build completes without errors) :

trace.c: In function 's390_trace_pc':
trace.c:606:6: warning: variable 'eamode' set but not used
[-Wunused-but-set-variable]
int eamode;
^~~~~~
CC vector.lo
CC vm.lo
CC vmd250.lo
CC vstore.lo
CC w32util.lo
CC xstore.lo
CCLD libherc.la

*** Warning: Linking the shared library libherc.la against the
*** static library decNumber/lib/libdecNumber64d.a is not portable!

*** Warning: Linking the shared library libherc.la against the
*** static library SoftFloat/lib/libSoftFloat64d.a is not portable!

*** Warning: Linking the shared library libherc.la against the
*** static library telnet/lib/libtelnet64d.a is not portable!
gcc: error: decNumber/lib/libdecNumber64d.a: No such file or directory
gcc: error: telnet/lib/libtelnet64d.a: No such file or directory
Makefile:1892: recipe for target 'libherc.la' failed
make[2]: *** [libherc.la] Error 1
make[2]: Leaving directory
'/home/maarten/src/fish-git-hyperion-topdir/hyperion'
Makefile:2293: recipe for target 'all-recursive' failed
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory
'/home/maarten/src/fish-git-hyperion-topdir/hyperion'
Makefile:1709: recipe for target 'all' failed
make: *** [all] Error 2



2.)
For official-hyperion:

Building SoftFloat fails with this message :


Scanning dependencies of target SoftFloat
[ 0%] Building C object CMakeFiles/SoftFloat.dir/source/s_add128.c.o
/home/maarten/src/hyperion-topdir/SoftFloat-3a/source/s_add128.c:48:2:
error: return type is an incomplete type
softfloat_add128( uint64_t a64, uint64_t a0, uint64_t b64, uint64_t b0 )
^~~~~~~~~~~~~~~~
/home/maarten/src/hyperion-topdir/SoftFloat-3a/source/s_add128.c: In
function ‘softfloat_add128’:
/home/maarten/src/hyperion-topdir/SoftFloat-3a/source/s_add128.c:50:20:
error: storage size of ‘z’ isn’t known
struct uint128 z;
^
/home/maarten/src/hyperion-topdir/SoftFloat-3a/source/s_add128.c:54:12:
warning: ‘return’ with a value, in function returning void
return z;
^
/home/maarten/src/hyperion-topdir/SoftFloat-3a/source/s_add128.c:48:2:
note: declared here
softfloat_add128( uint64_t a64, uint64_t a0, uint64_t b64, uint64_t b0 )
^~~~~~~~~~~~~~~~
CMakeFiles/SoftFloat.dir/build.make:62: recipe for target
'CMakeFiles/SoftFloat.dir/source/s_add128.c.o' failed
make[2]: *** [CMakeFiles/SoftFloat.dir/source/s_add128.c.o] Error 1
CMakeFiles/Makefile2:67: recipe for target 'CMakeFiles/SoftFloat.dir/all'
failed
make[1]: *** [CMakeFiles/SoftFloat.dir/all] Error 2
Makefile:149: recipe for target 'all' failed
make: *** [all] Error 2



- Maarten
Post by Maarten Hoes ***@gmail.com [hercules-390]
I've been having *at least* as much trouble getting fish-git-hyperion to
build on Linux as I have with official-hyperion. I managed once, but have
forgotten since how I did it: but it looks like you want the SoftFloat
binaries installed in a subdirectory of the hyperion source git repo ?
/* start-of-rant */
The issues I have had with building recent versions of both
official-hyperion and fish-git-hyperion seems to be the total inflexibility
of where you want your sources (both softfloat and hyperion) and binaries
located, including but not limited to 'in source' and 'out of source'
builds. To my untrained eye, the root cause seems to be that people
(including me, for that matter) simply do not know enough about both the
cmake and autotools build systems to make that happen (or describe in the
build instructions how to do it). It would be great if I could tell cmake
to 'install' softfloat in any random directory of my own choosing, and then
tell autotools/configure to go look for them there (or perhaps even tell
configure to look for softfloat in the softfloat build directory without
the need of 'installing 'softfloat at all).
/* end-rant */
- Maarten
On Tue, Feb 14, 2017 at 6:58 PM, ''Fish' (David B. Trout)'
Post by '\'Fish\' (David B. Trout)' ***@gmail.com [hercules-390]
[...]
Post by Ivan Warren ***@vmfacility.fr [hercules-390]
Forget about the simple "autogen.sh/configure/make/make install" ...
These days are apparently long gone.
My Fish-Git Hyperion fork (https://github.com/Fish-Git/hyperion) still
builds via the same autogen.sh, configure, make and make install method
that Hercules has been using for the last, oh, 15+ years or more now?
It also has all of Bob Polmanter's latest ECPS:VM assist fixes too, as
well as a couple of other minor fixes and enhancements.
--
"Fish" (David B. Trout)
Software Development Laboratories
http://www.softdevlabs.com
'\'Fish\' (David B. Trout)' david.b.trout@gmail.com [hercules-390]
2017-02-14 21:54:29 UTC
Permalink
[...]
Post by Maarten Hoes ***@gmail.com [hercules-390]
1.)
Building Hyperion with a 'debug build' fails with the following
trace.c:606:6: warning: variable 'eamode' set but not used [-Wunused-
but-set-variable]
int eamode;
^~~~~~
It doesn't happen for me, but then I use clang, not gcc. In any case. I'll certainly look into that and get it fixed for you just as fast as I can. Thanks for reporting it.


[...]
Post by Maarten Hoes ***@gmail.com [hercules-390]
*** Warning: Linking the shared library libherc.la against the
*** static library decNumber/lib/libdecNumber64d.a is not portable!
*** Warning: Linking the shared library libherc.la against the
*** static library SoftFloat/lib/libSoftFloat64d.a is not portable!
*** Warning: Linking the shared library libherc.la against the
*** static library telnet/lib/libtelnet64d.a is not portable!
Unfortunately there's nothing I can do to suppress those messages. Be assured however that they are nothing to worry about. All external packages ARE built with -fPIC specified.
Post by Maarten Hoes ***@gmail.com [hercules-390]
gcc: error: decNumber/lib/libdecNumber64d.a: No such file or directory
gcc: error: telnet/lib/libtelnet64d.a: No such file or directory
<snip>

Please refer to my previous reply. For now (until I can fix it), you need to perform a ONE TIME "Debug" build (and "install") of each external package. Within a few days however (hopefully) the above errors should be a thing of the past. I'm just EXTREMELY busy right now.

Again, please see my previous reply for more information.
--
"Fish" (David B. Trout)
Software Development Laboratories
http://www.softdevlabs.com
mail: ***@softdevlabs.com
'\'Fish\' (David B. Trout)' david.b.trout@gmail.com [hercules-390]
2017-02-16 00:02:36 UTC
Permalink
Post by '\'Fish\' (David B. Trout)' ***@gmail.com [hercules-390]
[...]
Post by Maarten Hoes ***@gmail.com [hercules-390]
1.)
Building Hyperion with a 'debug build' fails with the following
trace.c:606:6: warning: variable 'eamode' set but not used [-Wunused-
but-set-variable]
int eamode;
^~~~~~
It doesn't happen for me, but then I use clang, not gcc. In any case.
I'll certainly look into that and get it fixed for you just as fast as
I can. Thanks for reporting it.
Fix in commit 43051e4dc5ce9beaa2a83b4164604af126150303.


[...]
Post by '\'Fish\' (David B. Trout)' ***@gmail.com [hercules-390]
Post by Maarten Hoes ***@gmail.com [hercules-390]
gcc: error: decNumber/lib/libdecNumber64d.a: No such file or
directory
Post by Maarten Hoes ***@gmail.com [hercules-390]
gcc: error: telnet/lib/libtelnet64d.a: No such file or directory
<snip>
Fixed in commit c08f1fde7db1e1a4cd6a4b772375850a015595b7.


Also fixed: _dynamic_version.h issue (commit 29586eb1e21528ab81f776412e0f8aa132f279ca): The need for dynamically constructed "_dynamic_version.h" header was eliminated by passing all version components via command line.


Maarten, I would really appreciate it if you would try again and confirm for me that the issues you described (ranted about(*)) are now fixed.

Thanks!
--
"Fish" (David B. Trout)
Software Development Laboratories
http://www.softdevlabs.com
mail: ***@softdevlabs.com

(*) Don't worry! I realize your "rant" wasn't meant as a personal attack but rather simply a means of venting your frustration regarding the recent changes that complicated something that used to be simple and straightforward. I understand completely. And more than that, I *agree* with your frustration/rant.

Which was why I made the changes I recently did to try and address the issues you raised such that NOW, hopefully, things are back to once again being simple and straightforward.

At least in my fork anyway. ;-)
Maarten Hoes hoes.maarten@gmail.com [hercules-390]
2017-02-16 09:25:48 UTC
Permalink
Hi,


Sorry, I must have messed up somewhere. I removed my local hyperion git
source directory, and did a fresh 'git clone'. The build completes without
errors now.


Sorry for the noise.


- Maarten
Hi,
I did a 'git pull', and a 'out of source' build. The configure line I used
configure --enable-debug --enable-getoptwrapper --enable-ipv6
--enable-cckd-bzip2 --enable-het-bzip2 --enable-object-rexx
--enable-regina-rexx --enable-interlocked-access-facility-2=yes
--enable-optimization=no
I got the build error [1] listed below.
- Maarten
[1]
make[2]: Entering directory '/home/maarten/src/fish-git-
hyperion-topdir/build'
CC hsys.lo
CCLD libhercs.la
CC codepage.lo
CC hdl.lo
CC hexdumpe.lo
CC hostinfo.lo
CC hscutl.lo
CC hscutl2.lo
CC hsocket.lo
CC hthreads.lo
CC logger.lo
CC logmsg.lo
CC memrchr.lo
CC parser.lo
CC pttrace.lo
CC version.lo
In file included from ../hyperion/hercules.h:116:0,
../hyperion/version.h:41:21: error: 'DYNAMIC_VERSION' undeclared (first
use in this function)
#define VERSION DYNAMIC_VERSION
^
../hyperion/msgenu.h:144:56: note: in expansion of macro 'VERSION'
#define MSG( id, s, ... ) #id s " " id "\n", ## __VA_ARGS__
^~~~~~~~~~~
../hyperion/version.c:783:30: note: in expansion of macro 'MSG'
hprintf( httpfd, MSG( HHC01413, "I", prog, VERSION,
^~~
../hyperion/version.h:41:21: note: each undeclared identifier is reported
only once for each function it appears in
#define VERSION DYNAMIC_VERSION
^
../hyperion/msgenu.h:144:56: note: in expansion of macro 'VERSION'
#define MSG( id, s, ... ) #id s " " id "\n", ## __VA_ARGS__
^~~~~~~~~~~
../hyperion/version.c:783:30: note: in expansion of macro 'MSG'
hprintf( httpfd, MSG( HHC01413, "I", prog, VERSION,
^~~
In file included from ../hyperion/hercules.h:148:0,
../hyperion/version.c:784:17: error: 'VERS_MAJ' undeclared (first use in
this function)
VERS_MAJ, VERS_INT, VERS_MIN, VERS_BLD ));
^
../hyperion/msgenu.h:144:56: note: in definition of macro 'MSG'
#define MSG( id, s, ... ) #id s " " id "\n", ## __VA_ARGS__
^~~~~~~~~~~
../hyperion/version.c:784:27: error: 'VERS_INT' undeclared (first use in
this function)
VERS_MAJ, VERS_INT, VERS_MIN, VERS_BLD ));
^
../hyperion/msgenu.h:144:56: note: in definition of macro 'MSG'
#define MSG( id, s, ... ) #id s " " id "\n", ## __VA_ARGS__
^~~~~~~~~~~
../hyperion/version.c:784:37: error: 'VERS_MIN' undeclared (first use in
this function)
VERS_MAJ, VERS_INT, VERS_MIN, VERS_BLD ));
^
../hyperion/msgenu.h:144:56: note: in definition of macro 'MSG'
#define MSG( id, s, ... ) #id s " " id "\n", ## __VA_ARGS__
^~~~~~~~~~~
../hyperion/version.c:784:47: error: 'VERS_BLD' undeclared (first use in
this function)
VERS_MAJ, VERS_INT, VERS_MIN, VERS_BLD ));
^
../hyperion/msgenu.h:144:56: note: in definition of macro 'MSG'
#define MSG( id, s, ... ) #id s " " id "\n", ## __VA_ARGS__
^~~~~~~~~~~
Makefile:2243: recipe for target 'version.lo' failed
make[2]: *** [version.lo] Error 1
make[2]: Leaving directory '/home/maarten/src/fish-git-
hyperion-topdir/build'
Makefile:2293: recipe for target 'all-recursive' failed
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory '/home/maarten/src/fish-git-
hyperion-topdir/build'
Makefile:1709: recipe for target 'all' failed
make: *** [all] Error 2
On Thu, Feb 16, 2017 at 1:02 AM, ''Fish' (David B. Trout)'
Post by '\'Fish\' (David B. Trout)' ***@gmail.com [hercules-390]
[...]
Post by Maarten Hoes ***@gmail.com [hercules-390]
1.)
Building Hyperion with a 'debug build' fails with the following
trace.c:606:6: warning: variable 'eamode' set but not used [-Wunused-
but-set-variable]
int eamode;
^~~~~~
It doesn't happen for me, but then I use clang, not gcc. In any case.
I'll certainly look into that and get it fixed for you just as fast as
I can. Thanks for reporting it.
Fix in commit 43051e4dc5ce9beaa2a83b4164604af126150303.
[...]
Post by Maarten Hoes ***@gmail.com [hercules-390]
gcc: error: decNumber/lib/libdecNumber64d.a: No such file or
directory
Post by Maarten Hoes ***@gmail.com [hercules-390]
gcc: error: telnet/lib/libtelnet64d.a: No such file or directory
<snip>
Fixed in commit c08f1fde7db1e1a4cd6a4b772375850a015595b7.
Also fixed: _dynamic_version.h issue (commit
29586eb1e21528ab81f776412e0f8aa132f279ca): The need for dynamically
constructed "_dynamic_version.h" header was eliminated by passing all
version components via command line.
Maarten, I would really appreciate it if you would try again and confirm
for me that the issues you described (ranted about(*)) are now fixed.
Thanks!
--
"Fish" (David B. Trout)
Software Development Laboratories
http://www.softdevlabs.com
(*) Don't worry! I realize your "rant" wasn't meant as a personal attack
but rather simply a means of venting your frustration regarding the recent
changes that complicated something that used to be simple and
straightforward. I understand completely. And more than that, I *agree*
with your frustration/rant.
Which was why I made the changes I recently did to try and address the
issues you raised such that NOW, hopefully, things are back to once again
being simple and straightforward.
At least in my fork anyway. ;-)
'\'Fish\' (David B. Trout)' david.b.trout@gmail.com [hercules-390]
2017-02-14 21:35:23 UTC
Permalink
Post by Maarten Hoes ***@gmail.com [hercules-390]
I've been having *at least* as much trouble getting fish-git
hyperion to build on Linux as I have with official-hyperion.
I managed once, but have forgotten since how I did it: but it
looks like you want the SoftFloat binaries installed in a
subdirectory of the hyperion source git repo ?
Yes. Please see the README.EXTPKG document:

https://github.com/Fish-Git/hyperion/blob/master/README.EXTPKG

Also please refer to the "Building and Installing" web page (https://fish-git.github.io/html/hercinst.html) too, especially the "Building External Packages" section.

My fork comes with everything needed to do a normal Release (non-Debug) build of x86/x64 Hercules.


[...]
Post by Maarten Hoes ***@gmail.com [hercules-390]
It would be great if I could tell cmake to 'install' softfloat
in any random directory of my own choosing,
And you can. The 'build' script allows you to install into what directory you want. Please refer to the BUILDING document that each external package comes with.
Post by Maarten Hoes ***@gmail.com [hercules-390]
and then tell autotools/configure to go look for them there
With Fish-Git Hyperion you don't need to tell autotools/configure anything. You just build like normal, just like Hercules has been built on Linux for the past 15 years.
Post by Maarten Hoes ***@gmail.com [hercules-390]
(or perhaps even tell configure to look for softfloat in the
softfloat build directory without the need of 'installing
'softfloat at all).
In normal situation there should not be any "installing" involved whatsoever. Fish-Git Hyperion should build normally out-of-the-box, just like it normally has for many years.

The only exception to that rule (which I'm in the process of fixing) is if you need to build a "Debug" version of Hercules. Right now that requires you to first build (and "install") a debug version of each external package first, before you can build Hercules. Note too that since the current set of external packages are considered to be quite stable, this should be considered a "one time" preparation step. Once the debug versions of each external package are built and "installed" into the appropriate Fish-Git Hyperion subdirectory, you NEVER need to do it again (since external packages RARELY change).

If you just want to build a normal Release (optimized) build of Fish-Git Hyperion however, then you don't need to do anything at all: you just build it like normal out-of-the-box.

Within the next few days or so (I'm quite busy with helping someone right now) I will be adding pre-built "Debug" versions of all external packages to my Fish-Git Hyperion repository, so in the very near future you should NOT have to pre-build ANYTHING. Once I'm done, Fish-Git Hyperion will come distributed with pre-built version for both Release *AND* Debug builds, so that you will then not need to do ANYTHING AT ALL. Just build like normal. Just like you have been doing for years and years.

But due to my current workload it may take me a few days to get that done.

I fully understand and apologize for your frustration Maarten. Truly I do. I'm working as fast as I can.

Remember that I'm doing this all on my own too, without the help of anyone else.

I'm not sure what the current official hyperion development team's excuse is.
--
"Fish" (David B. Trout)
Software Development Laboratories
http://www.softdevlabs.com
mail: ***@softdevlabs.com
Maarten Hoes hoes.maarten@gmail.com [hercules-390]
2017-02-15 12:42:04 UTC
Permalink
Hi,


Thanks for the quick and elaborate reply. For me personally though, there
is no need to hurry (as if end-users could somehow make 'demands' on how
volunteer developers choose to spend their spare time to begin with), as I
really don't use Hercules/Hyperion for anything other than a personal
spare-time plaything.


Thanks again,


- Maarten



On Tue, Feb 14, 2017 at 10:35 PM, ''Fish' (David B. Trout)'
Post by '\'Fish\' (David B. Trout)' ***@gmail.com [hercules-390]
Post by Maarten Hoes ***@gmail.com [hercules-390]
I've been having *at least* as much trouble getting fish-git
hyperion to build on Linux as I have with official-hyperion.
I managed once, but have forgotten since how I did it: but it
looks like you want the SoftFloat binaries installed in a
subdirectory of the hyperion source git repo ?
https://github.com/Fish-Git/hyperion/blob/master/README.EXTPKG
Also please refer to the "Building and Installing" web page (
https://fish-git.github.io/html/hercinst.html) too, especially the
"Building External Packages" section.
My fork comes with everything needed to do a normal Release (non-Debug)
build of x86/x64 Hercules.
[...]
Post by Maarten Hoes ***@gmail.com [hercules-390]
It would be great if I could tell cmake to 'install' softfloat
in any random directory of my own choosing,
And you can. The 'build' script allows you to install into what directory
you want. Please refer to the BUILDING document that each external package
comes with.
Post by Maarten Hoes ***@gmail.com [hercules-390]
and then tell autotools/configure to go look for them there
With Fish-Git Hyperion you don't need to tell autotools/configure
anything. You just build like normal, just like Hercules has been built on
Linux for the past 15 years.
Post by Maarten Hoes ***@gmail.com [hercules-390]
(or perhaps even tell configure to look for softfloat in the
softfloat build directory without the need of 'installing
'softfloat at all).
In normal situation there should not be any "installing" involved
whatsoever. Fish-Git Hyperion should build normally out-of-the-box, just
like it normally has for many years.
The only exception to that rule (which I'm in the process of fixing) is if
you need to build a "Debug" version of Hercules. Right now that requires
you to first build (and "install") a debug version of each external package
first, before you can build Hercules. Note too that since the current set
of external packages are considered to be quite stable, this should be
considered a "one time" preparation step. Once the debug versions of each
external package are built and "installed" into the appropriate Fish-Git
Hyperion subdirectory, you NEVER need to do it again (since external
packages RARELY change).
If you just want to build a normal Release (optimized) build of Fish-Git
Hyperion however, then you don't need to do anything at all: you just build
it like normal out-of-the-box.
Within the next few days or so (I'm quite busy with helping someone right
now) I will be adding pre-built "Debug" versions of all external packages
to my Fish-Git Hyperion repository, so in the very near future you should
NOT have to pre-build ANYTHING. Once I'm done, Fish-Git Hyperion will come
distributed with pre-built version for both Release *AND* Debug builds, so
that you will then not need to do ANYTHING AT ALL. Just build like normal.
Just like you have been doing for years and years.
But due to my current workload it may take me a few days to get that done.
I fully understand and apologize for your frustration Maarten. Truly I do.
I'm working as fast as I can.
Remember that I'm doing this all on my own too, without the help of anyone else.
I'm not sure what the current official hyperion development team's excuse is.
--
"Fish" (David B. Trout)
Software Development Laboratories
http://www.softdevlabs.com
Maarten Hoes hoes.maarten@gmail.com [hercules-390]
2017-02-14 19:48:37 UTC
Permalink
Hi,

On Tue, Feb 14, 2017 at 6:58 PM, ''Fish' (David B. Trout)'
Post by '\'Fish\' (David B. Trout)' ***@gmail.com [hercules-390]
My Fish-Git Hyperion fork (https://github.com/Fish-Git/hyperion) still
builds via the same autogen.sh, configure, make and make install method
that Hercules has been using for the last, oh, 15+ years or more now?
/* non-rant, I hope ? */

The issue is not that core Hyperion (both official-hyperion and
fish-git-hyperion) doesn't use 'autotools/configure' anymore. The issue is
the introduced dependency on (versions of) 'softfloat', and the directories
the respective build/install directory's the respective versions build
systems expect things to be in.


- Maarten
'\'Fish\' (David B. Trout)' david.b.trout@gmail.com [hercules-390]
2017-02-14 21:56:09 UTC
Permalink
Post by Maarten Hoes ***@gmail.com [hercules-390]
/* non-rant, I hope ? */
:))
Post by Maarten Hoes ***@gmail.com [hercules-390]
The issue is not that core Hyperion (both official-hyperion
and fish-git-hyperion) doesn't use 'autotools/configure' anymore.
The issue is the introduced dependency on (versions of) 'softfloat',
and the directories the respective build/install directory's
the respective versions build systems expect things to be in.
Understood. Please see my earlier reply. This too shall pass. :)
--
"Fish" (David B. Trout)
Software Development Laboratories
http://www.softdevlabs.com
mail: ***@softdevlabs.com
Harold Grovesteen h.grovsteen@tx.rr.com [hercules-390]
2017-02-15 16:45:55 UTC
Permalink
There is clearly frustration with the current build situation. But you
received little to no help in moving forward.

http://hercules-390.github.io/html/

On this page there are two links you should read, if you have not,

https://github.com/hercules-390/hyperion/blob/master/BUILDING.txt
https://github.com/hercules-390/hyperion/blob/master/README.BuildUNIX.txt

These are detailed and well written and give you a sense of what is
going on now with the builds.

While these are informative, I found using the 1Stop command the
simplest to do. Don't over think it.

Using 1Stop.

1Stop is a script in the main Hercules source directory that will
download Softfloat3a, use cmake to build it for linking with Hercules.

cmake 3.2 or greater must be installed. Get used to the idea of cmake.
This is the build direction Hyperion is taking. There are long term
benefits, but we are in transition. You will likely need to install
cmake. Many distros are behind on cmake levels.

_Don't try any thing else until you have a version of cmake installed
that satisfies the needs of the SoftFloat-3a build._ There is a
bootstrap process for the first time you install cmake. Use it.

cd to the directory where 1Stop resides (the main Hercules source
directory).

To run 1Stop simply use the same configuration parameters you would
normally use with configure but supply them to the 1Stop command when
you execute it.

Presently --prefix install is disabled and will only install
into /usr/local. That is not a problem. The out of source build
creates the executable files in the build directory and you can use them
from that location.

I had no issues with 1Stop the first time I used it, other than the
surprise that make install did not work following the build because my
configure parameters had a --prefix option.

Yes, there is at present a required directory structure. Please just
use it. It will save you headaches.

I ended up with this in my home directory:

herchyp/ (where my Hyperion related stuff goes)
hyperion/ (where I pull from the github repo)
1Stop <--- use this to build Hyperion
SoftFloat-3a (1Stop created and built soft float package)
x86_64/ (created by 1Stop)
hyperion/ (where 1Stop built Hercules)
hercules <--- the executable

If you are just starting out or want to redo what did not work, create a
directory, it can be named anything.

myhyp/
(unzip the hyperion repo or clone it right here. There should be
a hyperion directory now.)

cd myhyp/hyperion
./1Stop [your configure parameters]

That should work better. It will get SoftFloat build it and then build
Hercules. If you are familiar with bash scripts, reviewing the 1Stop
command may help you to see what it is doing. Looking at it helped me.
It may help you.

So, yes, some adjustments for those who have a process in place.

As one of the Hyperion developers I understand things are changing, and
we will get them sorted out. Just try to bare with us while things
shift to the endgame, cmake. It will unify building of Hercules on all
supported platforms. It has a lot of flexibility. In the end you will
like it. Change is always a bit painful and the developers are learning
along with you.

Harold Grovesteen
Post by ***@vietfeir.com [hercules-390]
I thought I'd have a look at Hyperion and tried to install it on a
Linux virtual machine. I got through most of it then when I tried to
do make install, it complained about not being able to find a certain
SoftFloat file.
How do I install SoftFloat. The makefile for SoftFloat just installs
it in my local directory There doesn't seem to be a make install
target so I'm not sure what to do after that.
ieee.c:81:30: fatal error: SoftFloat-milieu.h: No such file or
directory
compilation terminated.
In the latest release of SoftFloat I downloaded,I cannot find this
file all all. Am I missing some instructions somewhere?
Dennis
Ivan Warren ivan@vmfacility.fr [hercules-390]
2017-02-15 17:04:32 UTC
Permalink
Post by Harold Grovesteen ***@tx.rr.com [hercules-390]
As one of the Hyperion developers I understand things are changing, and
we will get them sorted out. Just try to bare with us while things
shift to the endgame, cmake. It will unify building of Hercules on all
supported platforms. It has a lot of flexibility. In the end you will
like it. Change is always a bit painful and the developers are learning
along with you.
Harold Grovesteen
Harold...

I don't mind cmake... or anything.

But, to me, either
SoftFloat3a *IS* part of hercules - and should reside INSIDE the
hercules source code....
Or
SoftFloat3a is independent of hercules (although it may be a pre-req -
no issue there) and it should be possible to have it reside at any
location I want.

SoftFloat3a should *NOT* have to reside in a directory that is relative
to the *PARENT* of the source or build directory.

As is, the current build procedure *CANNOT* be automated, it cannot be
part of a binary package in a linux distribution, building requires an
internet connection to retrieve an external package, one cannot create a
self contained source tarball (and you cannot build from source without
git)...

You are welcome to prove me wrong (because I probably misunderstood a
few things).

--Ivan



[Non-text portions of this message have been removed]
Harold Grovesteen h.grovsteen@tx.rr.com [hercules-390]
2017-02-17 14:12:45 UTC
Permalink
Post by Ivan Warren ***@vmfacility.fr [hercules-390]
Post by Harold Grovesteen ***@tx.rr.com [hercules-390]
As one of the Hyperion developers I understand things are changing, and
we will get them sorted out. Just try to bare with us while things
shift to the endgame, cmake. It will unify building of Hercules on all
supported platforms. It has a lot of flexibility. In the end you will
like it. Change is always a bit painful and the developers are learning
along with you.
Harold Grovesteen
Harold...
I don't mind cmake... or anything.
But, to me, either
SoftFloat3a *IS* part of hercules - and should reside INSIDE the
hercules source code....
Or
SoftFloat3a is independent of hercules (although it may be a pre-req -
no issue there) and it should be possible to have it reside at any
location I want.
SoftFloat3a should *NOT* have to reside in a directory that is relative
to the *PARENT* of the source or build directory.
As is, the current build procedure *CANNOT* be automated, it cannot be
part of a binary package in a linux distribution, building requires an
internet connection to retrieve an external package, one cannot create a
self contained source tarball (and you cannot build from source without
git)...
You are welcome to prove me wrong (because I probably misunderstood a
few things).
--Ivan
Your points are noted. All of the issues you point out I believe result
from the challenges we are presently having with autotools, not issues
with SoftFloat-3a. In the course of events over the last few years,
real expertise with autotools has been lost.

SoftFloat-3a has to be separate due to licensing conflicts and is a
pre-req. Hyperion and SoftFloat-3a can not be delivered together in any
form. It will require a separate delivery mechanism for it to work as a
delivered package. Regardless of delivery, the mixing of the package
with Hyperion must be done by the user. Today that mixing occurs when
the source is delivered from its separate repo to the user's system.

At _present_, Hyperion only provides (on *nix) a local build. Making
that easier is where the focus is _today_. And the 1Stop command (as in
"one-stop shopping") tries to do that.

We may eventually get to solving all of these concerns and make it
possible for Hyperion to be included in a distro or be delivered
directly with various installation targets. Those are goals I see.

It is my hope that when Hyperion has moved to cmake (as opposed to the
autotools we are using today) these issues will be solved. If you have
solutions to them for autotools or are willing to develop them, feel
free to do so.

Admittedly, part of what is driving the change to cmake is a lack of
expertise with autotools. If anyone out there has the expertise and is
willing to help out until the transition to cmake is complete, your help
would be welcome. The rolling release approach Hyperion has requires
the build process to continue to function.

Harold Grovesteen
Ivan Warren ivan@vmfacility.fr [hercules-390]
2017-02-17 15:54:04 UTC
Permalink
Post by Harold Grovesteen ***@tx.rr.com [hercules-390]
Post by Ivan Warren ***@vmfacility.fr [hercules-390]
Post by Harold Grovesteen ***@tx.rr.com [hercules-390]
As one of the Hyperion developers I understand things are changing, and
we will get them sorted out. Just try to bare with us while things
shift to the endgame, cmake. It will unify building of Hercules on all
supported platforms. It has a lot of flexibility. In the end you will
like it. Change is always a bit painful and the developers are learning
along with you.
Harold Grovesteen
Harold...
I don't mind cmake... or anything.
But, to me, either
SoftFloat3a *IS* part of hercules - and should reside INSIDE the
hercules source code....
Or
SoftFloat3a is independent of hercules (although it may be a pre-req -
no issue there) and it should be possible to have it reside at any
location I want.
SoftFloat3a should *NOT* have to reside in a directory that is relative
to the *PARENT* of the source or build directory.
As is, the current build procedure *CANNOT* be automated, it cannot be
part of a binary package in a linux distribution, building requires an
internet connection to retrieve an external package, one cannot create a
self contained source tarball (and you cannot build from source without
git)...
You are welcome to prove me wrong (because I probably misunderstood a
few things).
--Ivan
Your points are noted. All of the issues you point out I believe result
from the challenges we are presently having with autotools, not issues
with SoftFloat-3a. In the course of events over the last few years,
real expertise with autotools has been lost.
SoftFloat-3a has to be separate due to licensing conflicts and is a
pre-req.
Isn't there any way for cmake to create a separate library...
Instructing autoconf to search for a specific library only takes a
couple lines of change... It's easy !
Under MSVC it is just the same as adding a search of ZLIB, PCRE or
whatnot... It's been done before.

If softfloat3a can be made into a separate library, then it can be
provided as a separate binary library as a separate project - and users
can then use that binary library or go through building their own
version at their convenience.

Having hercules dependent on softfloat3a, I don't see where the problem
is... If *HOWEVER* softfloat3a NEEDS hercules - then we are opening
another can of worm altogether (because then - softfloat3a becomes
dependent on the hercules project and on its licensing terms [1]).

--Ivan

[1] Oh wait... Hyperion already breaks the QPL...The QPL states VERY
explicitely : you CANNOT fork ! You can only distribute patches to the
source held by the copyright holders.



[Non-text portions of this message have been removed]
Harold Grovesteen h.grovsteen@tx.rr.com [hercules-390]
2017-02-17 21:41:23 UTC
Permalink
Post by Ivan Warren ***@vmfacility.fr [hercules-390]
[1] Oh wait... Hyperion already breaks the QPL...The QPL states VERY
explicitely : you CANNOT fork ! You can only distribute patches to the
source held by the copyright holders.
The QPL does not in fact say that. Read the words. A patch is an
example of a technology mechanism that supports the actual license
requirements. git also supports those requirements by preserving
contributor tracking. git did not exist at the time the Hercules QPL
license was developed and would not have been an appropriate repository
if it did not meet those requirements. The move to git was approved by
the original authors before the current situation developed.

You may also have forgotten how we got here. When the move to git
occurred, as painful as it was at the time, the plan was for two
streams: a development stream and a release stream. That plan was worked
out by Roger, myself and others. That has not really changed. What
changed is who is putting work into which stream. Hyperion is still the
development stream, or perhaps more correctly one of the streams.

Please review "The source code repository" topic on this page from the
release stream web pages published by Roger Bowler:

http://www.hercules-390.eu/

From both a technology perspective and the published role for the
Hyperion repository, it is the development repository it has always
been. Hyperion is not a fork.

Harold Grovesteen
Ivan Warren ivan@vmfacility.fr [hercules-390]
2017-02-17 22:02:56 UTC
Permalink
Post by Harold Grovesteen ***@tx.rr.com [hercules-390]
Post by Ivan Warren ***@vmfacility.fr [hercules-390]
[1] Oh wait... Hyperion already breaks the QPL...The QPL states VERY
explicitely : you CANNOT fork ! You can only distribute patches to the
source held by the copyright holders.
The QPL does not in fact say that. Read the words. A patch is an
example of a technology mechanism that supports the actual license
requirements. git also supports those requirements by preserving
contributor tracking. git did not exist at the time the Hercules QPL
license was developed and would not have been an appropriate repository
if it did not meet those requirements. The move to git was approved by
the original authors before the current situation developed.
You may also have forgotten how we got here. When the move to git
occurred, as painful as it was at the time, the plan was for two
streams: a development stream and a release stream. That plan was worked
out by Roger, myself and others. That has not really changed. What
changed is who is putting work into which stream. Hyperion is still the
development stream, or perhaps more correctly one of the streams.
Please review "The source code repository" topic on this page from the
http://www.hercules-390.eu/
From both a technology perspective and the published role for the
Hyperion repository, it is the development repository it has always
been. Hyperion is not a fork.
Harold Grovesteen
You may be right, I may be wrong...

I don't care..

The whole thing is FUBAR - It won't build without special doctoring and
is managed by someone who edicts "policies" (reminds you of anyone ?)...

--Ivan



[Non-text portions of this message have been removed]

'\'Fish\' (David B. Trout)' david.b.trout@gmail.com [hercules-390]
2017-02-16 00:11:00 UTC
Permalink
This post might be inappropriate. Click to display it.
Gregg Levine gregg.drwho8@gmail.com [hercules-390]
2017-02-16 00:43:03 UTC
Permalink
Hello!
Is it the gills? Or the fish scales and the gills?

Say.... Do you have family here? I actually met (politely even!) a
city cop with the same last name. He did complain about all of the bad
jokes. My comment was that I was above that.
-----
Gregg C Levine ***@gmail.com
"This signature fought the Time Wars, time and again."


On Wed, Feb 15, 2017 at 7:11 PM, ''Fish' (David B. Trout)'
Post by '\'Fish\' (David B. Trout)' ***@gmail.com [hercules-390]
[...]
Just try to bare with us ...
Thank you, no.
I'll BEAR with you, *maybe*, but I don't know any of you well enough to get naked with you.
;-)
(besides, seeing me naked is a frightening image that CAN'T be undone, and I would never do that to someone I consider to me a friend!)
--
"Fish" (David B. Trout)
Software Development Laboratories
http://www.softdevlabs.com
Sorry. It HAD to be said! :)
------------------------------------
------------------------------------
http://groups.yahoo.com/group/hercules-390
http://www.hercules-390.org
------------------------------------
Yahoo Groups Links
kerravon86@yahoo.com.au [hercules-390]
2017-02-16 02:18:44 UTC
Permalink
Post by '\'Fish\' (David B. Trout)' ***@gmail.com [hercules-390]
Sorry. It HAD to be said! :)
http://www.ratman.biz/archive/young_ones/oil.html

Mike: Rick, it had to be done.
Vyvyan: Yeah! I had to! I was drunk!


BFN. Paul.
Peter Coghlan mailinglists@beyondthepale.ie [hercules-390]
2017-02-15 17:18:37 UTC
Permalink
Post by Harold Grovesteen ***@tx.rr.com [hercules-390]
While these are informative, I found using the 1Stop command the
simplest to do. Don't over think it.
This reminds me of:

Q: How do you shut down Windows 95?
A: You click on the start button and...

I don't often use the build procedure supplied with Hercules but I came
across references to 1Stop here and there lately. My first thoughts were
that it must be the name of yet another package that was needed by linux
users before Hercules could be built. Or maybe something to do with a
convenience store. I just ignored it and went my own way as usual.

This is not going to have any impact on me but could I suggest coming
up with a more meaningful name for this critical item, for the sake of new
users who will come asking?

If "configure" is no longer used, could the name be repurposed for this item,
maybe with a warning printed to say that this no longer does what it once did?
Or how about "build"?

While in the area, perhaps ./util/bldlvlck or whatever it is could be changed
into something that it is possible to remember and has more vowels in it?

Regards,
Peter Coghlan.
Loading...