You're running into an issue with GnuCOBOL and bsd make. This was fixed for 3.1rc, so I suggest you use this one instead (or, if you really need the old 3.0 patch the makefiles by removing all order-only preerequisites | something. But really - get 3.1rc1 :-)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thanks for cleaning up my email Simon. I should have done better and studied the editor a bit.
I downloaded the July 1, 2020 version of gnucobol-3.1-rc1.tar.gz and started fresh. I thought I had that one already, but maybe it's been more than a few weeks since my last download.
I am using an OpenBSD snapshot, which I update weekly.
I just ran dmesg and noticed a string of these messages which show up on console whenever I run configure. One per configure attempt, I think. I wonder if this happens when configure is testing for environments, but just guessing.
I just ran dmesg and noticed a string of these messages which show up on console whenever I run configure. One per configure attempt, I think. I wonder if this happens when configure is testing for environments, but just guessing.
I'd guess the same.
a different problem feels like progress
It is! And it is one I've not encounted yet, I consider this a bonus!
Looks interesting.
the cobcrunbinary cannot be created because some functions are missing while others aren't... Let me guess: you have an older version of libcob installed on this system correct? The two issued functions are "newer" than the others.
I think this is related to your LDFLAGS (if this is an issue we could not workaround - and I think we can - then it should be checked in configure).
What happens if you do:
exportLOCALBASE=/usr/local
doas sh ./configure \LDFLAGS=-L${LOCALBASE}/lib -R${LOCALBASE}/lib" \ CPPFLAGS="-I${LOCALBASE}/include -I${LOCALBASE}/include/db4"
(I guess the same, just less identical include directories included)
and what happens with
exportLOCALBASE=/usr/local
doas sh ./configure CPPFLAGS="-I${LOCALBASE}/include/db4"
I'm positive that we'll have you setup sooner than later.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Oops, I should have mentioned the previously installed, and working, gnucobol-2.2p1 package from the OpenBSD website that is still lurking on this machine. I can remove it, if that will help.
exportLOCALBASE=/usr/local
doas sh ./configure LDFLAGS="-L${LOCALBASE}/lib -R${LOCALBASE}/lib"CPPFLAGS="-I${LOCALBASE}/include -I${LOCALBASE}/include/db4"
Oops, I should have mentioned the previously installed, and working, gnucobol-2.2p1 package from the OpenBSD website that is still lurking on this machine. I can remove it, if that will help.
Don't mind. It actually is considered a bug if you can't build GC correctly on a machine that has a separate install (it may need a bit more setup and care, but other than that, no issue).
... even if it would help for this installation (but not necessarily for GC in the bigger picture).
Sorry, I should have made that clear: as you've previously exported some variables you need to start a clean terminal (or re-login if you don't have the option to leace the terminal), then try again.
Please do so, edit the changes into your post (or create a new one and delete the old) and drop a note. we can then investigate further.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Don't mind. It actually is considered a bug if you can't build GC correctly on a machine that has a separate install (it may need a bit more setup and care, but other than that, no issue).
... even if it would help for this installation (but not necessarily for GC in the bigger picture).
If it helps you and improves the project, I can give you all the time you need. This is not a production cobol envronment. I am just playing with some old code. (nostalgia).
In the enviroment I have the following default path created by OpenBSD install:
daylight$ doas sh ./configure CPPFLAGS="-I${LOCALBASE}/include/db4" That terminal doesn't know about LOCALBASE from the other, so please retry with ./configure CPPFLAGS="-I/usr/local/include/db4".
As the configure looks good for both you may run makethere next. Side note: to keep environments separated use an out of tree build:
cd gnucobol-3.1rc1
# if previously configure you need to run `make distclean` once# but running the configure script from other places will remind you
mkdir build1
cd build1
../configure # and so on
make
mkdir build2
cd build2
../configure # different
make
Note: actually better then showing the configure output is posting config.log, from your build directory.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Side note: to keep environments separated use an out of tree build:
Done.
cd ../build1exportLOCALBASE=/usr/localdoassh ./configureLDFLAGS="-L${LOCALBASE}/lib -R${LOCALBASE}/lib"CPPFLAGS="-I${LOCALBASE}/include -I${LOCALBASE}/include/db4"
Thank you for providing these notes. config2.log is interesting because of the following:
-I/usr/local/include get's auto-included (by pkg-config for GMP, installed with the official "gmp" name)
BDB test fails as follows: configure:17360: gcc -std=gnu99 -o conftest -O2 -I/usr/local/include/db4 -I/usr/local/include conftest.c -ldb >&5
ld: error: unable to find library -ldb
so we see the include directory (from GMP) gets correctly taken over, but the library path, which is also included in GMP's pkg-config: configure:15168: checking if linking against libgmp with "-L/usr/local/lib -lgmp" works
configure:15181: gcc -std=gnu99 -o conftest -O2 -I/usr/local/include/db4 -I/usr/local/include conftest.c -L/usr/local/lib -lgmp >&5
is not included
this one even happens in GMP checks which is definitely wrong: checking for __gmp_get_memory_functions in -lgmp
configure:15486: gcc -std=gnu99 -o conftest -O2 -I/usr/local/include/db4 -I/usr/local/include conftest.c -lgmp >&5
ld: error: unable to find library -lgmp
... so I have something to fix the configure script in any case here.
And config1.log shows that the user-specified LDFLAGS are inserted before the main libtool, this can be fixed with adjusting the two Makefiles. You should be able to adjust
Yes, the configure command should (for now) stay the same as the working bdb one from above. The help2man part may be invoked because of the changed Makefiles, we can ignore that for now, just touch bin/cobcrun1.c cobc/cobc.1 to skip that.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
There's something really strange as your environment tries to updating a bunch of files it should not update. Where did you get the 3.1rc1 source from?
Last edit: Simon Sobisch 2020-08-26
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
daylight$ doas make checkall
Making check in .
Making check in lib
Making check in libcob
Making check in bin
Making check in cobc
make check-am
Making check in config
Making check in copy
Making check in po
Making check in extras
("../pre-inst-env" cobc -m -Wall -O2 -o "CBL_OC_DUMP.so" "CBL_OC_DUMP.cob" || "../pre-inst-env" cobc -m -Wall -o "CBL_OC_DUMP.so" "CBL_OC_DUMP.cob" || "../pre-inst-env" cobc -m -Wall -vv -o "CBL_OC_DUMP.so" "CBL_OC_DUMP.cob")
cobc:/home/puffy/gnucobol-3.2-dev/cobc/.libs/cobc: undefined symbol 'cob_hard_failure_internal'
ld.so: cobc: relocation failed
Killed
cobc:/home/puffy/gnucobol-3.2-dev/cobc/.libs/cobc: undefined symbol 'cob_hard_failure_internal'
ld.so: cobc: relocation failed
Killed
cobc:/home/puffy/gnucobol-3.2-dev/cobc/.libs/cobc: undefined symbol 'cob_hard_failure_internal'
ld.so: cobc: relocation failed
Killed
*** Error 137 in extras (Makefile:614 'CBL_OC_DUMP.so')
*** Error 1 in /home/puffy/gnucobol-3.2-dev (Makefile:661 'check-recursive': @fail=; if (target_option=k; case ${target_option-} in ?) ;; ...)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Out of interest: Is that "db.h" from Berkeley-DB and if yes what version is installed on the system? Even my system for compatibility-checks from year 2000 as db.h version 2.something (which is too old, so it also needs to be disabled) - but your system does not report any version [I guess 1.85 did so].
For curses: I guess you may have a header "curses.h" which matches the libncursesw, do you? Or is there only the library without the appropriate header?
The mlio.c:1310 warning definitely shows an error, I've fixed that in a current checkout but have to see if I've already fixed that in the pending XML PARSE commit (thet ypeck.c:14342 one definitely is).
The last time the linking of programs in the build tree did not work; this time the execution of the uninstalled binaries does not work, which is both an improvement and quite interesting.
Please do the following, it will very likely help:
I think the isue is related to rpath and that is related to the following lines seen in the configure output:
checking where the gettext function comes from... external libintl
checking how to link with libintl... /usr/local/lib/libintl.so.7.0 /usr/local/lib/libiconv.so.7.0 -Wl,-rpath,/usr/local/lib
If this is the case: Does it work when you configure with --disable-nls?
... that's one of the re-occuring issues, if we can't fix it now I hope we can after 3.2-rc1.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Not sure if this is useful, but here is the OpenBSD makefile for the above gnucobol package, which works fine at this time:
daylight$ cat Makefile
COMMENT= COBOL compiler, formerly known as OpenCOBOL
DISTNAME = gnucobol-3.1.2
REVISION = 0
SHARED_LIBS += cob 5.0 # 5.0
CATEGORIES = lang
HOMEPAGE = https://gnucobol.sourceforge.io/
# compiler: GPLv3+
# run-time library: LGPLv3+
PERMIT_PACKAGE = Yes
WANTLIB += c curses db gmp iconv intl json-c lzma m pthread xml2
WANTLIB += z
MASTER_SITES = ${MASTER_SITE_GNU:=gnucobol/}
# base makeinfo chokes on gnucobol texinfo files
BUILD_DEPENDS = print/texinfo
LIB_DEPENDS = databases/db/v4 \
devel/gettext,-runtime \
devel/gmp \
devel/json-c \
textproc/libxml
CONFIGURE_STYLE = gnu
CONFIGURE_ENV = LDFLAGS="${LDFLAGS} -L${LOCALBASE}/lib" \
CFLAGS="${CFLAGS} -I${LOCALBASE}/include" \
CPPFLAGS="${CPPFLAGS} -I${LOCALBASE}/include -I${LOCALBASE}/include/db4"
.include <bsd.port.mk>
You're stretching me a bit here, but curses is included in the o/s. The curses.h header file is at /usr/include/curses.h and contains the following:
/* $OpenBSD: curses.h,v 1.5 2019/01/25 00:19:25 millert Exp $ *//* * Placed in the public domain by Todd C. Miller <millert@openbsd.org> * on June 17, 2003. */#ifndef _CURSES_H_#define _CURSES_H_#include<ncurses.h>#endif /* _CURSES_H_ */
I remember playing around with curses a few years back, but ran out of time. More info here: https://man.openbsd.org/curses.
Please do the following, it will very likely help:
Not sure what the exit was for. There was nothing to exit. I think I have completely missed an important point. I'm going to blame covid, because that's what we can do now.
Thank you. This shows that we should again check for "plain curses.h" when looking for ncurses (I've removed that) and it also shows that the libtool generated wrapper script "bin/cobcrun" works different than directly executing the "real" binary - even if both have the same environment (which is setup by ./pre-inst-env).
Just to be 100% sure please do:
Note: this "exit", which you've wondered about before will leave the new shell environment that the pre-inst-env script creates if you don't pass it any program.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi all,
I have the OpenBSD package for v2.1 running fine, but thought I would take a run at installing V3. I got configure to run without errors by doing:
This is my configure output:
I tried to run make by doing:
And this is my make output:
Not sure what to do next.
Any pointers appreciated.
Gerald.
Last edit: Simon Sobisch 2020-08-21
You're running into an issue with GnuCOBOL and bsd make. This was fixed for 3.1rc, so I suggest you use this one instead (or, if you really need the old 3.0 patch the makefiles by removing all order-only preerequisites
| something. But really - get 3.1rc1 :-)Side note: it looks like you want to configure with
-R/usr/local/lib, not-R/usr/local/include.Thanks for cleaning up my email Simon. I should have done better and studied the editor a bit.
I downloaded the July 1, 2020 version of gnucobol-3.1-rc1.tar.gz and started fresh. I thought I had that one already, but maybe it's been more than a few weeks since my last download.
I am using an OpenBSD snapshot, which I update weekly.
The Configure works with less trouble. It even finds db4.
And the result
I just ran dmesg and noticed a string of these messages which show up on console whenever I run configure. One per configure attempt, I think. I wonder if this happens when configure is testing for environments, but just guessing.
The make is still having a problem, but a different problem feels like progress.
I'd guess the same.
It is! And it is one I've not encounted yet, I consider this a bonus!
Looks interesting.
the
cobcrunbinary cannot be created because some functions are missing while others aren't... Let me guess: you have an older version of libcob installed on this system correct? The two issued functions are "newer" than the others.I think this is related to your LDFLAGS (if this is an issue we could not workaround - and I think we can - then it should be checked in configure).
What happens if you do:
(I guess the same, just less identical include directories included)
and what happens with
I'm positive that we'll have you setup sooner than later.
Oops, I should have mentioned the previously installed, and working, gnucobol-2.2p1 package from the OpenBSD website that is still lurking on this machine. I can remove it, if that will help.
Produces the following:
and
Last edit: Simon Sobisch 2020-08-21
Don't mind. It actually is considered a bug if you can't build GC correctly on a machine that has a separate install (it may need a bit more setup and care, but other than that, no issue).
... even if it would help for this installation (but not necessarily for GC in the bigger picture).
Sorry, I should have made that clear: as you've previously exported some variables you need to start a clean terminal (or re-login if you don't have the option to leace the terminal), then try again.
Please do so, edit the changes into your post (or create a new one and delete the old) and drop a note. we can then investigate further.
If it helps you and improves the project, I can give you all the time you need. This is not a production cobol envronment. I am just playing with some old code. (nostalgia).
In the enviroment I have the following default path created by OpenBSD install:
On a new terminal instance
And on another new terminal instance:
Operators are standing by...
daylight$ doas sh ./configure CPPFLAGS="-I${LOCALBASE}/include/db4"That terminal doesn't know about LOCALBASE from the other, so please retry with./configure CPPFLAGS="-I/usr/local/include/db4".As the configure looks good for both you may run
makethere next. Side note: to keep environments separated use an out of tree build:Note: actually better then showing the configure output is posting config.log, from your build directory.
Aargh! I knew that and missed it.
Done.
Hopefully config1.log is attached to email.
Make results:
Results in config2.log
BDB error gives incomplete config. Unable to make.
Thank you for providing these notes. config2.log is interesting because of the following:
-I/usr/local/includeget's auto-included (by pkg-config for GMP, installed with the official "gmp" name)configure:17360: gcc -std=gnu99 -o conftest -O2 -I/usr/local/include/db4 -I/usr/local/include conftest.c -ldb >&5 ld: error: unable to find library -ldbconfigure:15168: checking if linking against libgmp with "-L/usr/local/lib -lgmp" works configure:15181: gcc -std=gnu99 -o conftest -O2 -I/usr/local/include/db4 -I/usr/local/include conftest.c -L/usr/local/lib -lgmp >&5is not included
checking for __gmp_get_memory_functions in -lgmp configure:15486: gcc -std=gnu99 -o conftest -O2 -I/usr/local/include/db4 -I/usr/local/include conftest.c -lgmp >&5 ld: error: unable to find library -lgmp... so I have something to fix the configure script in any case here.
And config1.log shows that the user-specified LDFLAGS are inserted before the main libtool, this can be fixed with adjusting the two Makefiles. You should be able to adjust
and be able to go on with "build1".
GnuCOBOL should likely put all those into the libcob.la file and remove the additional entries alltogether, but I need to check that.
After Makefile changes.
Running "../configure" produces the incomplete configuration attached as config.log-with-db.
Running "..configure --without-db produces the completed configuration attached as config.log-without-db.
Running the without-db config produces the following make output:
Yes, the configure command should (for now) stay the same as the working bdb one from above. The help2man part may be invoked because of the changed Makefiles, we can ignore that for now, just
touch bin/cobcrun1.c cobc/cobc.1to skip that.In a fresh build directory, on a fresh putty terminal:
creates the attached config.log
Produces the following output:
and here is the promised config.log...
Just to help the make output look a bit cleaner, I installed the help2man package and things look a bit different.
There's something really strange as your environment tries to updating a bunch of files it should not update. Where did you get the 3.1rc1 source from?
Last edit: Simon Sobisch 2020-08-26
https://sourceforge.net/projects/gnucobol/files/gnucobol/3.1/gnucobol-3.1-rc1.tar.gz/download
I could build a fresh OpenBSD machine and start again if that would help.
Can you please check if the nightly builds work for you?
https://ci.appveyor.com/api/projects/GitMensch/gnucobol-3-x/artifacts/gnucobol-3.1-dev.tar.gz?job=Image:%20Ubuntu1804 (Ubuntu1804 is just the OS that produced the build not a "target"). Testing this would be useful as some GNU make extensions are now only used if they are available.
That was a while ago, as I see it there was an issue with using the correct header during compilation in the scenario:
@gchudyk: That definitely works under 3.2 dev on Debian; as 3.2rc1 is near the front door and I don't have an OpenBSD installation around: Could you please check the nightly build tarball from https://ci.appveyor.com/api/buildjobs/rvw0arur14lx9yyd/artifacts/gnucobol-3.2-dev.tar.xz in the same scenario (and run
make checkallafter compilation)?I currently have the OpenBSD package installed as gnucobol-3.1.2p0
Downloaded gnucobol-3.2-dev.tar.xz and unpacked into my user directory as gnucobol-3.2-dev.
If I run a clean ./configure I get the following at the tail end:
So I use the --without-db option as follows:
daylight$cd gnucobol-3.2-dev
daylight$ doas ./configure --without-db
daylight$ doas make
daylight$ doas make checkall
Results as follows:
Out of interest: Is that "db.h" from Berkeley-DB and if yes what version is installed on the system? Even my system for compatibility-checks from year 2000 as db.h version 2.something (which is too old, so it also needs to be disabled) - but your system does not report any version [I guess 1.85 did so].
For curses: I guess you may have a header "curses.h" which matches the libncursesw, do you? Or is there only the library without the appropriate header?
The mlio.c:1310 warning definitely shows an error, I've fixed that in a current checkout but have to see if I've already fixed that in the pending
XML PARSEcommit (thet ypeck.c:14342 one definitely is).The last time the linking of programs in the build tree did not work; this time the execution of the uninstalled binaries does not work, which is both an improvement and quite interesting.
Please do the following, it will very likely help:
I think the isue is related to rpath and that is related to the following lines seen in the configure output:
If this is the case: Does it work when you configure with
--disable-nls?... that's one of the re-occuring issues, if we can't fix it now I hope we can after 3.2-rc1.
The following is the pkg info installed on my desktop.:
Not sure if this is useful, but here is the OpenBSD makefile for the above gnucobol package, which works fine at this time:
You're stretching me a bit here, but curses is included in the o/s. The curses.h header file is at /usr/include/curses.h and contains the following:
I remember playing around with curses a few years back, but ran out of time. More info here: https://man.openbsd.org/curses.
I also did this, in case it helps.
Not sure what the exit was for. There was nothing to exit. I think I have completely missed an important point. I'm going to blame covid, because that's what we can do now.
Thank you. This shows that we should again check for "plain curses.h" when looking for ncurses (I've removed that) and it also shows that the libtool generated wrapper script "bin/cobcrun" works different than directly executing the "real" binary - even if both have the same environment (which is setup by ./pre-inst-env).
Just to be 100% sure please do:
Note: this "exit", which you've wondered about before will leave the new shell environment that the pre-inst-env script creates if you don't pass it any program.