Upgrade/patch singular more to remove bad -rpath linker options

[mkoeppe]

The issue reported in ​https://groups.google.com/g/sage-release/c/fXpbYwaqt9o/m/929SlEXcCAAJ is likely caused by the upgrade to singular (#25993) from 4.1.1p2 to 4.2.0p1. Upstream singular introduced some rather unfortunate linker flags in 4.1.3 or earlier.

We fix it by a number of PRs to the singular build system. The new snapshot release is made from the current singular spielwiese HEAD, which has merged the PRs. There are a number of other change since the last snapshot release built in #31552, which seem to be bugfixes.

Previous tickets: #25993, #31552

[mkoeppe]

A first PR as preparation: ​https://github.com/Singular/Singular/pull/1072

[fbissey]

While /usr and /usr/local made it back in DEFAULT_CHECKING_PATH in flint-check.m4, if you use that variable that means they have not been found there previously by the bit that check standard paths - that I have added ​https://github.com/Singular/Singular/pull/981. So, I haven't asked for that re-addition to be removed. If you get to the bit checking DEFAULT_CHECKING_PATH they won't be found there anyway.

It would have been nice for gmp-check.m4 to follow that model. That would also prevent /usr/lib and /usr/local/lib to ever end up in a rpath unless you explicitly pass it as a path to be checked.

[mkoeppe]

Yes, I plan to make more improvements in this direction later. The first PR is designed to make no difference in behavior

[fbissey]

The replacement of all those gmp detections by a single one is certainly overdue. Code duplication is such a maintenance mess. It is an improvement on that front already.

[mkoeppe]

Replying to mkoeppe:

A first PR as preparation: ​https://github.com/Singular/Singular/pull/1072

It has been merged upstream.

[mkoeppe]

Next PR: ​https://github.com/Singular/Singular/pull/1074 (Replace -Wl,-rpath -Wl,... by -Wl,-rpath,...)

[mkoeppe]

And another one: ​https://github.com/Singular/Singular/pull/1075 (Define DEFAULT_CHECKING_PATH once only)

[mkoeppe]

And another one: ​https://github.com/Singular/Singular/pull/1076 (m4/*.m4: In the search loops, test for the presence of headers using the compiler)

[mkoeppe]

These three are all merged by upstream, so here's the next one:

​https://github.com/Singular/Singular/pull/1078 (m4/flint-check.m4: Refactor)

[mkoeppe]

Merged, so here is the last one:

​https://github.com/Singular/Singular/pull/1080

[fbissey]

I am not sure why you leave '/usr/local'? I would have thought anything in there would be found when testing DEFAULTS.

[mkoeppe]

Not true on macOS when using CC=CC=gcc -isysroot ....

[fbissey]

OK, fair enough.

[mkoeppe]

All of the above PRs have been merged by upstream.

I have made another PR, ​https://github.com/Singular/Singular/pull/1081, just with minor fixes to the Singular docbuild so the process of making a release is simpler: autoreconf -fi && ./configure --disable-pyobject-module --enable-doc-build && make && make dist

New release for sage at ​https://github.com/mkoeppe/Singular/releases/tag/singular-4.2.0p1%2B2021-04-06%2Bsage

---

New commits:

​ea8652b

build/pkgs/singular: Use 4.2.0p1+2021-04-06+sage

[fbissey]

Thanks for taking the time to go through that mess that likely represented years of accumulated hacks. I am satisfied that it should work out of the box. It needs to go to the bots.

[git]

Branch pushed to git repo; I updated commit sha1 and set ticket back to needs_review. New commits:

​1c00520

build/pkgs/singular/spkg-install.in: Use --with-libparse - just in case we use a tarball without built documentation

[fbissey]

That's a new option to me. I now see what objects it builds. I am unfamiliar with the documentation building, is that a component to help build it?

[mkoeppe]

Yes, to my understanding it is needed by the docbuild to extract test cases from the library code.

[fbissey]

I am not against it but that may have been more appropriate for future tickets. On the other hand that would mean more bumping of singular, not like we need any more of that.

I am happy to put it back to positive review, that commit doesn't add any requirements which was my first knee jerk reaction to it.

[mkoeppe]

I added it here so that the upstream CI integration tests with Sage run properly: ​https://github.com/Singular/Singular/actions/runs/723960919

[git]

Branch pushed to git repo; I updated commit sha1 and set ticket back to needs_review. New commits:

​4769678

Merge tag '9.3.rc2' into t/31592/upgrade_patch_singular_more_to_remove_bad__rpath_linker_options

[mkoeppe]

now on top of 9.3.rc2

[mkoeppe]

Just saw this error on cygwin-standard, a cygwin-specific makefile bug related to libparse.

g++ -std=gnu++11 -O2 -g -march=native -pipe -fno-common -g0 -O3 -Wno-unused-function -Wno-trigraphs -Wno-unused-parameter -Wunknown-pragmas -Wno-unused-variable -fomit-frame-pointer -fwrapv -fvisibility=default -finline-functions -fno-exceptions -fno-threadsafe-statics -fno-enforce-eh-specs -fconserve-space -funroll-loops -fno-delete-null-pointer-checks -fno-rtti  -L/opt/sage-ee023d7e18dfacf53b08fd0cf862661c48fe39c5/lib -Wl,-rpath,/opt/sage-ee023d7e18dfacf53b08fd0cf862661c48fe39c5/lib  -pipe -fno-common -g0 -O3 -Wno-unused-function -Wno-trigraphs -Wno-unused-parameter -Wunknown-pragmas -Wno-unused-variable -fomit-frame-pointer -fwrapv -fvisibility=default -finline-functions -fno-exceptions -fconserve-space -funroll-loops -fno-delete-null-pointer-checks  -Wl,-Bdynamic  libparse.cc   -o libparse
libparse.cc:31:10: fatal error: factory/globaldefs.h: No such file or directory
   31 | #include "factory/globaldefs.h"
      |          ^~~~~~~~~~~~~~~~~~~~~~
compilation terminated.

​https://github.com/mkoeppe/sage/runs/2309214320 (this run is on top of other tickets, in particular #28890, but let's play safe and remove 1c00520)

[git]

Branch pushed to git repo; I updated commit sha1. New commits:

​2571513

Revert "build/pkgs/singular/spkg-install.in: Use --with-libparse - just in case we use a tarball without built documentation"

[mkoeppe]

Setting it back to positive review - back to the version reviewed in comment 19.

[mkoeppe]

Follow-up in #31642, where 1c00520 is coming back