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.

(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.

I'd only tested 3.1.4 so far, i'll see how/if libfac/factory 3.1.5 works with M2

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.

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

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.

no need to worry about BuildConflicts  in rawhide, libfac/factory packages have been blocked/removed there already

(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...

(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.

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

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.