search

hercules-390 / hyperion

Hercules 390
Other
246 stars 69 forks source link

hercules 4x from git does not compile and does not install on FreeBSD 12-CURRENT #216

Closed gurucubano closed 7 years ago

gurucubano commented 7 years ago

$ uname -a FreeBSD c720-r314251 12.0-CURRENT FreeBSD 12.0-CURRENT #0 r314251: Sat Feb 25 17:14:40 CET 2017 root@r303343-amd64:/usr/obj/usr/src/sys/GENERIC amd64

$ git clone https://github.com/hercules-390/hyperion.git $ cd hyperion $ ./1Stop ... the result are missing shared libs: CCLD cckdcdsk ./.libs/libherc.so.0.0: undefined reference to decNumberPlus ./.libs/libherc.so.0.0: undefined reference to decimal128ToNumber ./.libs/libherc.so.0.0: undefined reference to decNumberQuantize

Faking the system environment to 11.0-RELEASE with:

$ env | grep UNAME UNAME_r=11.0-RELEASE UNAME_v=FreeBSD 11.0-RELEASE #0 r314251: Sat Feb 25 17:14:40 CET 2017 root@r303343-amd64:/usr/obj/usr/src/sys/GENERIC UNAME_U=1100022 $ uname -a FreeBSD c720-r314251 11.0-RELEASE FreeBSD 11.0-RELEASE #0 r314251: Sat Feb 25 17:14:40 CET 2017 root@r303343-amd64:/usr/obj/usr/src/sys/GENERIC amd64

makes the compilation fine but the installation does not work:

# cd ../amd64/hyperion # make install ... /usr/bin/install -c .libs/libhercs.so.0.0 /usr/local/lib/libhercs.so.0.0 /usr/bin/install -c .libs/libhercs.lai /usr/local/lib/libhercs.la libtool: install: warning: relinking libhercu.la (cd /usr/home/guru/amd64/hyperion; /bin/sh ./libtool --mode=relink gcc -g -W -Wall -O3 -g -g3 -ggdb3 -O3 -export-dynamic -no-undefined -avoid-version -Wl,--warn-common -o libhercu.la -rpath /usr/local/lib codepage.lo hdl.lo hexdumpe.lo hostinfo.lo hscutl.lo hscutl2.lo hsocket.lo hthreads.lo logger.lo logmsg.lo memrchr.lo parser.lo pttrace.lo version.lo ltdl.lo -lrt -lz -lm -pthread -lbz2 -L/home/guru/amd64/s3fh/lib -lSoftFloat libhercs.la -lrt -lz -lm -pthread -lbz2 -L/home/guru/amd64/s3fh/lib -lSoftFloat ) gcc -shared .libs/codepage.o .libs/hdl.o .libs/hexdumpe.o .libs/hostinfo.o .libs/hscutl.o .libs/hscutl2.o .libs/hsocket.o .libs/hthreads.o .libs/logger.o .libs/logmsg.o .libs/memrchr.o .libs/parser.o .libs/pttrace.o .libs/version.o .libs/ltdl.o -Wl,--rpath -Wl,/usr/local/lib -L/home/guru/amd64/s3fh/lib -L/usr/local/lib -lhercs -lrt -lz -lm -lbz2 -lSoftFloat -Wl,--warn-common -Wl,-soname -Wl,libhercu.so.0.0 -o .libs/libhercu.so.0.0 /usr/local/bin/ld: cannot find -lhercs collect2: error: ld returned 1 exit status libtool: install: error: relink libhercu.la with the above command before installing it *** Error code 1

Please let me know if you need additional output or logs.

srorso commented 7 years ago

Issue occurs on FreeBSD 11 (most recent stable release) as well.

srorso commented 7 years ago

Root causes of the issue: 1) autoconf/config.rpath does not recognize FreeBSD 10 and up as modern versions and turns off shared library support, and 2) libtools.m4 treats any FreeBSD version 7 and higher as only supporting a.out formats. FreeBSD 4 and higher were ELF only.

Libtools.m4 used the objformat utility to determine whether a FreeBSD system was using a.out or ELF, and presumed a.out if the tool did not exist. The tool was removed in FreeBSD 7.

srorso commented 7 years ago

Hi Matthais:

Changes have been committed to address the issue you have reported. Would you please re-clone and re-test?

Many thanks for reporting this issue. And now I do not know if I should close with MfG or saludos cordiales. So...

Best Regards, Steve Orso

gurucubano commented 7 years ago

Hi Steve, compiling after git clone, and without faking uname values, gives the same errors as described in the 1st post; Kind regards

srorso commented 7 years ago

Hi Matthais:

Can you zip and send your /configure and provide the console log from make install? Feel free to send via pm.

Also, and I should have mentioned this, please delete your build directory, which I think is $HOME/amd64/hyperion, before repeating the process?

Also, what happens when you fake out uname?

Many thanks!

Best Regards, Steve Orso

gurucubano commented 7 years ago

Hi

Before git clone, I removed rekursive the dirs hyperion and amd64.

I could not run make install because already compilation with ./1Stop was failing.

I will send the requested file configure.gz later. I'm out for dinner. Anything else?

Thx

matthias

Sent from my mobile device

Am 05.04.2017 um 20:07 schrieb Stephen Orso notifications@github.com:

Hi Matthais:

Can you zip and send your /configure and provide the console log from make install? Feel free to send via pm.

Also, and I should have mentioned this, please delete your build directory, which I think is $HOME/amd64/hyperion, before repeating the process?

Also, what happens when you fake out uname?

Many thanks!

Best Regards, Steve Orso

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or mute the thread.

srorso commented 7 years ago

Hi Matthias,

That will be great...please enjoy your dinner and follow up anytime that is convenient for you.

Best regards, Steve Orso

On Apr 5, 2017, at 2:20 PM, Matthias notifications@github.com wrote:

Hi

Before git clone, I removed rekursive the dirs hyperion and amd64.

I could not run make install because already compilation with ./1Stop was failing.

I will send the requested file configure.gz later. I'm out for dinner. Anything else?

Thx

matthias

Sent from my mobile device

Am 05.04.2017 um 20:07 schrieb Stephen Orso notifications@github.com:

Hi Matthais:

Can you zip and send your /configure and provide the console log from make install? Feel free to send via pm.

Also, and I should have mentioned this, please delete your build directory, which I think is $HOME/amd64/hyperion, before repeating the process?

Also, what happens when you fake out uname?

Many thanks!

Best Regards, Steve Orso

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or mute the thread.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub, or mute the thread.

gurucubano commented 7 years ago

Hello Steve, $ find hyperion/ amd64/ -name configure hyperion/configure $ gzip hyperion/configure

file configure.gz attached

gurucubano commented 7 years ago

El día miércoles, abril 05, 2017 a las 11:07:55a. m. -0700, Stephen Orso escribió:

Also, what happens when you fake out uname?

Hi,

When I fake the uname to 11.0-RELEASE (...) it compiles and installs fine; but on exec it crashes:

$ hercules HHC01413I Hercules version 4.0.0 (4.0.0.8750) HHC01414I (C) Copyright 1999-2016 by Roger Bowler, Jan Jaeger, and others HHC01414I Commit 5ba80fd178babbe4c820c526a3cf9a52538fbe63. HHC01415I Build date: Apr 5 2017 at 21:30:32 HHC01417I Built with: GCC 4.9.4 HHC01417I Build type: FreeBSD 199506 amd64 host architecture build HHC01417I Modes: S/370 ESA/390 z/Arch HHC01417I Max CPU Engines: 128 HHC01417I Using setresuid() for setting privileges HHC01417I Using POSIX threads Threading Model HHC01417I Using Error-Checking Mutex Locking Model HHC01417I With Syncio support HHC01417I With Shared Devices support HHC01417I With Dynamic loading support HHC01417I Using shared libraries HHC01417I With External GUI support HHC01417I With IPV6 support HHC01417I With HTTP Server support HHC01417I With sqrtl support HHC01417I With SIGABEND handler HHC01417I With CCKD BZIP2 support HHC01417I With HET BZIP2 support HHC01417I With ZLIB support HHC01417I With Regular Expressions support HHC01417I Without Object REXX support HHC01417I Without Regina REXX support HHC01417I With Automatic Operator support HHC01417I Without National Language Support HHC01417I Machine dependent assists: cmpxchg1 cmpxchg4 cmpxchg8 hatomics=atomicIntrinsics HHC01417I Running on: c720-r314251 (FreeBSD-12.0-CURRENT amd64) MP=2 HHC01508I HDL: loadable module directory is /usr/local/lib/hercules-v4 Segmentation fault (core dumped)

gurucubano commented 7 years ago

Hi

Watching the proc with truss for the sys calls, it seems that it is missing something:

write(2,"HHC01508I HDL: loadable module d"...,71) = 71 (0x47) access("/lib/hdteq",R_OK) ERR#2 'No such file or directory' access("/usr/lib/hdteq",R_OK) ERR#2 'No such file or directory' access("/usr/local/lib/hdteq",F_OK) ERR#2 'No such file or directory' access("/lib/hdteq",F_OK) ERR#2 'No such file or directory' access("/usr/lib/hdteq",F_OK) ERR#2 'No such file or directory' access("/usr/lib/compat/hdteq",F_OK) ERR#2 'No such file or directory' access("/usr/local/lib/hdteq",F_OK) ERR#2 'No such file or directory' access("/usr/local/lib/gcc49/hdteq",F_OK) ERR#2 'No such file or directory' access("/usr/local/lib/gegl-0.2/hdteq",F_OK) ERR#2 'No such file or directory' access("/usr/local/lib/graphviz/hdteq",F_OK) ERR#2 'No such file or directory' access("/usr/local/lib/mysql/hdteq",F_OK) ERR#2 'No such file or directory' access("/usr/local/lib/mysql/plugin/hdteq",F_OK) ERR#2 'No such file or directory' access("/usr/local/lib/nss/hdteq",F_OK) ERR#2 'No such file or directory' access("/usr/local/lib/opencollada/hdteq",F_OK) ERR#2 'No such file or directory' access("/usr/local/lib/perl5/5.24/mach/CORE/hdteq",F_OK) ERR#2 'No such file or directory' access("/usr/local/lib/qt4/hdteq",F_OK) ERR#2 'No such file or directory' access("/usr/local/lib/qt5/hdteq",F_OK) ERR#2 'No such file or directory' access("/usr/local/lib/qtcreator/hdteq",F_OK) ERR#2 'No such file or directory' access("/usr/local/llvm39/lib/hdteq",F_OK) ERR#2 'No such file or directory' access("/lib/casper/hdteq",F_OK) ERR#2 'No such file or directory' access("/lib/hdteq",F_OK) ERR#2 'No such file or directory' access("/usr/lib/hdteq",F_OK) ERR#2 'No such file or directory' open("/lib/hdteq.la",O_RDONLY,0666) ERR#2 'No such file or directory' open("/usr/lib/hdteq.la",O_RDONLY,0666) ERR#2 'No such file or directory' open("hdteq.la",O_RDONLY,0666) ERR#2 'No such file or directory' SIGNAL 11 (SIGSEGV) read(3,"\M-%\M-%\M-%",1047158) = 3 (0x3) <thread 100461 exited> process killed, signal = 11 (core dumped)

gurucubano commented 7 years ago

Don't know if this helps, but here is what e gdb debugger shows from the core:

$ gdb /usr/local/bin/hercules hercules.core

GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "amd64-marcel-freebsd"...Dwarf Error: wrong version in compilation unit header (is 4, should be 2) [in module /usr/local/bin/hercules]

Core was generated by `/usr/local/bin/hercules'. Program terminated with signal 11, Segmentation fault. Reading symbols from /usr/local/lib/libherc.so...Error while reading shared library symbols: Dwarf Error: wrong version in compilation unit header (is 4, should be 2) [in module /usr/local/lib/libherc.so] Reading symbols from /usr/local/lib/libherct.so...Error while reading shared library symbols: Dwarf Error: wrong version in compilation unit header (is 4, should be 2) [in module /usr/local/lib/libherct.so] Reading symbols from /usr/local/lib/libhercd.so...Error while reading shared library symbols: Dwarf Error: wrong version in compilation unit header (is 4, should be 2) [in module /usr/local/lib/libhercd.so] Reading symbols from /usr/local/lib/libhercu.so...Error while reading shared library symbols: Dwarf Error: wrong version in compilation unit header (is 4, should be 2) [in module /usr/local/lib/libhercu.so] Reading symbols from /usr/local/lib/libhercs.so...Error while reading shared library symbols: Dwarf Error: wrong version in compilation unit header (is 4, should be 2) [in module /usr/local/lib/libhercs.so] Reading symbols from /usr/local/lib/libdecNumber.so...Error while reading shared library symbols: Dwarf Error: wrong version in compilation unit header (is 4, should be 2) [in module /usr/local/lib/libdecNumber.so] Reading symbols from /usr/lib/librt.so.1...Reading symbols from /usr/lib/debug//usr/lib/librt.so.1.debug...done. done. Loaded symbols for /usr/lib/librt.so.1 Reading symbols from /lib/libz.so.6...Reading symbols from /usr/lib/debug//lib/libz.so.6.debug...done. done. Loaded symbols for /lib/libz.so.6 Reading symbols from /lib/libm.so.5...Reading symbols from /usr/lib/debug//lib/libm.so.5.debug...done. done. Loaded symbols for /lib/libm.so.5 Reading symbols from /usr/lib/libbz2.so.4...Reading symbols from /usr/lib/debug//usr/lib/libbz2.so.4.debug...done. done. Loaded symbols for /usr/lib/libbz2.so.4 Reading symbols from /lib/libthr.so.3...Reading symbols from /usr/lib/debug//lib/libthr.so.3.debug...done. done. Loaded symbols for /lib/libthr.so.3 Reading symbols from /lib/libc.so.7...Reading symbols from /usr/lib/debug//lib/libc.so.7.debug...done. done. Loaded symbols for /lib/libc.so.7 Reading symbols from /libexec/ld-elf.so.1...Reading symbols from /usr/lib/debug//libexec/ld-elf.so.1.debug...done. done. Loaded symbols for /libexec/ld-elf.so.1

0 basename (path=) at /usr/src/lib/libc/gen/basename.c:48

48 *ptr-- = '\0'; [New Thread 803016500 (LWP 100561/)] [New Thread 803016000 (LWP 100184/)] (gdb) thread apply all bt

Thread 2 (Thread 803016000 (LWP 100184/)):

0 basename (path=) at /usr/src/lib/libc/gen/basename.c:48

1 0x00000008017b6b96 in ?? () from /usr/local/lib/libhercu.so

2 0x0000000000000014 in ?? ()

3 0x0000000803168070 in ?? ()

4 0x000000080301c2b0 in ?? ()

5 0x00000008017c6d4a in ?? () from /usr/local/lib/libhercu.so

6 0x0000000000000008 in ?? ()

7 0x00000008017b7b1e in ?? () from /usr/local/lib/libhercu.so

8 0x00000008019d1430 in ?? () from /usr/local/lib/libhercu.so

9 0x0000000801bd5380 in ?? () from /usr/local/lib/libhercs.so

10 0x0000000000000000 in ?? ()

Current language: auto; currently minimal

Thread 1 (Thread 803016500 (LWP 100561/)):

0 0x00000008029db9d8 in _read () from /lib/libc.so.7

1 0x0000000802665726 in __thr_read (fd=, buf=,

nbytes=<value optimized out>) at /usr/src/lib/libthr/thread/thr_syscalls.c:402

2 0x00000008017bd4f0 in ?? () from /usr/local/lib/libhercu.so

3 0x00007fffdfffdf00 in ?? ()

4 0x000000080292b282 in __je_witness_assert_lockless (tsdn=0x80301c220) at witness.h:191

Previous frame inner to this frame (corrupt stack?) 48 ptr-- = '\0'; (gdb) p ptr $1 = 0x8017c6d4e "q" (gdb) l 43
44 / Find end of last pathname component and null terminate it. / 45 ptr = path + strlen(path); 46 while (ptr > path + 1 && (ptr - 1) == '/') 47 --ptr; 48 ptr-- = '\0'; 49
50 / Find beginning of last pathname component. / 51 while (ptr > path && (ptr - 1) != '/') 52 --ptr; (gdb)

ghost commented 7 years ago

My two cents …

all the autoshit stuff included in hercules is 15 ( fifteen years) old

i mildly suggest ( instead of hacking around ) to download and use more recent versions

for libtool.m4 to use the one provided by the libtool package

http://ftpmirror.gnu.org/libtool/libtool-2.4.6.tar.gz.

for config.guess git clone https://git.savannah.gnu.org/git/config.git

and for the rest of the autoshit better use in the autoconf.sh script something along the lines of …

echo -n "aclocal... " && aclocal --force -I autoconf >>./bootstrap.log 2>&1 && echo "(25% done)" && echo -n "autoheader... " && autoheader -f >>./bootstrap.log 2>&1 && echo "(50% done)" && echo -n "automake... " && automake -f --foreign -a -c >>./bootstrap.log 2>&1 && echo "(75% done)" && echo -n "autoconf... " && autoconf -f >>./bootstrap.log 2>&1 && echo "(100% done)"

to force a replace of the outdated things with the more recent ones provided by the system

when I was using the auto* things to build hercules on Darwin and other Linux never had any problems using the above approach

I do not know if the above apply to freeBSD, but worth a try

cheers

e

gurucubano commented 7 years ago

El día jueves, abril 06, 2017 a las 12:06:42a. m. -0700, Enrico Sorichetti escribió:

My two cents …

all the autoshit stuff included in hercules is 15 ( fifteen years) old

i mildly suggest ( instead of hacking around ) to download and use more recent versions

for libtool.m4 to use the one provided by the libtool package

http://ftpmirror.gnu.org/libtool/libtool-2.4.6.tar.gz.

On the host in question I have libtool 2.4.6:

pkg info | grep libtool

libtool-2.4.6 Generic shared library support script

ls -l /usr/local/share/aclocal/libtool.m4

-rw-r--r-- 1 root wheel 305723 4 mar. 21:58 /usr/local/share/aclocal/libtool.m4

about the rest (and required changes in hercules' build infrastructure), I have no idea...

matthias
ghost commented 7 years ago

On 6 Apr 2017, at 09:21, Matthias notifications@github.com wrote:

On the host in question I have libtool 2.4.6:

You might have it on Your host,… but the one used is the one in hyperion.whatever>autoconf/libtool.m4

cheers e

jphartmann commented 7 years ago

Matthias, as you cannot commit to the Hyperion source, can you confirm that this problem would not have surfaced it the source you pulled from github had been processed by the developers to run autogen.sh before committing?

And you would not have to install the autoxxx packages (let alone find out what and where they are)?

gurucubano commented 7 years ago

El día jueves, abril 06, 2017 a las 01:03:19a. m. -0700, John P. Hartmann escribió:

Matthias, as you cannot commit to the Hyperion source, can you confirm that this problem would not have surfaced it the source you pulled from github had been processed by the developers to run autogen.sh before committing?

And you would not have to install the autoxxx packages (let alone find out what and where they are)?

I'm not sure if I do understand your questions.

I only want to get hercules to work on my laptop to run some older /370 system I have here on my desk as 9-track tape (still to transfer to some file, so it could be used).

matthias
jphartmann commented 7 years ago

Thanks, Matthias. Your answers are yes, yes. We (the guys in the back office) need to address this problem.

gurucubano commented 7 years ago

El día jueves, abril 06, 2017 a las 01:14:08a. m. -0700, John P. Hartmann escribió:

Thanks, Matthias. Your answers are yes, yes. We (the guys in the back office) need to address this problem.

Thanks. Just let me know if you commited something and I will happy to give it a try and provide any information you need to fix it.

srorso commented 7 years ago

Hi Matthais:

I will build a FreeBSD 12 system to duplicate this issue, although it will take a day or so...I have some non-Hercules matters that must be addressed.

I tried for other reasons to update Hercules versions of autotools, including libtool, a few weeks back. Turns out that is a non-trivial exercise. Other stuff breaks in the Hercules build when using modern tools, particularly libtool. So far, fixing the old libtools has been easier than updating all of autotools to current versions.

All of the previous issues in FreeBSD builds that I have been able to fix were caused by an old libtools not understanding FreeBSD versioning or capabilities. Your issue may or may not have the same root cause.

We shall continue to investigate.

Best Regards, Steve Orso

srorso commented 7 years ago

Hi Matthais:

The cause of this issue has been identified, and it will take a day or so to document the cause and publish a work-around. Because FreeBSD 12 is the only system at present affected by this issue, additional testing wil be needed to see how the work-around can be converted into a fix that can be committed.

Again, thanks for bringing this matter to our attention, and for giving me the opportunity to get on speaking terms with gdb.

Best Regards, Steve Orso

srorso commented 7 years ago

In module hdl.c, line 229, c library function basename() is called with a caller-provided pointer to a string. That string turns out to be allocated in the .rodata segment because it is a constant.

In FreeBSD versions prior to 12, the implementation of basename() following prototype: 

char * basename(const char *path)

In FreeBSD version 12, the prototype was changed to this:

char * basename(char *path)

And the man page was updated to note that the parameter provided by the caller would be used for the result:

IMPLEMENTATION NOTES This implementation of basename() uses the buffer provided by the caller to store the resulting pathname component. Other vendor implementations may return a pointer to internal storage space instead. The advantage of the former approach is that it ensures thread-safety, while also placing no upper limit on the supported length of the pathname.

The FreeBSD 12 basename() source code reveals is that the caller's string parameter is always modified, even if there are no trailing directory separator characters. This means if you pass basename() a constant string, even if it is as a result of a char *filename ="onetwothree" statement, you will get a segment fault.

The GNU version of basename() always did have a caveat that the caller's string parameter might be modified, and the GNU basename() prototype reads the same as the FreeBSD 12 prototype. Debian 8.6 (Jessie) documentation for example, says:

Both dirname() and basename() may modify the contents of path, so it may be desirable to pass a copy when calling one of these functions.

But internally, Debian's basename() function does not modify the caller's string. Instead, it malloc()'s a space for the result string.

The basename() function is used in the following Hercules routines:

When built on Windows, the w32util.c module provides its own basename() function which does not modify the caller's string parameter. Although my quick look at it makes me wonder if it is thread safe.

srorso commented 7 years ago

And here's what made this hard to find: the basename() function is only used in hdl.c when Hercules is run outside of the build directory (before or after make install). When run inside the build directory, the code path that includes basename() is not executed.

srorso commented 7 years ago

Hi Matthais:

Here is a work-around for you. Please change source directory file hdl.c lines 227-229 by adding this line before 227:

    char * filenamecopy = strdup(filename);

and this line after existing line 229:

   free(filenamecopy);

so that when changed, the entire if statement reads thus:

    if( hdl_modpath && *hdl_modpath)
    {
        char * filenamecopy = strdup(filename);
        strlcpy(fullname,hdl_modpath,fulllen);
        strlcat(fullname,PATHSEPS,fulllen);
        strlcat(fullname,basename(filenamecopy),fulllen);
        free(filenamecopy);
    }
    else
        strlcpy(fullname,filename,fulllen);

Delete the build directory and re-run 1Stop, followed by make check and make install.

Please let me know how this works out.

Thanks!

Best Regards, Steve Orso

gurucubano commented 7 years ago

Hello,

I've applied the patch, compiled all new (removed build dir before) with the faked uname env, double checked all; but the crash remains with the same gdb backtrace as shown above; sorry for the bad news. I think from the gdb bt that the crash is in some other place, as the basename-patch addresses. Will insert a printf in this place to be sure, later.

Saludos Matthias

srorso commented 7 years ago

Hi Matthias:

I am sorry to hear that....which snapshot of 12 are you using? I'm on the 5-April snapshot.

Let me know what gdb tells you....

Best regards, Steve Orso

gurucubano commented 7 years ago

On Saturday, 8 April 2017 18:25:21 CEST, Stephen Orso notifications@github.com wrote:

Hi Matthias:

I am sorry to hear that....which snapshot of 12 are you using?
I'm on the 5-April snapshot.

Hi,

I always compile from SVN repository, actual from March 3.

Let me know what gdb tells you....

Of course :-)

Saludos

matthias

-- Sent from my Ubuntu phone http://www.unixarea.de/

gurucubano commented 7 years ago

El día sábado, abril 08, 2017 a las 05:12:57a. m. -0700, Stephen Orso escribió:

Hi Matthais:

Here is a work-around for you. Please change source directory file hdl.c lines 227-229 by adding this line before 227:

    char * filenamecopy = strdup(filename);

and this line after existing line 229:

   free(filenamecopy);

so that when changed, the entire if statement reads thus:

    if( hdl_modpath && *hdl_modpath)
    {
        char * filenamecopy = strdup(filename);
        strlcpy(fullname,hdl_modpath,fulllen);
        strlcat(fullname,PATHSEPS,fulllen);
        strlcat(fullname,basename(filenamecopy),fulllen);
        free(filenamecopy);
    }
    else
        strlcpy(fullname,filename,fulllen);

Delete the build directory and re-run 1Stop, followed by make check and make install.

Now it works. While reading the change in hdl.c again, I realised that I did insert the lines about strdup() and free(), but did not changed the call of basename() itself. I did this now and hercules starts fine. Even if I do not know (and do not have) to boot from something.

Thanks for the fix.

It remains the problem about the faked FreeBSD-11 environment, though.

Saludos

matthias
srorso commented 7 years ago

Hi Matthias,

I have good news and bad news.

You already know the bad news: I left an essential element out of my instructions. You figured that out nicely; you have my thanks.

Now for the good news: I did not fake out uname. All testing was done using uname reporting FreeBSD 12-CURRENT.

Please give the correction a try using an unfaked uname.

Please accept my apologies for the incomplete workaround instructions.

Best regards, Steve Orso

gurucubano commented 7 years ago

El día sábado, abril 08, 2017 a las 01:09:52p. m. -0700, Stephen Orso escribió:

Hi Stephen,

Do not worry about the missing instruction. I blame myself for not have carefully read your code change and missed out some essential part.

Please give the correction a try using an unfaked uname.

I did and it is missing some shared lib symbols:

CCLD s37x.la CC cckdcdsk.o In file included from /home/guru/hyperion/hstdinc.h:223:0, from /home/guru/hyperion/cckdcdsk.c:14: /usr/include/sys/capability.h:41:2: warning: #warning this file includes <sys/capability.h> which is deprecated [-Wcpp]

warning this file includes <sys/capability.h> which is deprecated

^ CCLD cckdcdsk ./.libs/libherc.so: undefined reference to decNumberPlus' ./.libs/libherc.so: undefined reference todecimal128ToNumber' ./.libs/libherc.so: undefined reference to decNumberQuantize' ./.libs/libherc.so: undefined reference todecNumberNormalize' ...

$ ls -l ../amd64/hyperion/.libs/lib* lrwxr-xr-x 1 guru wheel 13 8 abr. 22:24 ../amd64/hyperion/.libs/libherc.la -> ../libherc.la -rw-r--r-- 1 guru wheel 939 8 abr. 22:24 ../amd64/hyperion/.libs/libherc.lai -rwxr-xr-x 1 guru wheel 17391336 8 abr. 22:24 ../amd64/hyperion/.libs/libherc.so lrwxr-xr-x 1 guru wheel 14 8 abr. 22:18 ../amd64/hyperion/.libs/libhercd.la -> ../libhercd.la -rw-r--r-- 1 guru wheel 891 8 abr. 22:18 ../amd64/hyperion/.libs/libhercd.lai -rwxr-xr-x 1 guru wheel 1701040 8 abr. 22:18 ../amd64/hyperion/.libs/libhercd.so lrwxr-xr-x 1 guru wheel 14 8 abr. 22:17 ../amd64/hyperion/.libs/libhercs.la -> ../libhercs.la -rw-r--r-- 1 guru wheel 837 8 abr. 22:17 ../amd64/hyperion/.libs/libhercs.lai -rwxr-xr-x 1 guru wheel 504720 8 abr. 22:17 ../amd64/hyperion/.libs/libhercs.so lrwxr-xr-x 1 guru wheel 14 8 abr. 22:17 ../amd64/hyperion/.libs/libherct.la -> ../libherct.la -rw-r--r-- 1 guru wheel 891 8 abr. 22:17 ../amd64/hyperion/.libs/libherct.lai -rwxr-xr-x 1 guru wheel 638536 8 abr. 22:17 ../amd64/hyperion/.libs/libherct.so lrwxr-xr-x 1 guru wheel 14 8 abr. 22:17 ../amd64/hyperion/.libs/libhercu.la -> ../libhercu.la -rw-r--r-- 1 guru wheel 864 8 abr. 22:17 ../amd64/hyperion/.libs/libhercu.lai -rwxr-xr-x 1 guru wheel 1404696 8 abr. 22:17 ../amd64/hyperion/.libs/libhercu.so

Saludos

matthias
srorso commented 7 years ago

Hello Matthias:

The libraries dec* are built in a subdirectory decNumber of hyperion; you should see them here:

$ ls .libs/lib*
.libs/libherc.la        .libs/libhercd.lai      .libs/libhercs.so       .libs/libhercu.la
.libs/libherc.lai       .libs/libhercd.so       .libs/libherct.la       .libs/libhercu.lai
.libs/libherc.so        .libs/libhercd.soT      .libs/libherct.lai      .libs/libhercu.so
.libs/libherc.soT       .libs/libhercs.la       .libs/libherct.so       .libs/libhercu.soT
.libs/libhercd.la       .libs/libhercs.lai      .libs/libherct.soT
$ ls -laR decNumber/
total 72
drwxr-xr-x   4 srorso  srorso    512 Apr  8 07:54 .
drwxr-xr-x  11 srorso  srorso   4608 Apr  8 08:00 ..
drwxr-xr-x   2 srorso  srorso    512 Apr  8 07:54 .deps
drwxr-xr-x   2 srorso  srorso    512 Apr  8 07:54 .libs
-rw-r--r--   1 srorso  srorso  22995 Apr  8 07:54 Makefile
-rw-r--r--   1 srorso  srorso    310 Apr  8 07:54 decContext.lo
-rw-r--r--   1 srorso  srorso    308 Apr  8 07:54 decNumber.lo
-rw-r--r--   1 srorso  srorso    308 Apr  8 07:54 decPacked.lo
-rw-r--r--   1 srorso  srorso    310 Apr  8 07:54 decimal128.lo
-rw-r--r--   1 srorso  srorso    308 Apr  8 07:54 decimal32.lo
-rw-r--r--   1 srorso  srorso    308 Apr  8 07:54 decimal64.lo
-rw-r--r--   1 srorso  srorso    871 Apr  8 07:54 libdecNumber.la

decNumber/.deps:
total 32
drwxr-xr-x  2 srorso  srorso   512 Apr  8 07:54 .
drwxr-xr-x  4 srorso  srorso   512 Apr  8 07:54 ..
-rw-r--r--  1 srorso  srorso  2101 Apr  8 07:54 decContext.Plo
-rw-r--r--  1 srorso  srorso  2417 Apr  8 07:54 decNumber.Plo
-rw-r--r--  1 srorso  srorso  2323 Apr  8 07:54 decPacked.Plo
-rw-r--r--  1 srorso  srorso  2327 Apr  8 07:54 decimal128.Plo
-rw-r--r--  1 srorso  srorso  2323 Apr  8 07:54 decimal32.Plo
-rw-r--r--  1 srorso  srorso  2429 Apr  8 07:54 decimal64.Plo

decNumber/.libs:
total 736
drwxr-xr-x  2 srorso  srorso     512 Apr  8 07:54 .
drwxr-xr-x  4 srorso  srorso     512 Apr  8 07:54 ..
-rw-r--r--  1 srorso  srorso   23928 Apr  8 07:54 decContext.o
-rw-r--r--  1 srorso  srorso  307496 Apr  8 07:54 decNumber.o
-rw-r--r--  1 srorso  srorso    8712 Apr  8 07:54 decPacked.o
-rw-r--r--  1 srorso  srorso   20856 Apr  8 07:54 decimal128.o
-rw-r--r--  1 srorso  srorso   18240 Apr  8 07:54 decimal32.o
-rw-r--r--  1 srorso  srorso   37640 Apr  8 07:54 decimal64.o
lrwxr-xr-x  1 srorso  srorso      18 Apr  8 07:54 libdecNumber.la -> ../libdecNumber.la
-rw-r--r--  1 srorso  srorso     872 Apr  8 07:54 libdecNumber.lai
-rwxr-xr-x  1 srorso  srorso  305358 Apr  8 07:54 libdecNumber.so
$

I will have to see what I can do about building the 3 March version from svn.

Best Regards, Steve Orso

gurucubano commented 7 years ago

Hello,

I did some systematic tests re/ the uname fake; it depends only of the env var UNAME_r and works or fails with the following values:

UNAME_r="12.0-RELEASE" # --> failed

UNAME_r="11.0-RELEASE" # --> works

UNAME_r="11.0-CURRENT" # --> works

UNAME_r="12" # --> failed

When in failed the picture is always the same: missing symbols 'dec....':

CCLD cckdcdsk ./.libs/libherc.so: undefined reference to decNumberPlus' ./.libs/libherc.so: undefined reference todecimal128ToNumber' ./.libs/libherc.so: undefined reference to decNumberQuantize' ./.libs/libherc.so: undefined reference todecNumberNormalize' ./.libs/libherc.so: undefined reference to `decPackedFromNumber' ...

and the obj and share libs below ../amd64/hyperion/decNumber/ are:

$ ls -laR ../amd64/hyperion/decNumber/ total 68 drwxr-xr-x 4 guru wheel 512 9 abr. 15:42 . drwxr-xr-x 11 guru wheel 3584 9 abr. 15:51 .. drwxr-xr-x 2 guru wheel 512 9 abr. 15:42 .deps drwxr-xr-x 2 guru wheel 512 9 abr. 15:42 .libs -rw-r--r-- 1 guru wheel 310 9 abr. 15:42 decContext.lo -rw-r--r-- 1 guru wheel 310 9 abr. 15:42 decimal128.lo -rw-r--r-- 1 guru wheel 308 9 abr. 15:42 decimal32.lo -rw-r--r-- 1 guru wheel 308 9 abr. 15:42 decimal64.lo -rw-r--r-- 1 guru wheel 308 9 abr. 15:42 decNumber.lo -rw-r--r-- 1 guru wheel 308 9 abr. 15:42 decPacked.lo -rw-r--r-- 1 guru wheel 812 9 abr. 15:42 libdecNumber.la -rw-r--r-- 1 guru wheel 22785 9 abr. 15:42 Makefile

../amd64/hyperion/decNumber/.deps: total 32 drwxr-xr-x 2 guru wheel 512 9 abr. 15:42 . drwxr-xr-x 4 guru wheel 512 9 abr. 15:42 .. -rw-r--r-- 1 guru wheel 2552 9 abr. 15:42 decContext.Plo -rw-r--r-- 1 guru wheel 2732 9 abr. 15:42 decimal128.Plo -rw-r--r-- 1 guru wheel 2728 9 abr. 15:42 decimal32.Plo -rw-r--r-- 1 guru wheel 2811 9 abr. 15:42 decimal64.Plo -rw-r--r-- 1 guru wheel 2847 9 abr. 15:42 decNumber.Plo -rw-r--r-- 1 guru wheel 2728 9 abr. 15:42 decPacked.Plo

../amd64/hyperion/decNumber/.libs: total 1112 drwxr-xr-x 2 guru wheel 512 9 abr. 15:42 . drwxr-xr-x 4 guru wheel 512 9 abr. 15:42 .. -rw-r--r-- 1 guru wheel 91688 9 abr. 15:42 decContext.o -rw-r--r-- 1 guru wheel 101232 9 abr. 15:42 decimal128.o -rw-r--r-- 1 guru wheel 96624 9 abr. 15:42 decimal32.o -rw-r--r-- 1 guru wheel 115752 9 abr. 15:42 decimal64.o -rw-r--r-- 1 guru wheel 563904 9 abr. 15:42 decNumber.o -rw-r--r-- 1 guru wheel 85680 9 abr. 15:42 decPacked.o -rw-r--r-- 1 guru wheel 72 9 abr. 15:42 libdecNumber.a lrwxr-xr-x 1 guru wheel 18 9 abr. 15:42 libdecNumber.la -> ../libdecNumber.la -rw-r--r-- 1 guru wheel 813 9 abr. 15:42 libdecNumber.lai

HIH

matthias
gurucubano commented 7 years ago

El día domingo, abril 09, 2017 a las 01:04:26a. m. -0700, Stephen Orso escribió:


I will have to see what I can do about building the 3 March version from svn.

Hello Steve,

If you really want bo build the version from SVN you do:

svn co -r314251 svn://svn.freebsd.org/base/head src

and build from source. If you need a small tutorial for compiling FreeBSD' world and kernel, please let me know.

Saludos

matthias
srorso commented 7 years ago

Hi Mattias:

If you have such a tutorial already written, please feel free to send it along...it will continue my open source system education. But please do not take the time to write one on my account.

Your directory listings have, I think, provided me with enough information to continue diagnosing your issue. It appears that decNumber is being generated as a static library contrary to all expectations of the build process. While not supported, the build still includes code for creating static libraries, and static libraries are what I got when I first tried to build Hercules on FreeBSD 11. It is interesting that the main libraries, libherc*, are built shared. That is a puzzle.

Many thanks for your patience as we work through this. The effort will benefit everyone who wishes to run Hercules on FreeBSD 12.

Best Regards, Steve Orso

gurucubano commented 7 years ago

El día domingo, abril 09, 2017 a las 08:31:04a. m. -0700, Stephen Orso escribió:

Hi Mattias:

If you have such a tutorial already written, please feel free to send it along...it will continue my open source system education. But please do not take the time to write one on my account.

Hi Steve,

here we go:

Update from "old" to r314251:

cd /usr

mv src src.old

mv obj obj.old

mkdir obj

svn co -r314251 svn://svn.freebsd.org/base/head src

make buildworld

make buildkernel

Install the new kernel; use 'sh' and not 'csh':

sh

cd /usr/src

make installkernel

ignore errors about 'kldxref: unknown metadata ...' (if any); the reason is that the old still installed tool 'kldxref' does not understand some data in the new, now installed, kernel's loadable modules;

shutdown and reboot

shutdown -r now

...and reboot to Single User (option 2); mount the file system, add swap and do some house keeping work before installing world; note the keyboard is expected as English (the - sign is the key of 'sz', and the / sign is where the - sign is printed on the key, the = sign is left to sz):

mount -u /

mount -a -t ufs

swapon -a

adjkerntz -i

now to mergemaster: read this before and maybe before all the update its man page; it tries to present the diff of the (old) installed files and the new which would come with the world-install; the diff is presented with the more-command and at the end for each pair it will ask what to do now:

d) to delete the (new) file i) to install the (new) file m) merge both (which is higly complex) v) view diff again

the default (ENTER) is 'Leave it for later'; the best strategy is option i) i.e. install the new file; with at least two execptions: /etc/group and /etc/motd;

if you have understand the above, run mergemaster for the first time as:

mergemaster -p -m /usr/src

only the file /etc/group is checked in this run before installing world, the rest comes in an additional mergemaster run after installing world; use here 'd' to delete the temp. new ./etc/group file;

after this we now are ready to install 'world':

cd /usr/src

make installworld

now we run mergemaster again:

mergemaster -iF -m /usr/src

as said: follow the strategy to use i) install the new file, but not for /etc/group and /etc/motd;

finally delete some old stuff and reboot to normal live:

yes | make delete-old

yes | make delete-old-libs

reboot

Have fun

matthias
srorso commented 7 years ago

Hi Matthias:

I shall have fun; thanks for the procedure. For extra credit after I get it working I will figure out how to build onto a second (blank, virtual) disk for later boot as a primary.

Would you send along, by pm if needed, a copy of the following from the build directory

Crypto and decNumber should both be build shared, and I would like to see if your 12.0* system builds both as static.

I just tried again for verification, and Hercules builds correctly with an unfaked uname using the 5-Apr snapshot of 12-CURRENT. 

$ uname -a
FreeBSD FreeBSD12 12.0-CURRENT FreeBSD 12.0-CURRENT #0 r316508: Wed Apr  5 01:29:19 UTC 2017     root@releng3.nyi.freebsd.org:/usr/obj/usr/src/sys/GENERIC  amd64
$ uname -m
amd64
$ uname -r
12.0-CURRENT
$ uname -s
FreeBSD
$ uname -v
FreeBSD 12.0-CURRENT #0 r316508: Wed Apr  5 01:29:19 UTC 2017     root@releng3.nyi.freebsd.org:/usr/obj/usr/src/sys/GENERIC

Again, many thanks.

Best Regards, Steve Orso

srorso commented 7 years ago

Took me a minute to figure out that sz means ß on a German keyboard...fun stuff. My keyboard is labeled for US Querty, but I always configure US Dvorak. I played with some old versions of FreeBSD (5.5, 6.4) a while back and those boot UK Querty.

gurucubano commented 7 years ago

El día domingo, abril 09, 2017 a las 11:09:41a. m. -0700, Stephen Orso escribió:

Hi Matthias:

I shall have fun; thanks for the procedure. For extra credit after I get it working I will figure out how to build onto a second (blank, virtual) disk for later boot as a primary.

Hi Steve,

I allways write new systems on some external USB disk and boot/test from there. It's pretty much easy. Just make a partition on the disk, make a file system there with 'newfs', mount it to /mnt and say in all make ... something like:

make installworld DESTDIR=/mnt

make installkernel DESTDIR=/mnt

...

and the new System is in /mnt; I have some tutorial too for this.

FreeBSD is just the better UNIX :-)

Tschüß

matthias
jphartmann commented 7 years ago

"FreeBSD is just the better UNIX :-)"

I second that. Regrettably, nowadays one needs more than UNIX.

gurucubano commented 7 years ago

El día domingo, abril 09, 2017 a las 11:09:41a. m. -0700, Stephen Orso escribió:

Would you send along, by pm if needed, a copy of the following from the build directory

  • Makefile file from the decNumber subdirectory
  • Makefile file from the crypto subdirectory
  • Makefile file from the build directory
  • output from uname -m
  • output from uname -r
  • output from uname -s
  • output from uname -v
  • Output from ls -laR crytpo issued from the build directory?

Hi Steve,

Here the listing of the requested Makefile's and command output from without faking uname.

HIH

matthias
gurucubano commented 7 years ago

the attachment did not went through by mail, here it is: screenlog.0.gz

gurucubano commented 7 years ago

Hello Steve,

As I now have running hercules 4.x, I wanted to setup some MVS in it. There is a so called "turnkey" CD for download from

http://www.bsp-gmbh.com/turnkey/herc_mvs.html

but the setup script is full of Linux'ismen. Do you know if such a beast for FreeBSD is around?

Thanks

matthias
srorso commented 7 years ago

Hi Matthias:

Thank you for the files. I hope to have the same luck at finding out why a static decNumber library was built as when I first installed on FreeBSD 11.

While not a turnkey system at all, my preference is for Jay Moseley's MVS installation tutorial. Installation steps are clearly laid out ad there's lots of descriptive information. I have no professional MVS experience and was able to install MVS. There are also lots of people in Hercules-land with MVS experience.

One note about that site: Mr. Moseley includes some warnings about telnet support in Hercules. These warnings are no longer needed for Hercules V4, as Fish re-did the telnet support last year. PuTTY works just fine, as does xc3270 (Windows). I am confident native Linux or BSD telnet will work fine as well.

Best Regards, Steve Orso

srorso commented 7 years ago

Hi Mattias:

All three Makefilen show that the build process has settled on static libraries for the build. Unfortunately they do not provide clues as to why.

Would you, if possible, run the following commands in this order from the build directory:

sh -x -v ../../hyperion/configure >configuretrace.log 2>&1
make diagnostic

The second command generates some diagnostic information and exits;; it does not do a build. The first command will generate a lot of output, as it traces each shell command prior to execution and then after execution. It will also take a while to run. The result on my system:

$ ls -la configuretrace.log
-rw-r--r--  1 srorso  srorso  3841418 Apr 10 05:33 configuretrace.log
$

Once that's done, could you send the make diagnostic output and the files configuretrace.log, configure, and config.log from the build directory?

For reference and comparison, make diagnostic on my FreeBSD 12 system generates:

$ make diagnostic
System information
  /etc/os-release      cat: /etc/os-release: No such file or directory
  uname -a             FreeBSD FreeBSD12 12.0-CURRENT FreeBSD 12.0-CURRENT #0 r316508: Wed Apr 5 01:29:19 UTC 2017 root@releng3.nyi.freebsd.org:/usr/obj/usr/src/sys/GENERIC amd64
  uname -m             amd64
  uname -p             amd64
  uname -s             FreeBSD

Build tools versions
  autoconf             autoconf (GNU Autoconf) 2.69
  automake             automake (GNU automake) 1.15
  m4                   BSD version of m4
  make                 BSD version of make
  compiler             FreeBSD clang version 4.0.0 (tags/RELEASE_400/final 297347) (based on LLVM 4.0.0)
  linker               GNU ld 2.17.50 [FreeBSD] 2007-07-03

Build directories
  source              /usr/home/srorso/Hercules/hyperion
  build               /usr/home/srorso/Hercules/amd64/hyperion
Install directories
  prefix              /usr/local
    exec_prefix       /usr/local
      bindir          /usr/local/bin
      libdir          /usr/local/lib
    includedir        /usr/local/include
    datarootdir       /usr/local/share
      datadir         /usr/local/share
      mandir          /usr/local/share/man
      infodir         /usr/local/share/info
      docdir          /usr/local/share/doc/hercules-v4

Values from automake
  BUILD_HERCIFC        Defined
  BUILD_FTHREADS       Undefined
  BUILD_SHARED         Defined
  OPTION_DYNAMIC_LOAD  Defined

Values from make
  $CC                 cc
  $CFLAGS             -g  -W -Wall -O3  -g -g3 -ggdb3 -O3
  $CXX                c++
  $CXXFLAG            -g -O2
  $LDFLAGS            -Wl,--warn-common
  $CPPFLAGS           -DPKGDATADIR=\"/usr/local/share/hercules-v4\" -DMODULESDIR=\"/usr/local/lib/hercules-v4\" -DHERC_LOCALEDIR=\"/usr/local/share/locale\"

Values from configure
  $LIBS               -lrt -lz -lm  -pthread -lbz2 -L/usr/home/srorso/Hercules/amd64/s3fh/lib -lSoftFloat
  $S3FH_INC           /usr/home/srorso/Hercules/amd64/s3fh/include
  $S3FH_LIB           @S3FH_LIB@     (future use)
  $HQA_INC            .

Values generated by Makefile.am
  $AM_CPPFLAGS         -I/usr/home/srorso/Hercules/hyperion                                                      -I/usr/home/srorso/Hercules/hyperion/decNumber                       -I/usr/home/srorso/Hercules/amd64/s3fh/include                      -I.
  $DYNAMIC_VERISON
  $DYNMOD_LD_ADD       libherc.la                libhercs.la             libhercu.la             -lrt -lz -lm  -pthread -lbz2 -L/usr/home/srorso/Hercules/amd64/s3fh/lib -lSoftFloat
  $DYNMOD_LD_FLAGS     -module             -no-undefined                 -export-dynamic  -avoid-version
  $FTHREADS
  $HDEPS
  $HDLFLAGS
  $HERCIFC             hercifc
  $HERCLIBS
  $HERCLIBS2           libhercs.la  libhercu.la  libherct.la  libhercd.la  libherc.la
  $HERCLIN             herclin
  $LDADD               -lrt -lz -lm  -pthread -lbz2 -L/usr/home/srorso/Hercules/amd64/s3fh/lib -lSoftFloat
  $LIB_LD_FLAGS        -export-dynamic                   -no-undefined   -avoid-version
  $LTDL                ltdl.c
  $tools_ADDLIBS       libhercs.la  libhercu.la  libherct.la  libhercd.la  libherc.la -lrt -lz -lm  -pthread -lbz2 -L/usr/home/srorso/Hercules/amd64/s3fh/lib -lSoftFloat
  $tools_LD_FLAGS
  $XSTATIC

Note that the variable $XSTATIC is blank above. I expect it will have the value -static on your system. The contents of configuretrace.log should let me see what led the build process to that value.

And I now see that uname -r and uname -v should be added to the System information section. Live and learn.

Best Regards, Steve Orso

gurucubano commented 7 years ago

Hello Steve,

I run the commands w/o faking uname:

[guru@c720-r314251 ~/amd64/hyperion]$ sh -x -v ../../hyperion/configure >configuretrace.log 2>&1 [guru@c720-r314251 ~/amd64/hyperion]$ make diagnostic > diagnostic.log 2>&1 [guru@c720-r314251 ~/amd64/hyperion]$ ls -l configuretrace.log diagnostic.log config.log -rw-r--r-- 1 guru wheel 440027 10 abr. 16:40 config.log -rw-r--r-- 1 guru wheel 4031029 10 abr. 16:40 configuretrace.log -rw-r--r-- 1 guru wheel 3357 10 abr. 16:41 diagnostic.log

and will gzip the three files and attach them later.

HIH

matthias
gurucubano commented 7 years ago

diagnostic.log.gz config.log.gz configuretrace.log.gz

srorso commented 7 years ago

Hi Matthias:

It appears that you have gfortran installed on your workstation. Could you as a workaround attempt a Hercules build without gfortran visible? A rename of /usr/local/bin/gfortran to /usr/local/bin/savefortran would be sufficient.

Best Regards, Steve Orso

gurucubano commented 7 years ago

El día lunes, abril 10, 2017 a las 09:29:19a. m. -0700, Stephen Orso escribió:

Hi Matthias:

It appears that you have gfortran installed on your workstation. Could you as a workaround attempt a Hercules build without gfortran visible? A rename of /usr/local/bin/gfortran to /usr/local/bin/savefortran would be sufficient.

Hi Steven

This gfortran is part of the gcc-4.9.4 pkg and I have deinstalled this now:

ls -l /usr/local/bin/gfortran

lrwxr-xr-x 1 root wheel 25 5 mar. 11:56 /usr/local/bin/gfortran -> /usr/local/bin/gfortran49

pkg which /usr/local/bin/gfortran

/usr/local/bin/gfortran was installed by package gcc-4.9.4

pkg delete gcc-4.9.4

Checking integrity... done (0 conflicting) Deinstallation has been requested for the following 2 packages (of 0 packages in the universe):

Installed packages to be REMOVED: gcc-4.9.4 pdftk-2.02_4

Number of packages to be removed: 2

The operation will free 377 MiB.

Proceed with deinstalling packages? [y/N]: y [1/2] Deinstalling pdftk-2.02_4... [1/2] Deleting files for pdftk-2.02_4: 100% [2/2] Deinstalling gcc-4.9.4... [2/2] Deleting files for gcc-4.9.4: 100%

ls -l /usr/local/bin/gfortran

ls: /usr/local/bin/gfortran: No such file or directory

and after this it builds, installs and starts fine. Success!

Gracias

matthias
jphartmann commented 7 years ago

I don't know what you were using before deinstalling GCC, but now you must clearly be using CLANG, which is the default for FreeBSC since 10.

srorso commented 7 years ago

Hi Matthias,

De nada.

I am surprised that gcc in the FreeBSD repo includes gfortran, as other distros do not; I presume it is a separate package. I will learn more about this as I do functional and regression testing of a fix.

About which:

I found an ugly kludgy icky two line patch for Hercules's ancient libtools that should allow one to build Hercules on a FreeBSD 12 system with gcc installed. Or any system with FORTRAN installed.

Apparently FORTRAN does not support shared libraries. At least in the eyes of libtools.

Your good results made my day. Thanks!!

Best regards, Steve Orso

ps to John: FreeBSD 12 uses clang 4.0 at its default; most messages floating about regarding clang and Hercules mention 3.8.

srorso commented 7 years ago

Hi Matthias:

I installed gcc 4.9.4 on my 5-Apr snapshot, and I got the packages I expected. I did not get gfortran, so I suspect you are building gcc from source. And that's fine. But it means I cannot do functional testing of the build changes. I can and shall do the regression testing on Ubuntu, Debian, CentOS, Leap, Windows Subsystem for Linux, and of course FreeBSD. Native Windows uses a different build process.

So could I impose on you to run a functional check on a FreeBSD 12 system that still has gfortran installed?

I have committed fixes in (near?) final form in the master branch of my fork of Hercules V4 at https://github.com/srorso/hyperion. The last two commits in that fork have the fixes. Note: my fork of Hercules is my sandbox and nothing more. Everything there finds its way into Hercules-390.

If you would clone into a clean (empty) source directory and test on a FreeBSD 12 image that includes gcc and gfortran, it would be a great help.

And if you cannot, I understand...I can commit the build change to Hercules-390 with a clean set of regression tests.

Best Regards, Steve Orso