[Bug cobol/119217] cobol: build broken on non-linux by unguarded use of Linux-specific facilities.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119217 --- Comment #29 from rdubner at symas dot com --- > -Original Message- > From: ro at CeBiTec dot Uni-Bielefeld.DE > Sent: Tuesday, June 10, 2025 11:43 > To: rdub...@gcc.gnu.org > Subject: [Bug cobol/119217] cobol: build broken on non-linux by unguarded > use of Linux-specific facilities. > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119217 > > --- Comment #28 from ro at CeBiTec dot Uni-Bielefeld.DE Uni-Bielefeld.DE> --- > > --- Comment #27 from Robert Dubner --- > > I have managed to compile gcobol and libgcobol.so on a i386-pc-solaris > system. > > (Thanks, Richard!) > > Good! (It's Rainer btw.;-) My sincere apologies. I was looking at some other messages from Richard, and I conflated the names. I don't like getting names wrong. > > > Attempting to compile a COBOL source file with the resulting gcobol > executable > > results in this rather intriguing error message: > > > > cobol1: out of memory allocating 150 bytes after a total of 786432 > bytes. > > > > I will be looking into that. > > I found that you can avoid this by putting LANG=C in the environment. > Haven't yet investigated why this happens, though. Well. I tried it. My instant reaction was "Son Of A ..!" Because it worked! Putting LANG=C in front of the compilation not only resulted in the compilation succeeding, the executable created by a "DISPLAY "HELLO" COBOL source code file actually ran. When the time comes to track this down, the error in this case was caused by a call to regcmp() in the course of processing regular expressions. Of course, not much else worked, sadly. Errors abound. But it's hopeful that DISPLAY "HELLO" actually worked! I know I am coming in late here, after a lot of work done by other people. Thank you all. > > > Meanwhile, since it appears that all of the original issues raised in > this PR > > have been addressed to the point where I can compile on an i386-solaris > system, > > I am going to close this PR out. > > I think so, yes. Though there are other issues on other targets, > they're covered by separate PRs. > > Thanks for your help with all this. > > -- > You are receiving this mail because: > You are on the CC list for the bug.
[Bug cobol/119217] cobol: build broken on non-linux by unguarded use of Linux-specific facilities.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119217 --- Comment #28 from ro at CeBiTec dot Uni-Bielefeld.DE --- > --- Comment #27 from Robert Dubner --- > I have managed to compile gcobol and libgcobol.so on a i386-pc-solaris > system. > (Thanks, Richard!) Good! (It's Rainer btw.;-) > Attempting to compile a COBOL source file with the resulting gcobol executable > results in this rather intriguing error message: > > cobol1: out of memory allocating 150 bytes after a total of 786432 bytes. > > I will be looking into that. I found that you can avoid this by putting LANG=C in the environment. Haven't yet investigated why this happens, though. > Meanwhile, since it appears that all of the original issues raised in this PR > have been addressed to the point where I can compile on an i386-solaris > system, > I am going to close this PR out. I think so, yes. Though there are other issues on other targets, they're covered by separate PRs. Thanks for your help with all this.
[Bug cobol/119217] cobol: build broken on non-linux by unguarded use of Linux-specific facilities.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119217 Robert Dubner changed: What|Removed |Added Resolution|--- |FIXED Status|WAITING |RESOLVED --- Comment #27 from Robert Dubner --- I have managed to compile gcobol and libgcobol.so on a i386-pc-solaris system. (Thanks, Richard!) Attempting to compile a COBOL source file with the resulting gcobol executable results in this rather intriguing error message: cobol1: out of memory allocating 150 bytes after a total of 786432 bytes. I will be looking into that. Meanwhile, since it appears that all of the original issues raised in this PR have been addressed to the point where I can compile on an i386-solaris system, I am going to close this PR out.
[Bug cobol/119217] cobol: build broken on non-linux by unguarded use of Linux-specific facilities.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119217 --- Comment #26 from Robert Dubner --- *Thank* you. Those hints led to a successful compilation. This doesn't work: ../configure CONFIG_SHELL=/bin/bash --enable-languages=c,c++ --disable-multilib --disable-bootstrap So, I cribbed some of the information from doing a "gcc -v" and copying some of the "configured with" information. This does work: ../configure CONFIG_SHELL=/bin/bash --prefix=/usr/gcc/14 --enable-languages=ada,c,c++ --enable-shared --enable-initfini-array --disable-rpath --with-system-zlib --with-build-config=no --without-gnu-ld --with-ld=/usr/bin/ld --with-gnu-as --with-as=/usr/gnu/bin/as --disable-bootstrap x86_64-pc-solaris2.11 Doing a "make -sj10" takes twenty-three minutes, so figuring out what's important and what isn't by trial and error would take a little while. However, I am not going to bother. The next step will be --enable-languages=c,c++,cobol, and I'll see what happens. Thank you so much!
[Bug cobol/119217] cobol: build broken on non-linux by unguarded use of Linux-specific facilities.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119217 --- Comment #25 from ro at CeBiTec dot Uni-Bielefeld.DE --- Robert, > I have gotten access, through cfarm.net, to a Solaris system. It happens to > be > a big-endian sparc system: > > LDOM on Oracle SPARC T8-1 (big-endian) > Solaris 11.4 Oracle Solaris 11.4 SPARC 5.11 > > There are six or so Solaris machines; this happened to be the first one that > let me in. while this is fine, I'd start with a Solaris/x86 system (cfarm215) first. cfarm216, being SPARC (big-endian) and strict-alignment has quite a number of additional issues compared to Solaris/x86, so I'd start with the latter to keep things simpler. > I cloned the cobolworx copy of the repository. > > $ mkdir build && cd build && ../configure --disable-bootstrap > $gmake > > It instantly comes back with > > rdubner@s11-sparc:~/repos/gcc-cobol/build$ gmake > gmake[1]: Entering directory '/home/rdubner/repos/gcc-cobol/build' > mkdir ./fixincludes > Configuring in ./fixincludes > /home/rdubner/repos/fixincludes > /bin/sh: /home/rdubner/repos/gcc-cobol: cannot open [Is a directory] > gmake[1]: *** [Makefile:3981: configure-fixincludes] Error 1 > gmake[1]: Leaving directory '/home/rdubner/repos/gcc-cobol/build' > gmake: *** [Makefile:1064: all] Error 2 > > > Any advice for me, before I start reverse engineering several universes about > which I know nothing? Several things to keep in mind: * It's best to prepend /usr/gnu/bin to PATH: while the native tools should work in principle, I only test with the GNU ones myself. In this case, I wonder if /usr/bin/make is used in the fixincludes subdir above, which is *not* GNU make and doesn't understand its extensions. * Although I do test with CONFIG_SHELL=/bin/ksh (which is /bin/sh on Solaris) all the time, in case of problems you may want to use configure CONFIG_SHELL=/bin/bash ... instead to avoid a possible cause of problems. * Be sure to include --enable-languages=cobol --enable-libgcobol in the configure line. Both language and runtime lib are not yet enabled by default on Solaris. If you don't get further with those hints, I can have a look at your build if that's ok with you: I happen to run those two cfarm host :-)
[Bug cobol/119217] cobol: build broken on non-linux by unguarded use of Linux-specific facilities.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119217 Robert Dubner changed: What|Removed |Added CC||rdubner at gcc dot gnu.org --- Comment #24 from Robert Dubner --- (In reply to Rainer Orth from comment #11) > Created attachment 60959 [details] > Initial hacky patch to allow cobol1 to link on Solaris/amd64 Rainer, I have gotten access, through cfarm.net, to a Solaris system. It happens to be a big-endian sparc system: LDOM on Oracle SPARC T8-1 (big-endian) Solaris 11.4 Oracle Solaris 11.4 SPARC 5.11 There are six or so Solaris machines; this happened to be the first one that let me in. I cloned the cobolworx copy of the repository. $ mkdir build && cd build && ../configure --disable-bootstrap $gmake It instantly comes back with rdubner@s11-sparc:~/repos/gcc-cobol/build$ gmake gmake[1]: Entering directory '/home/rdubner/repos/gcc-cobol/build' mkdir ./fixincludes Configuring in ./fixincludes /home/rdubner/repos/fixincludes /bin/sh: /home/rdubner/repos/gcc-cobol: cannot open [Is a directory] gmake[1]: *** [Makefile:3981: configure-fixincludes] Error 1 gmake[1]: Leaving directory '/home/rdubner/repos/gcc-cobol/build' gmake: *** [Makefile:1064: all] Error 2 Any advice for me, before I start reverse engineering several universes about which I know nothing?
[Bug cobol/119217] cobol: build broken on non-linux by unguarded use of Linux-specific facilities.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119217 --- Comment #23 from Iain Sandoe --- what is the "waiting" status for? ( I don't see any trunk commits recently for us to test )
[Bug cobol/119217] cobol: build broken on non-linux by unguarded use of Linux-specific facilities.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119217 James K. Lowden changed: What|Removed |Added Status|NEW |WAITING
[Bug cobol/119217] cobol: build broken on non-linux by unguarded use of Linux-specific facilities.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119217 --- Comment #22 from James K. Lowden --- I removed use of glob(3) entirely. The code is actually simpler because there never was any wildcard; we just iterate over variations on the name. I also converted all stdio.h to cstdio, etc, for all such files. The commit is in our development branch. When applied, I believe this issue can be closed, because other parts have been addressed already.
[Bug cobol/119217] cobol: build broken on non-linux by unguarded use of Linux-specific facilities.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119217 --- Comment #21 from ro at CeBiTec dot Uni-Bielefeld.DE --- > --- Comment #20 from James K. Lowden --- > NAME_MAX has been removed entirely as of > ca44643f75c437fb1fb4b17e59b72bc836d12cc6. This commit isn't in the gcc repo yet. >> * GLOB_BRACE and GLOB_TILDE are not in POSIX.1 and missing on Solaris: > > What is the rule? When cobol is enabled, both c and c++ are built, too. I > was > told a bootstrap build is the standard, and that libgcobol should link to the > just-built libstdc++. Is that not true of libc, too? Or does that rule apply There's no libc inside the gcc tree, unlike libstdc++, and I know of no libc implementation portable to the wide variety of hosts and targets supported by gcc. > only to the target, whereas the compiler runs on the host and uses the host > system libraries? Neither: libc will always be the host resp. target libc. GCC is supposed to work on the primary and secondary platforms listed in the release criteria: https://gcc.gnu.org/gcc-15/criteria.html > The patch (which was applied) to #define GLOB_BRACE 0 indeed compiles, and > will > never work. Braces are supplied in the pattern as static text; if not > expanded > by the library, glob(3) will not execute the intended search. > > If we are constrained to work with every libc and not only glibc, then my > answer to would be to add xglob to libiberty. At least then the work would be > useful outside the GCC COBOL front end. I'd already mentioned (Comment #10) that gnulib provides an implementation of glob(3) that includes GLOB_BRACE and GLOB_TILDE. If it's feasible to integrate that is another question (the gnulib framework is considerable, though gdb currently uses it).
[Bug cobol/119217] cobol: build broken on non-linux by unguarded use of Linux-specific facilities.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119217 James K. Lowden changed: What|Removed |Added CC||jklowden at gcc dot gnu.org --- Comment #20 from James K. Lowden --- NAME_MAX has been removed entirely as of ca44643f75c437fb1fb4b17e59b72bc836d12cc6. > * GLOB_BRACE and GLOB_TILDE are not in POSIX.1 and missing on Solaris: What is the rule? When cobol is enabled, both c and c++ are built, too. I was told a bootstrap build is the standard, and that libgcobol should link to the just-built libstdc++. Is that not true of libc, too? Or does that rule apply only to the target, whereas the compiler runs on the host and uses the host system libraries? The patch (which was applied) to #define GLOB_BRACE 0 indeed compiles, and will never work. Braces are supplied in the pattern as static text; if not expanded by the library, glob(3) will not execute the intended search. If we are constrained to work with every libc and not only glibc, then my answer to would be to add xglob to libiberty. At least then the work would be useful outside the GCC COBOL front end.
[Bug cobol/119217] cobol: build broken on non-linux by unguarded use of Linux-specific facilities.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119217 --- Comment #19 from GCC Commits --- The master branch has been updated by Rainer Orth : https://gcc.gnu.org/g:1df8fffba30bf4022dda762bf61acf16ac704c67 commit r16-469-g1df8fffba30bf4022dda762bf61acf16ac704c67 Author: Rainer Orth Date: Thu May 8 09:39:26 2025 +0200 cobol: Allow for undefined NAME_MAX [PR119217] All users of symbols.h fail to compile on Solaris: /vol/gcc/src/hg/master/local/gcc/cobol/symbols.h: At global scope: /vol/gcc/src/hg/master/local/gcc/cobol/symbols.h:1365:13: error: âNAME_MAXâ was not declared in this scope 1365 | char name[NAME_MAX]; | ^~~~ NAME_MAX being undefined is allowed by POSIX.1, actually: it's listed for under "Pathname Variable Values": A definition of one of the symbolic constants in the following list shall be omitted from the header on specific implementations where the corresponding value is equal to or greater than the stated minimum, but where the value can vary depending on the file to which it is applied. The actual value supported for a specific pathname shall be provided by the pathconf() function. As a hack, this patch provides a fallback definition to allow the build to finish. In fact it turned out that cbl_funtion_t.name isn't filename related and never set at all, so this patch serves as a mere stopgap fix to unbreak the build until a real solution can be figured out. Bootstrapped without regressions on amd64-pc-solaris2.11, sparcv9-sun-solaris2.11, and x86_64-pc-linux-gnu. 2025-04-08 Rainer Orth gcc/cobol: PR cobol/119217 * symbols.h (NAME_MAX): Define fallback.
[Bug cobol/119217] cobol: build broken on non-linux by unguarded use of Linux-specific facilities.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119217
--- Comment #18 from GCC Commits ---
The master branch has been updated by Rainer Orth :
https://gcc.gnu.org/g:12d6fa2a21140166181ae3be7711d60e62c569d7
commit r16-467-g12d6fa2a21140166181ae3be7711d60e62c569d7
Author: Rainer Orth
Date: Thu May 8 09:29:56 2025 +0200
cobol: Initialize regmatch_t portably [PR119217]
The dts.h initialization of regmatch_t currently breaks Solaris
compilation:
In file included from /vol/gcc/src/hg/master/local/gcc/cobol/lexio.h:208,
from /vol/gcc/src/hg/master/local/gcc/cobol/lexio.cc:36:
/vol/gcc/src/hg/master/local/gcc/cobol/dts.h: In constructor
âdts::csub_match::csub_match(const char*)â:
/vol/gcc/src/hg/master/local/gcc/cobol/dts.h:36:35: error: invalid
conversion from âintâ to âconst char*â [-fpermissive]
36 | static regmatch_t empty = { -1, -1 };
| ^~
| |
| int
The problem is that Solaris regmatch_t has additional members before
rm_so and rm_eo, as is always allowed by POSIX.1
typedef struct {
const char *rm_sp, *rm_ep; /* Start pointer, end pointer */
regoff_trm_so, rm_eo; /* Start offset, end offset */
int rm_ss, rm_es; /* Used internally */
} regmatch_t;
so the initialization doesn't do what it's supposed to do.
Fixed by initializing the rm_so and rm_eo members explicitly.
Bootstrapped without regressions on amd64-pc-solaris2.11,
sparcv9-sun-solaris2.11, and x86_64-pc-linux-gnu.
2025-04-08 Rainer Orth
gcc/cobol:
PR cobol/119217
* dts.h (csub_match): Initialize rm_so, rm_eo fields explicitly.
[Bug cobol/119217] cobol: build broken on non-linux by unguarded use of Linux-specific facilities.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119217 --- Comment #17 from GCC Commits --- The master branch has been updated by Rainer Orth : https://gcc.gnu.org/g:aacaa3b13bca508cb6cb803d11cb942b2de8c0db commit r16-463-gaacaa3b13bca508cb6cb803d11cb942b2de8c0db Author: Rainer Orth Date: Thu May 8 09:21:45 2025 +0200 cobol: Don't require GLOB_BRACE etc. [PR119217] cdf-copy.cc doesn't compile on Solaris: /vol/gcc/src/hg/master/local/gcc/cobol/cdf-copy.cc: In member function âint copybook_elem_t::open_file(const char*, bool)â: /vol/gcc/src/hg/master/local/gcc/cobol/cdf-copy.cc:317:34: error: âGLOB_BRACEâ was not declared in this scope; did you mean âGLOB_ERRâ? 317 | static int flags = GLOB_MARK | GLOB_BRACE | GLOB_TILDE; | ^~ | GLOB_ERR /vol/gcc/src/hg/master/local/gcc/cobol/cdf-copy.cc:317:47: error: âGLOB_TILDEâ was not declared in this scope 317 | static int flags = GLOB_MARK | GLOB_BRACE | GLOB_TILDE; | ^~ GLOB_BRACE and GLOB_TILDE are BSD extensions not in POSIX.1, thus missing on Solaris probably due to its System V heritage. This patch introduces fallback definitions to avoid this. Bootstrapped without regressions on amd64-pc-solaris2.11, sparcv9-sun-solaris2.11, and x86_64-pc-linux-gnu. 2025-04-08 Rainer Orth gcc/cobol: PR cobol/119217 * cdf-copy.cc (GLOB_BRACE): Define fallback. (GLOB_TILDE): Likewise.
[Bug cobol/119217] cobol: build broken on non-linux by unguarded use of Linux-specific facilities.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119217 --- Comment #16 from GCC Commits --- The releases/gcc-15 branch has been updated by Rainer Orth : https://gcc.gnu.org/g:05941b93dfc19686d6b9c9ca5aecf3a6b28a15a5 commit r15-9569-g05941b93dfc19686d6b9c9ca5aecf3a6b28a15a5 Author: Rainer Orth Date: Tue Apr 22 13:47:17 2025 +0200 cobol: Restrict COBOL to supported Linux arches [PR119217] The COBOL frontend is currently built on all x86_64 and aarch64 hosts although the code contains some Linux/glibc specifics that break the build e.g. on Solaris/amd64. Tested on Linux/x86_64 and Solaris/amd64. 2025-03-17 Rainer Orth PR cobol/119217 * configure.ac: Restrict cobol to aarch64-*-linux*, x86_64-*-linux*. Fix indentation. * configure: Regenerate. (cherry picked from commit 6390fc86995fbd5239497cb9e1797a3af51d3936)
[Bug cobol/119217] cobol: build broken on non-linux by unguarded use of Linux-specific facilities.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119217 --- Comment #15 from GCC Commits --- The master branch has been updated by Rainer Orth : https://gcc.gnu.org/g:6390fc86995fbd5239497cb9e1797a3af51d3936 commit r16-81-g6390fc86995fbd5239497cb9e1797a3af51d3936 Author: Rainer Orth Date: Tue Apr 22 13:47:17 2025 +0200 cobol: Restrict COBOL to supported Linux arches [PR119217] The COBOL frontend is currently built on all x86_64 and aarch64 hosts although the code contains some Linux/glibc specifics that break the build e.g. on Solaris/amd64. Tested on Linux/x86_64 and Solaris/amd64. 2025-03-17 Rainer Orth PR cobol/119217 * configure.ac: Restrict cobol to aarch64-*-linux*, x86_64-*-linux*. Fix indentation. * configure: Regenerate.
[Bug cobol/119217] cobol: build broken on non-linux by unguarded use of Linux-specific facilities.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119217 --- Comment #14 from GCC Commits --- The master branch has been updated by Rainer Orth : https://gcc.gnu.org/g:b0fb746bf2ff533eccf3a4ea7fbbc02a9a1f8b81 commit r15-9416-gb0fb746bf2ff533eccf3a4ea7fbbc02a9a1f8b81 Author: Rainer Orth Date: Sun Apr 13 22:48:44 2025 +0200 cobol: Avoid conflict with OVERFLOW in system headers [PR119217] parse.h causes the COBOL build to break on Solaris: cobol/parse.h:356:5: error: expected identifier before numeric constant 356 | OVERFLOW = 305,/* OVERFLOW */ | ^~~~ The problem is that has #define OVERFLOW3 To avoid the conflict, this patch renames OVERFLOW to OVERFLOW_kw, following existing praxis. Btw., token_names.h has a comment claiming // generated by ./token_names.h.gen ../../build/gcc/cobol/parse.h but there's no token_names.h.gen anywhere in the tree, so I've updated the file manually. Bootstrapped without regressions on amd64-pc-solaris2.11, sparcv9-sun-solaris2.11, and x86_64-pc-linux-gnu. 2025-04-08 Rainer Orth gcc/cobol: PR cobol/119217 * parse.y: Rename OVERFLOW to OVERFLOW_kw. Specify type name in %token directive. * scan.l: Likewise. * token_names.h: Regenerate. Co-Authored-By: Simon Sobisch
[Bug cobol/119217] cobol: build broken on non-linux by unguarded use of Linux-specific facilities.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119217
--- Comment #13 from GCC Commits ---
The master branch has been updated by Rainer Orth :
https://gcc.gnu.org/g:962c3d69f189f6fa451153faf3ce261c50d23d5a
commit r15-9413-g962c3d69f189f6fa451153faf3ce261c50d23d5a
Author: Rainer Orth
Date: Sun Apr 13 12:53:54 2025 +0200
cobol: Avoid conflict with timespec_t in system headers [PR119217]
util.cc doesn't compile on Solaris:
/vol/gcc/src/hg/master/local/gcc/cobol/util.cc:2135:7: error: using
typedef-name âtimespec_tâ after âclassâ
2135 | class timespec_t {
| ^~
This happens because declares timespec_t itself. In fact,
POSIX.1 reserves every *_t identifier, so this is benign.
To avoid the problem, this patch renames the cobol timespec_t to
cbl_timespec.
Bootstrapped without regressions on amd64-pc-solaris2.11,
sparcv9-sun-solaris2.11, and x86_64-pc-linux-gnu.
2025-04-08 Rainer Orth
gcc/cobol:
PR cobol/119217
* util.cc (class timespec_t): Rename to cbl_timespec.
[Bug cobol/119217] cobol: build broken on non-linux by unguarded use of Linux-specific facilities.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119217 --- Comment #12 from ro at CeBiTec dot Uni-Bielefeld.DE --- I've now posted proper patches for the various issues breaking the compilation of the COBOL frontend on Solaris: cobol: Don't require GLOB_BRACE etc. [PR119217] https://gcc.gnu.org/pipermail/gcc-patches/2025-April/680675.html cobol: Initialize regmatch_t portably [PR119217] https://gcc.gnu.org/pipermail/gcc-patches/2025-April/680676.html cobol: Heed ASM_COMMENT_START https://gcc.gnu.org/pipermail/gcc-patches/2025-April/680677.html cobol: Avoid conflict with OVERFLOW in system headers [PR119217] https://gcc.gnu.org/pipermail/gcc-patches/2025-April/680678.html cobol: Allow for undefined NAME_MAX [PR119217] https://gcc.gnu.org/pipermail/gcc-patches/2025-April/680682.html cobol: Avoid conflict with timespec_t in system headers [PR119217] https://gcc.gnu.org/pipermail/gcc-patches/2025-April/680681.html libgcobol: Use strchr instead of index libgcobol/valconv.cc There are a few more for libgcobol, but those are not for this PR.
[Bug cobol/119217] cobol: build broken on non-linux by unguarded use of Linux-specific facilities.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119217 Bug 119217 depends on bug 119295, which changed state. Bug 119295 Summary: cobol, libcobol uses random_r which is GLIBC specific https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119295 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug cobol/119217] cobol: build broken on non-linux by unguarded use of Linux-specific facilities.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119217 --- Comment #11 from Rainer Orth --- Created attachment 60959 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60959&action=edit Initial hacky patch to allow cobol1 to link on Solaris/amd64
[Bug cobol/119217] cobol: build broken on non-linux by unguarded use of Linux-specific facilities.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119217
--- Comment #10 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #5 from Rainer Orth ---
Given the recent flurry of activity to make the COBOL frontend (and
libgcobol) more portable, I've given a Solaris/amd64 build another try.
Some issues remain, while others are new.
> * GLOB_BRACE and GLOB_TILDE are not in POSIX.1 and missing on Solaris:
>
> /vol/gcc/src/hg/master/local/gcc/cobol/cdf-copy.cc: In member function ‘int
> copybook_elem_t::open_file(const char*, bool)’:
> /vol/gcc/src/hg/master/local/gcc/cobol/cdf-copy.cc:317:34: error: ‘GLOB_BRACE’
> was not declared in this scope; did you mean ‘GLOB_ERR’?
> 317 | static int flags = GLOB_MARK | GLOB_BRACE | GLOB_TILDE;
> | ^~
> | GLOB_ERR
> /vol/gcc/src/hg/master/local/gcc/cobol/cdf-copy.cc:317:47: error: ‘GLOB_TILDE’
> was not declared in this scope
> 317 | static int flags = GLOB_MARK | GLOB_BRACE | GLOB_TILDE;
> | ^~
As a hack, I've simply defined both GLOB_BRACE and GLOB_TILDE as 0 if
they are missing. Alternatively, gnulib has a version glob that
supports both, although I don't know if we want to go this route (gdb
has, for example).
> * NAME_MAX is undefined on Solaris since it can vary by path, as allowed by
> POSIX.1:
>
> /vol/gcc/src/hg/master/local/gcc/cobol/symbols.h: At global scope:
> /vol/gcc/src/hg/master/local/gcc/cobol/symbols.h:1365:13: error: ‘NAME_MAX’
> was
> not declared in this scope
> 1365 | char name[NAME_MAX];
> | ^~~~
Again, I provided a fallback definition (255) for this case.
* valconv.cc uses index without a declaration:
cobol/valconv.cc: In function ‘bool __gg__string_to_numeric_edited(char*,
char*, int, int, const char*)’:
cobol/valconv.cc:856:40: error: ‘index’ was not declared in this scope; did you
mean ‘Rindex’?
856 | const char *decimal_location = index(dest,
__gg__decimal_point); |^
|Rindex
On Solaris, this needs . One should simply use strchr instead.
* The initialization of regmatch_t breaks:
In file included from /vol/gcc/src/hg/master/local/gcc/cobol/lexio.h:208,
from /vol/gcc/src/hg/master/local/gcc/cobol/lexio.cc:36:
/vol/gcc/src/hg/master/local/gcc/cobol/dts.h: In constructor
‘dts::csub_match::csub_match(const char*)’:
/vol/gcc/src/hg/master/local/gcc/cobol/dts.h:36:35: error: invalid conversion
from ‘int’ to ‘const char*’ [-fpermissive]
36 | static regmatch_t empty = { -1, -1 };
| ^~
| |
| int
Solaris has
typedef struct {
const char *rm_sp, *rm_ep; /* Start pointer, end pointer */
regoff_trm_so, rm_eo; /* Start offset, end offset */
int rm_ss, rm_es; /* Used internally */
} regmatch_t;
(additional members are always allowed). I didn't use designated
initializers here since that causes warnings like
/vol/gcc/src/hg/master/cobol/gcc/cobol/dts.h:36:60: warning: missing
initializer for member ‘regmatch_t::rm_ep’ [-Wmissing-field-initializers]
* Using timespec_t as a class name breaks:
/vol/gcc/src/hg/master/local/gcc/cobol/util.cc:2135:7: error: using
typedef-name ‘timespec_t’ after ‘class’
2135 | class timespec_t {
| ^~
Solaris declares timespec_t itself. Besides, *_t
identifies are reserved by POSIX.1. I've renamed this to
cbl_timespec_t (should probably be cbl_timespec or some such instead).
* Solaris defines OVERFLOW, clashing with the like-named
identifier in the scanner/parser:
cobol/parse.h:356:5: error: expected identifier before numeric constant
356 | OVERFLOW = 305,/* OVERFLOW */
| ^~~~
To avoid this, I've renamed it to OVERFLOW_kw in line with other such
cases.
With those changes/hacks (attached for reference), I managed to build
cobol1 on amd64-pc-solaris2.11.
libgcobol is another matter, primarily for lack of the C23 *128
functions, but also initstate_r, srandom_r, and tm_zone in struct tm.
I'll give that another try once Iain's work to use libquadmath lands.
[Bug cobol/119217] cobol: build broken on non-linux by unguarded use of Linux-specific facilities.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119217 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #9 from Jakub Jelinek --- Yeah. Given the current restriction of targets which support _Float128 (and __int128), the compiler should be either using real.cc APIs or mpfr to work on the IEEE quad floating point (e.g. convert from string, to string, rounding, arithmetics on it) and for __int128 either wide_int or gmp.
[Bug cobol/119217] cobol: build broken on non-linux by unguarded use of Linux-specific facilities.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119217 --- Comment #8 from Andreas Schwab --- The compiler should not use any host facilities to parse floating literals in the first place.
[Bug cobol/119217] cobol: build broken on non-linux by unguarded use of Linux-specific facilities.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119217
--- Comment #7 from ro at CeBiTec dot Uni-Bielefeld.DE ---
The _Float128 handling is completely unportable, it turns out:
#if ! (__HAVE_FLOAT128 && __GLIBC_USE (IEC_60559_TYPES_EXT))
__HAVE_FLOAT128 is a glibc-internal macro, as is __GLIBC_USE. On top of
that, the fallback code providing strfromf128 is unportable in itself:
it uses strfroml, which is a C23 addition apparently. I don't think we
can reasonably require C23 support on the host.
Besides, both libstd++ and libgfortran already provide fallback code to
handle this situation:
cf. libstdc++-v3/src/c++17/floating_{from,to}_chars.cc and
libgfortran/io/{read.c,write_float.def}.
[Bug cobol/119217] cobol: build broken on non-linux by unguarded use of Linux-specific facilities.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119217 --- Comment #6 from Iain Sandoe --- I notice that symbols.h (and other places) also has a lot of unconditional includes of platform headers. Not sure if/how those might conflict with the system.h approach. Not sure why &friends instead of &friend if the intention is to be C++ code #include #include #include #include #include #include #include #include #include #include #include #include #include
[Bug cobol/119217] cobol: build broken on non-linux by unguarded use of Linux-specific facilities.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119217 Rainer Orth changed: What|Removed |Added Ever confirmed|0 |1 CC||ro at gcc dot gnu.org Last reconfirmed||2025-03-11 Status|UNCONFIRMED |NEW --- Comment #5 from Rainer Orth --- I see more such issues on Solaris: * GLOB_BRACE and GLOB_TILDE are not in POSIX.1 and missing on Solaris: /vol/gcc/src/hg/master/local/gcc/cobol/cdf-copy.cc: In member function ‘int copybook_elem_t::open_file(const char*, bool)’: /vol/gcc/src/hg/master/local/gcc/cobol/cdf-copy.cc:317:34: error: ‘GLOB_BRACE’ was not declared in this scope; did you mean ‘GLOB_ERR’? 317 | static int flags = GLOB_MARK | GLOB_BRACE | GLOB_TILDE; | ^~ | GLOB_ERR /vol/gcc/src/hg/master/local/gcc/cobol/cdf-copy.cc:317:47: error: ‘GLOB_TILDE’ was not declared in this scope 317 | static int flags = GLOB_MARK | GLOB_BRACE | GLOB_TILDE; | ^~ * NAME_MAX is undefined on Solaris since it can vary by path, as allowed by POSIX.1: /vol/gcc/src/hg/master/local/gcc/cobol/symbols.h: At global scope: /vol/gcc/src/hg/master/local/gcc/cobol/symbols.h:1365:13: error: ‘NAME_MAX’ was not declared in this scope 1365 | char name[NAME_MAX]; | ^~~~
[Bug cobol/119217] cobol: build broken on non-linux by unguarded use of Linux-specific facilities.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119217 --- Comment #4 from Xi Ruoyao --- (In reply to Richard Biener from comment #3) > Nah, cobol isn't a primary or default language. Oh I wrongly thought it was enabled by default.
[Bug cobol/119217] cobol: build broken on non-linux by unguarded use of Linux-specific facilities.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119217 Richard Biener changed: What|Removed |Added Priority|P1 |P3 --- Comment #3 from Richard Biener --- Nah, cobol isn't a primary or default language.
[Bug cobol/119217] cobol: build broken on non-linux by unguarded use of Linux-specific facilities.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119217 --- Comment #2 from Richard Biener --- Possibly the _Float128 uses in the frontend can go away by using real.h or alternatively mpfr.h
[Bug cobol/119217] cobol: build broken on non-linux by unguarded use of Linux-specific facilities.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119217 Xi Ruoyao changed: What|Removed |Added CC||xry111 at gcc dot gnu.org Priority|P3 |P1 Blocks||119211 --- Comment #1 from Xi Ruoyao --- P1 as we have non-Linux primary targets. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119211 [Bug 119211] [15 Regression] Cobol GCC 15 release checklist
