GnuCOBOL / Bugs / #627 configure script does not handle multiple blacklisted CFLAGS

Toshio Kuratomi - 2020-04-15

Hmmm.... There's another problem in the sed handling which is exacerbated by my patch... -g is being used in the gnucobolo build like this:

-grecord-gcc-switches

This is munged by the first sed line which does:

-e 's/-g//'

If there's no -g flag given in CFLAGS, then the -g gets stripped from gnucobol's -grecord-gcc-switches line.

My patch makes it worse because it makes that sed command global and thus the -g gets stripped from -grecord-gcc-switches even if there is a prior -g switch but the underlying problem is independent of my change.

Last edit: Toshio Kuratomi 2020-04-17

fix-cflags-munging.patch

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Gwyn Ciesla - 2020-04-16

In my review we're using this patch alongside %configure --enable-debug.
https://bugzilla.redhat.com/show_bug.cgi?id=1823419

stackprotector.patch

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Edward Hart - 2020-04-16

labels: --> configure

Description has changed:

Diff:

--- old +++ new @@ -6,3 +6,5 @@ configure: COB_CFLAGS -I/usr/local/include -Wno-unused -fsigned-char -Wno-pointer-sign -strong -I/usr/include/libdb4 -pipe Patch which fixes this attached but my autoconf and shell scripting skills are a bit rusty so you may end up changing it a little bit. + +Related to [bugs:#528] and [bugs:#547].

status: open --> needs-merge

Priority: 5 - default --> 4

Related

Bugs: ~~#528~~
Bugs: ~~#547~~

Last edit: Simon Sobisch 2020-04-16
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Edward Hart - 2020-04-16

Thank you both for reporting this!

I've committed a fix to trunk in [r3531]. There have been changes to configure.ac since 2.2, so the fix is basically a merge of both your patches.

@sf-mensch Could you please move this ticket from patches to bugs?

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Simon Sobisch - 2020-04-16

Ticket moved from /p/open-cobol/patches/49/

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Simon Sobisch - 2020-04-16

assigned_to: Simon Sobisch
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Simon Sobisch - 2020-04-16

Moved as requested. Thank you all three for taking care; I try to check and merge to 3.x tonight and would suggest that for Fedora a test-build with a 3.1-dev tarball is done instead of the old 3.0rc1 (which will not get a release and is outdated) after my merge. I'll drop a note here.

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Simon Sobisch - 2020-04-17

Changes merged with [r3533]. @abadger1999 and @limburgher can you please check if this removes the need for any patches on your side? You may do so using the nightly tarballs, in this case the URL is https://ci.appveyor.com/api/projects/GitMensch/gnucobol-3-x/artifacts/gnucobol-3.1-dev.tar.gz?job=Image:%20Ubuntu1804

In any case two notes to the spec file:

you may also use .lz or .xz instead of the .gz (I have no idea what the best-practices in Fedora look like)

please recheck the spec file in our vcs, you find it at https://sourceforge.net/p/open-cobol/code/HEAD/tree/branches/gnucobol-3.x/gnucobol.spec and compare to yours (I guess there are mistakes in both an possibly errors in our).
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Gwyn Ciesla - 2020-04-17

I get the following with the nightly and no patches:

Making all in extras
make[2]: Entering directory '/home/gwyn/rpmbuild/BUILD/gnucobol-3.1-dev/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: symbol lookup error: cobc: undefined symbol: cob_is_valid_uri
cobc: symbol lookup error: cobc: undefined symbol: cob_is_valid_uri
cobc: symbol lookup error: cobc: undefined symbol: cob_is_valid_uri
make[2]: *** [Makefile:594: CBL_OC_DUMP.so] Error 127

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
- Simon Sobisch - 2020-04-17
  
  Thank you for the feedback. This likely means that it uses a system-installed libcob instead of the one that should be taken by means of pre-inst-env.
  Can you please investigate why this is the case? Would LD_PRELOAD be evil to use there?
  
  If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Gwyn Ciesla - 2020-04-17

You would appear to be correct, uninstalling 3.0-rc1 allows 3.1-dev to build, and it builds with 3.1-dev installed.

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Toshio Kuratomi - 2020-04-17

I think LD_PRELOAD as part of the build process is fine. IIRC, it doesn't encode anything into the built object; it just tells the currently running code to looks for a library somewhere it normally wouldn't.

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

@abadger1999 and @limburger - I don't run Fedora currently and am a bit confused what's going on, can you please recheck?

This is what I've done on a Debian system (with GnuCOBOL 2.2 installed, which also don't have the entry point that was the issue in your case) and after make of GnuCOBOL 3.1-dev (with nearly the maximum of optional dependencies [you may consider to add some of these to the .spec file, ideally as "--with-xyz"]) :

simon@Soprano:/tmp/gnucobol-3.1-dev$ ldd $(which cobc)
        linux-vdso.so.1 (0x00007fffeedb2000)
        libcob.so.4 => /usr/lib/x86_64-linux-gnu/libcob.so.4 (0x00007ff89d740000)
        libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007ff89d570000)
        libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007ff89d3e0000)
        libgmp.so.10 => /usr/lib/x86_64-linux-gnu/libgmp.so.10 (0x00007ff89d350000)
        libncursesw.so.6 => /lib/x86_64-linux-gnu/libncursesw.so.6 (0x00007ff89d310000)
        libtinfo.so.6 => /lib/x86_64-linux-gnu/libtinfo.so.6 (0x00007ff89d2e0000)
        libdb-5.3.so => /usr/lib/x86_64-linux-gnu/libdb-5.3.so (0x00007ff89d110000)
        libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007ff89d100000)
        /lib64/ld-linux-x86-64.so.2 (0x00007ff89d8a9000)
        libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007ff89d0df000)
simon@Soprano:/tmp/gnucobol-3.1-dev$ ./pre-inst-env which cobc
/tmp/gnucobol-3.1-dev/cobc/.libs/cobc
simon@Soprano:/tmp/gnucobol-3.1-dev$ ./pre-inst-env ldd $(which cobc)
        linux-vdso.so.1 (0x00007fffe674a000)
        libcob.so.4 => /tmp/gnucobol-3.1-dev/libcob/.libs/libcob.so.4 (0x00007f68fe70c000)
        libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f68fe540000)
        libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f68fe3b0000)
        libxml2.so.2 => /usr/lib/x86_64-linux-gnu/libxml2.so.2 (0x00007f68fe200000)
        libcjson.so.1 => /usr/lib/x86_64-linux-gnu/libcjson.so.1 (0x00007f68fe1f0000)
        libgmp.so.10 => /usr/lib/x86_64-linux-gnu/libgmp.so.10 (0x00007f68fe160000)
        libncursesw.so.6 => /lib/x86_64-linux-gnu/libncursesw.so.6 (0x00007f68fe110000)
        libtinfo.so.6 => /lib/x86_64-linux-gnu/libtinfo.so.6 (0x00007f68fe0e0000)
        libdb-5.3.so => /usr/lib/x86_64-linux-gnu/libdb-5.3.so (0x00007f68fdf20000)
        libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f68fdf10000)
        /lib64/ld-linux-x86-64.so.2 (0x00007f68fe891000)
        libicui18n.so.63 => /usr/lib/x86_64-linux-gnu/libicui18n.so.63 (0x00007f68fdc30000)
        libicuuc.so.63 => /usr/lib/x86_64-linux-gnu/libicuuc.so.63 (0x00007f68fda60000)
        libicudata.so.63 => /usr/lib/x86_64-linux-gnu/libicudata.so.63 (0x00007f68fc060000)
        libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007f68fbe40000)
        liblzma.so.5 => /lib/x86_64-linux-gnu/liblzma.so.5 (0x00007f68fbe10000)
        libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f68fbdef000)
        libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007f68fbc60000)
        libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f68fbc30000)

What we can see and should know:

old installed environment has standard libraries, and is resolved fine
new not-yet-installed environment has own libraries + standard libraries, and is resolved fine
the setup for the later is done via pre-inst-env, which sets, along to other entries, PATH (which is the reason your not-yet-installed cobc is found) and LD_LIBRARY_PATH

Something must be different on your side, there should be no need to uninstall something before building the new version.

Can you check what's going on?

As a secondary thing: pre-inst-env should likely setup the libtool wrapper in PATH as those are explicit there to prevent issues like this. Is there any difference if you change pre-inst-env (either after configure or before in build_aux) as follows?

-PATH="$abs_top_builddir/cobc/.libs${sep}$abs_top_builddir/cobc${sep}$PATH"
-PATH="$abs_top_builddir/bin/.libs${sep}$abs_top_builddir/bin${sep}$PATH"
+PATH="$abs_top_builddir/cobc${sep}$PATH"
+PATH="$abs_top_builddir/bin${sep}$PATH"
 PATH="$abs_top_builddir/libcob/.libs${sep}$abs_top_builddir/libcob${sep}$PATH"
 export PATH

Thank you for your report in advance,
Simon

BTW: LD_PRELOAD seems wrongm as it would force a use of a different ABI file, too (OpenCOBOL 1.1 and GnuCOBOL 2.2-3.x have a different ABI version than GnuCOBOL 4.0), if I'm not wrong.

Gwyn Ciesla - 2020-04-20

It would appear that cobc/.libs/cobc is linked against the system version:

gwyn@gwythsefyll .libs]$ ldd cobc
linux-vdso.so.1 (0x00007ffe7d682000)
libcob.so.4 => /usr/lib64/libcob.so.4 (0x00007fb4513b7000)
libc.so.6 => /usr/lib64/libc.so.6 (0x00007fb4511ee000)
libm.so.6 => /usr/lib64/libm.so.6 (0x00007fb4510a8000)
libgmp.so.10 => /usr/lib64/libgmp.so.10 (0x00007fb45102b000)
libncursesw.so.6 => /usr/lib64/libncursesw.so.6 (0x00007fb450feb000)
libtinfo.so.6 => /usr/lib64/libtinfo.so.6 (0x00007fb450fbb000)
libdb-5.3.so => /usr/lib64/libdb-5.3.so (0x00007fb450dee000)
libdl.so.2 => /usr/lib64/libdl.so.2 (0x00007fb450de7000)
/lib64/ld-linux-x86-64.so.2 (0x00007fb451547000)
libpthread.so.0 => /usr/lib64/libpthread.so.0 (0x00007fb450dc5000)

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Simon Sobisch - 2020-05-18

@limburgher can you please recheck with current 3.x branch if this is still an issue for you? Thank you.

Note: if you want to run ldd against cobc/.libs/cobc you'll always have to either invoke the pre-inst-env script or setup your dynamic loader to prefix libcob/.libs.

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Gwyn Ciesla - 2020-05-18

Ok, so on the previous nightly, if I use pre-inst-env, it shows linkage to the .libs version. If not, it shows linkage to the installed system version. On trunk, if I use pre-inst-env, it shows linkage to the .libs version, if not, it gives, among other things, libcob.so.5 => not found, as expected. The rpm build fails due to missing translation, as they don't appear to be building.

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Gwyn Ciesla - 2020-06-24

Do we know when 3.1 might come out?

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
- Simon Sobisch - 2020-07-02
  
  @limburgher 3.1-rc1 is out now (NEWS entry says 3.1 final, depending on feedback to be expected within the next 3 monhs).
  Is there anything open from this ticket for you (3.1rc1 + trunk) or can we close it?
  
  Note: if you experience any issues with translations you likely need to add gettext in your environment, but in both the 3.1-rc1 tarball and in the CI-created tarball for trunk there should be no need for this.
  If you stumble over any issue related to this and want to go on you could go with the configure option --disable-nls to work around this issue.
  
  I suggest to update the 3.1 fedora package to the rc-1 from https://alpha.gnu.org/gnu/gnucobol/, possibly with signature and sha256 check if that is something Fedora does during build. Using the rc1 will also remove the need to use the autogen script and therefore the build-dependecies bison flex help2man texinfo.
  
  I also highly suggest to compare your spec file with https://sourceforge.net/p/open-cobol/code/HEAD/tree/branches/gnucobol-3.x/gnucobol.spec - as some entries, for example URL and license, are currently wrong in the fedora spec.
  You may want to add a libxml2 dependency. While it is an optional one (if not explicit specified configure will check if it is available and add it in this case) and relative big, it is needed to support GENERATE XML which is otherwise non-functional.
  
  Personal question: can you try to make it available in EPEL-7, too?
  
  Last edit: Simon Sobisch 2020-07-02
  
  If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Gwyn Ciesla - 2020-07-02

I'll fix the spec, and add the sig verification and build deps. I notice that the soname has gone from 5 back to 4, is this intended to be stable now?

I can try EPEL7, yes.

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
- Simon Sobisch - 2020-07-02
  
  There's nothing going back here :-)
  Explanation: soname is at 5 in trunk (because 4.x is incompatible to previous versions; so "fun" to tackle when targetting this in rpms some later date), GC3.1 is compatible back to GC 2.2 and therefore sticks with the soname 4.
  
  If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Gwyn Ciesla - 2020-07-02

Ahh, ok. SO I just need to wark people to recompile.

For EL-7 it looks like test 696 is failing. Any idea why?

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
- Simon Sobisch - 2020-07-02
  
  Ahh, ok. SO I just need to wark people to recompile.
  
  I guess you mean "warn" - this is something that would be needed when upgrading from 3.x to 4.x (and also the other way around or when downgrading from 3.x to 2.2). It is not needed when going from 2.2 to 3.x. Because of the different soname one could theoretically install both, even into the same directory with using an exec-suffix; but 4.0 is too far away to think about this now.
  I'Ve just rechecked the first rpm that I've seen - it is named "gnucobol-3.1-3.el8.src.rpm" and contains (according to configure.ac) "4.0-early-dev" - at least this one (= everyone with the soname 5) has to be considered broken because: it says "a" (3.1) and contains "b" (4.0) - and in any case it contains an unstable version with no guarantee at all that generated modules will work after the next change (without recompilation).
  So yet: please "revert" that one if possible and try to provide a 3.1 based on the 3.1rc1 quick, telling people that they may need to recompile (actually they are likely to get a nice message like "version mismatch, module version 4, libcob version 3").
  
  Which EL-7 is broken - GC3.1-rc1 or GC4.0-early-dev? In the case of 3.1 it should be the test "DELETE FILE, INDEXED", that is not a test that is known to fail "under special circumstances" - please provide the file tests/testsuite.log if possible as this would allow us to recheck.
  
  If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
  - Gwyn Ciesla - 2020-07-02
    
    I do. :)
    
    I only need to warn the few people using the previous trunk snapshot, that's all. I'm releasing 3.1-rc1 for rawhide, fc32 and epel8 now. And yes, that's the one. Here's the log.
    
    testsuite.log
    
    If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
    - Simon Sobisch - 2020-07-02
      
      Thank you for the log - does this only happen on EL7 but not on EL-8? Can you send the file tests/testuite.log for comparision?
      
      In any case: that's only a minor issue (internally there's a wrong error code returned, but still an error code, so this is mainly confusing).
      
      If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
      - Gwyn Ciesla - 2020-07-02
        
        Correct, 8 is fine, here's the log.
        
        Also, gnucobol doesn't currently build on ppc64le.
        
        testsuite.log
        
        If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

configure script does not handle multiple blacklisted CFLAGS

A free COBOL compiler

Group

Searches

Help

#627 configure script does not handle multiple blacklisted CFLAGS

Related

Discussion

Related