Opened 7 years ago

Last modified 7 years ago

#13325 closed defect

eclib does not build on Cygwin — at Version 15

Reported by: jpflori Owned by: tbd
Priority: major Milestone: sage-5.6
Component: porting: Cygwin Keywords: eclib spkg cygwin
Cc: kcrisman, dimpase, cremona, vbraun Merged in:
Authors: Jean-Pierre Flori Reviewers:
Report Upstream: Fixed upstream, in a later stable release. Work issues: wait for official update of the build system; fix pari problem (new spkg?)
Branch: Commit:
Dependencies: Stopgaps:

Description (last modified by dimpase)

There are two problems with the current spkg on Cygwin:

  • -lgmp should come after -lntl and -lpari, I fixed this in configure.ac
  • the executables names in tests/Makefile.am should finish with $(EXEEXT), fixed there as well.

Then I reran autogen.sh from upstream, deleted autom4te.cache and repackaged, versioned, commented everything.

Patched spkg available at http://perso.telecom-paristech.fr/~flori/sage/eclib-20120428.p0.spkg

To make this work on CYGWIN, presently you will need, for instance, to manually create in SAGELOCAL/lib/ a symbolic link named libpari.dll.a to libpari-gmp.dll.

Nevertheles, I think it would be better to repack a new release of eclib including such changes to prevent the inclusion of the patches and the hg history which make the spkg size explode.

Change History (16)

Changed 7 years ago by jpflori

Spkg diff, for review only.

comment:1 Changed 7 years ago by jpflori

  • Authors set to Jean-Pierre Flori
  • Cc kcrisman dimpase cremona added
  • Description modified (diff)
  • Status changed from new to needs_info

Updated spkg available at: http://perso.telecom-paristech.fr/~flori/sage/eclib-20120428.p0.spkg

Although I'd prefer package an updated upstream version including such fixes. John, could you update eclib ggoglecode repo? If you're convinced the changes I propose are useful... At least, they seem harmless on Linux and let the spkg build on Cygwin.

comment:2 Changed 7 years ago by jpflori

Hmmm, the 13325.patch file I uploaded is not the one I planned to. That's a random previous version of the patch, please wait for me to upload a file named spkg.diff.

comment:3 Changed 7 years ago by jpflori

The current spkg does not build yet. I get multiple definitions of _roots while building d2.exe: in d2 and in libpari.a(rootpol.o) apparently.

comment:4 Changed 7 years ago by cremona

It is certainly preferable for the eclib source (build system) to be changed so we do not need to patch it. I have some other suggested changes to the build system from a debian developer -- it would be very helpful if someone else could look at those too. I am travelling at the moment and will not be able to think about this properly for the next 2+ weeks.

comment:5 Changed 7 years ago by jpflori

That's because a static version of libpari is used. Using the shared one (by copying libpari.dll to libpari.dll.a) solves the problem.

comment:6 Changed 7 years ago by jpflori

  • Report Upstream changed from Not yet reported upstream; Will do shortly. to Workaround found; Bug reported upstream.
  • Work issues set to wait for official update of the build system; fix pari problem (new spkg?)

comment:7 Changed 7 years ago by jpflori

Another question to John: For the PARI stuff, would you consider renaming the function to something else? That would allow to link the programs statically (not that I really care, I think it's more important to let Cygwin find the shared lib of PARI before the static one anyway).

comment:8 Changed 7 years ago by jpflori

Apparently pari creates a libpari.dll.a file but I guess Sage does not correctly copy it. I also see strange if test "libpari-gmp.dll" != "libpari-gmp.dll"

Have to have a look to pari spkg install script...

comment:9 Changed 7 years ago by dimpase

The spkg does not work for me; I get

/bin/sh ../libtool --tag=CXX    --mode=link g++ -I/home/Dima/sage-5.2.rc1/local/include  -I/home/Dima/sage-5.2.rc1/local/include  -I/home/Dima/sage-5.2.rc1/local/include -DNTL_ALL -DUSE_PARI_FACTORING -DMETHOD=2 -DNEW_OP_ORDER -g -O3  -ljc -L../libsrc -L/home/Dima/sage-5.2.rc1/local/lib -lntl -lgmp -L/home/Dima/sage-5.2.rc1/local/lib -lpari -lgmp   -o d2.exe d2.o
libtool: link: g++ -I/home/Dima/sage-5.2.rc1/local/include -I/home/Dima/sage-5.2.rc1/local/include -I/home/Dima/sage-5.2.rc1/local/include -DNTL_ALL -DUSE_PARI_FACTORING -DMETHOD=2 -DNEW_OP_ORDER -g -O3 -o .libs/d2.exe d2.o  /home/Dima/sage-5.2.rc1/spkg/build/eclib-20120428.p0/src/libsrc/.libs/libjc.a /usr/lib/gcc/i686-pc-cygwin/4.5.3/libstdc++.dll.a -L../libsrc -L/home/Dima/sage-5.2.rc1/local/lib -lntl -lpari /home/Dima/sage-5.2.rc1/local/lib/libgmp.dll.a -L/usr/lib/gcc/i686-pc-cygwin/4.5.3 -L/home/Dima/sage-5.2.rc1/local/lib
/home/Dima/sage-5.2.rc1/local/lib/libpari.a(rootpol.o): In function `roots':
/home/Dima/sage-5.2.rc1/spkg/build/pari-2.5.1.p3/src/Ocygwin-i686/../src/basemath/rootpol.c:2057: multiple definition of `_roots'
d2.o:/home/Dima/sage-5.2.rc1/spkg/build/eclib-20120428.p0/src/tests/d2.cc:149: first defined here
collect2: ld returned 1 exit status
Makefile:679: recipe for target `d2.exe' failed
make[3]: *** [d2.exe] Error 1

By the way, did I have to install a different PARI spkg, too?

comment:10 follow-up: Changed 7 years ago by jpflori

Yes you have to somehow tweak PARI to let d2 build.

The quickest hack is to copy libpari.dll to libpari.dll.a.

However I'd prefer to copy the proper import file dll.a ggenerated by PARI when it's build.

And I'd prefer such a fix to be included in PARI itself rather than in a Sage spkg. I'll contact the PARI team today. Hopefully this could make it into 2.5.2 for which Jeroen is currently preparing a spkg as well.

comment:11 in reply to: ↑ 10 Changed 7 years ago by dimpase

Replying to jpflori:

Yes you have to somehow tweak PARI to let d2 build.

The quickest hack is to copy libpari.dll to libpari.dll.a.

there are 2 files named libpari.dll in SAGELOCAL. One in bin/, and another in lib/... And both of them aren't archive files, but "real" dlls. Tried your hack for the one in bin/, it didn't help.

And, by the way, how would it help the problem of multiple definition of `_roots' This looks like overlinking rather than underlinking to me.

comment:12 Changed 7 years ago by jpflori

I never said they were archive files...

I said that when linking the linker finds libpari.a BEFORE libpari.dll. But as there is already a function named _roots in an object file included in libpari.a it fails. That's the problem.

From now on, lets suppose we live in the lib directory and forget about the bin one which is not of interest for our purposes.

So a hack consists in making sure that the linker find libpari.dll BEFORE libpari.a. To do that, you can copy libpari.dll to libpari.dll.a. You could just rename it if you want to have some fun. You could also delete libpari.a or rename it to jdlksjlkdjls.

Or we could explicitely tell the linker to use libpari.dll, rather than just passing -lpari, but that needs more work. And anyway, PARI generates a file ending by .dll.a. AFAIK it's not a copy od libpari.dll, not a dll file, but some import file. The point is that the linker will find it BEFORE libpari.a if its present and by looking at it it will automatically use the libpari.dll file.

comment:13 Changed 7 years ago by jpflori

The point is that if you link to the dll rather than the archive file, ld won't complain, which is quite understandable because the _roots function from libpari is not needed nor called directly from eclib (and how could it be anyway as theres a function called so in eclib itself). The two namespaces/worlds are kept as separate as possible with ld just doing its magic when needed.

If you link archive files together, ar will try to put everything from pari and from eclib in one file, in particular it will have some trouble putting to functions with the same name in that one file. The two namespaces/worlds are colliding.

comment:14 Changed 7 years ago by cremona

I'm very sorry this is calling you trouble, as I hardly use libpari at all (in eclib), literally only for integer factorization. I am planning an upgrade to eclib which will make FLINT a dependency, in which case I might use FLINT for integer factorization instead. But not very soon.

comment:15 Changed 7 years ago by dimpase

  • Description modified (diff)
Note: See TracTickets for help on using tickets.