Bug 842407 - Singular-3.1.4+
Singular-3.1.4+
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: Singular (Show other bugs)
rawhide
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Paulo Andrade
Fedora Extras Quality Assurance
: FutureFeature
Depends On: 846497
Blocks: 837122 846352
  Show dependency treegraph
 
Reported: 2012-07-23 15:13 EDT by Rex Dieter
Modified: 2013-01-26 10:59 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2012-08-08 22:09:07 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Rex Dieter 2012-07-23 15:13:49 EDT
So, in trying to get Macaulay2 built for rawhide, I've concluded:
Macaulay2-1.4 builds ok only with factory/libfac 3.1.1
Macaulay2-1.5 builds ok only with factory/libfac 3.1.4

3.1.3 doesn't work as-is without more patching. :(

So, any chance for Singular-3.1.4 soon?

Else, I suppose we could consider reviving standalone libfac/factory packaging and update only those to 3.1.4
Comment 1 Paulo Andrade 2012-07-24 07:45:49 EDT
Using a different Singular version than what is used by sagemath will
make it almost impossible to get sagemath packaged.
I think it could be required a special case to link statically, with
minimal code duplication; probably somewhat like the initial Singular
package I proposed, but changed because making it work with system
libfac/factory of different (at that time older) version would not
work.
Comment 2 Paulo Andrade 2012-08-03 11:05:30 EDT
(In reply to comment #0)
> So, in trying to get Macaulay2 built for rawhide, I've concluded:
> Macaulay2-1.4 builds ok only with factory/libfac 3.1.1
> Macaulay2-1.5 builds ok only with factory/libfac 3.1.4
> 
> 3.1.3 doesn't work as-is without more patching. :(
> 
> So, any chance for Singular-3.1.4 soon?

  What about 3.1.5? :-)

http://trac.sagemath.org/sage_trac/ticket/13237

> Else, I suppose we could consider reviving standalone libfac/factory
> packaging and update only those to 3.1.4

  I will try to update my sagemath build to recently released 5.2
instead of a beta, and work on getting singular 3.1.5 patches on
int shortly.
Comment 3 Rex Dieter 2012-08-03 11:14:42 EDT
I'd only tested 3.1.4 so far, i'll see how/if libfac/factory 3.1.5 works with M2
Comment 4 Paulo Andrade 2012-08-04 19:16:22 EDT
Please test with a build of

http://fedorapeople.org/~pcpa/Singular-3.1.5-1.fc18.src.rpm

Note that I added a BuildConflicts for factory-devel and libfac-devel
otherwise it would include the system non matching versions and
fail to build (luckily instead of runtime weirdness)

I am now finishing my tests of adapting my sagemath-5.2beta0
rpm to plain sagemath-5.2, and from now on also using singular 3.1.5
by adapting/using patches from sagemath trac 13237.
Comment 5 Rex Dieter 2012-08-07 10:28:34 EDT
OK, I think I got M2-1.5 working with some minor patching here and there.

please do update rawhide to 3.1.5 asap
Comment 6 Paulo Andrade 2012-08-07 13:57:57 EDT
I will try to submit an update shortly, only plan to do some tests
to avoid the need of the BuildConflicts with factory-devel and
libfac-devel. Hopefully adding local headers to CPPFLAGS in related
Makefile.in files should be enough.
Comment 7 Rex Dieter 2012-08-07 18:25:32 EDT
no need to worry about BuildConflicts  in rawhide, libfac/factory packages have been blocked/removed there already
Comment 8 Paulo Andrade 2012-08-07 21:04:41 EDT
(In reply to comment #7)
> no need to worry about BuildConflicts  in rawhide, libfac/factory packages
> have been blocked/removed there already

Ok. Not sure how to properly correct it anyway. I edited every header
of the current factory-devel and libfac-devel from Singular 3.1.3, to
#error if included, but they were not included; the problem is in the
link stage, precisely due to:

[...] -rdynamic -L/usr/kernel -L../kernel -lkernel -L/usr/lib64 -L/usr/lib64 -Wl,-z,relro  -L/usr/local/lib  -ldl -L../kernel -L../factory -L../libfac -L../omalloc -lkernel -lm -lsingfac -lsingcf -lntl -lgmp -lreadline -lncurses -lm  -lnsl -lbsd  -lomalloc -lpthread  ../kernel/mmalloc.o 

(the -L/usr/kernel is in error but no problem) it ends up linking
to system "-lsingfac -lsingcf"

I think it should be fine to just remove the BuildConflits from
Singular.spec, as it is mean't to be built in a chroot anyway,
otherwise, need to "expand" several variables in the Makefile
to put "-L../libfac -lsingfac -L../factory -lsingcf" before
-L/usr/lib64 (or better yet, omit the later)

Will wait for #846497 as I can only hack ntl-devel in my local
build...
Comment 9 Paulo Andrade 2012-08-08 22:09:07 EDT
(In reply to comment #7)
> no need to worry about BuildConflicts  in rawhide, libfac/factory packages
> have been blocked/removed there already

I did some extra work and the correction was actually trivial,
by adding a "s|-L%{_libdir}||g" in Makefile would cause the
linker to not prefer the system wide libsingfac and libsingcf
when all -L paths were specified before the -l names.

Singular-3.1.5 has now been built for rawhide.
Comment 10 Fedora Update System 2013-01-16 10:55:52 EST
Singular-3.1.5-3.fc18 has been submitted as an update for Fedora 18.
https://admin.fedoraproject.org/updates/Singular-3.1.5-3.fc18
Comment 11 Fedora Update System 2013-01-26 10:59:06 EST
Singular-3.1.5-3.fc18 has been pushed to the Fedora 18 stable repository.  If problems still persist, please make note of it in this bug report.

Note You need to log in before you can comment on or make changes to this bug.