eclib does not build on Cygwin

[jpflori]

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.
• the -no-undefined flag should also be passed to libtool so that a shared library gets built on Cygwin and for sage.libs.mwrank to be functional.

All of this is fixed in the 2012-08-30 upstream release.

Apply:

1. attachment: trac_13325.patch
2. the spkg http://www.infres.enst.fr/~flori/sage/eclib-20120830.spkg

Depends on #13333

Upstream: Fixed upstream, in a later stable release.

CC: @kcrisman @dimpase @JohnCremona @vbraun

Component: porting: Cygwin

Keywords: eclib spkg cygwin

Author: Jean-Pierre Flori

Reviewer: John Cremona

Merged: sage-5.6.beta0

Issue created by migration from https://trac.sagemath.org/ticket/13325

[jpflori]

Attachment: 13325.patch.gz

Spkg diff, for review only.

[jpflori]

Author: Jean-Pierre Flori

[jpflori]

comment:1

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.

[jpflori]

Description changed:

--- 
+++ 
@@ -1 +1,10 @@
-Because of some mess between AM_CPP_FLAGS and AM_CXX_FLAGS, the tests target of Makefile fails when linking.
+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
+
+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.

[jpflori]

comment:2

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.

[jpflori]

comment:3

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.

[JohnCremona]

comment:4

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.

[jpflori]

comment:5

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.

[jpflori]

Work Issues: wait for official update of the build system; fix pari problem (new spkg?)

[jpflori]

Changed upstream from Not yet reported upstream; Will do shortly. to Workaround found; Bug reported upstream.

[jpflori]

comment:7

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

[jpflori]

comment:8

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

[dimpase]

comment:9

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?

[jpflori]

comment:10

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.

[dimpase]

comment:11

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.

[jpflori]

comment:12

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.

[jpflori]

comment:13

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.

[JohnCremona]

comment:14

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.

[dimpase]

Description changed:

--- 
+++ 
@@ -7,4 +7,6 @@
 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.

[jpflori]

Description changed:

--- 
+++ 
@@ -7,6 +7,7 @@
 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`.
+Nevertheless, 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.

-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.
+
+Moreover, 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` or use the PARI spkg from #13333.

[jpflori]

comment:17

The -no-undefined flag should also be passed to libtool so that a shared library gets built on Cygwin.

[jpflori]

Description changed:

--- 
+++ 
@@ -1,6 +1,7 @@
 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.
+The -no-undefined flag should also be passed to libtool so that a shared library gets built on Cygwin. 

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

[jpflori]

Spkg diff, for review only. Not committed in spkg.

[jpflori]

comment:18

Attachment: eclib.patch.gz

Updated spkg at the same url adding the -no-undefined flag. This has the nice consequence that eclib now builds a shared library and that sage.libs.mwrank is functional.

[jpflori]

Description changed:

--- 
+++ 
@@ -1,7 +1,7 @@
 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.
-The -no-undefined flag should also be passed to libtool so that a shared library gets built on Cygwin. 
+The -no-undefined flag should also be passed to libtool so that a shared library gets built on Cygwin and for sage.libs.mwrank to be functional.

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

[jpflori]

comment:19

As a temporary solution I've uploaded an spkg reautoconfed using #13357, so that there is no spkg size explosion. Not retested on Cygwin yet, but it should be as functional as before. Nothing is definitely committed or tagged yet, I'll do it after review.

[jpflori]

Changed work issues from wait for official update of the build system; fix pari problem (new spkg?) to none

[jpflori]

Dependencies: #13333

[JohnCremona]

comment:21

I'm going to need some help & advice here. Since the last release of eclib with autotools there are three sets of changes: (1) the ones by you people for Sage (triggered by cygwin issues); (2) some changes sent to me by email by Bernhard Link of debian; (3) changes made by me to make FLINT 3 a prerequisite, since by using FLINT in a few key places I obtain a vast speedup of some programs (nto ones used by Sage currently). Clearly I can absorb the first two sets easily, but I am not sure about the last one, since until Sage starts to use FLINT 3 I would have to get autoconf to determine whether or not to use FLINT by setting some compiler switches or similar. And I am very capable of getting very confused in merging 3 sets of changes to anything...

[jpflori]

comment:22

FLINT 3? Is that a super secret project :) If you mean FLINT 2.3, I personally think that it should quickly go into Sage, see #12173, which seems (almost?) functional to me.

I still have some issues with Cygwin there, so the spkg I posted is not vanilla #12173, but rather vanilla plus a quite large rewrite of the build system. I'm aware that's a bad idea, because it won't get into FLINT 2.3, but I won't have the time to produce a bunch of small patches in order for only the Cygwin part to get included.

As Cygwin is not required to be supported, we should surely just ship a vanilla FLINT 2.3 when it gets released and wait for Bill to integrate my changes (if he feels like) in a 2.4 or subsequent release.

[JohnCremona]

comment:23

Replying to @jpflori:

FLINT 3? Is that a super secret project :) If you mean FLINT 2.3, I personally think that it should quickly go into Sage, see #12173, which seems (almost?) functional to me.

Yes, I did mean 2.3! I guess FLINT3 is waiting for Bill to write a new language / compiler...

[jpflori]

comment:24

Im finally testing the last spkg, and it seems I deleted something in it. I'll fix it tomorrow.

[jpflori]

Attachment: spkg.diff.gz

Spkg diff, for review only. Committed in spkg.

[jpflori]

comment:25

Spkg is now fixed. The error was caused by the fact that files of the build system were patched and so their timestamp updated. Then autotool magic wanted to regenerate some of them, which would fail because some pieces needed to do that are missing (this would also be true with the previous spkg). So touching some files in the right order after patching solves the issue.

[jpflori]

Description changed:

--- 
+++ 
@@ -1,14 +1,12 @@
 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.
-The -no-undefined flag should also be passed to libtool so that a shared library gets built on Cygwin and for sage.libs.mwrank to be functional.
+* the -no-undefined flag should also be passed to libtool so that a shared library gets built on Cygwin and for sage.libs.mwrank to be functional.

-Then I reran autogen.sh from upstream, deleted autom4te.cache and repackaged, versioned, commented everything.
+Then I reran automake and autoconf (not aclocal, nor libtoolize, which modified a lot of things) from upstream, repackaged, versioned, commented everything.
+As the build system is patched before configuration, some files have to be touched in order to avoid automatic regeneration (which would fail due to the lack off some files, this is already the case in the upstream distribution).

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

-Nevertheless, 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.
-
-
 Moreover, 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` or use the PARI spkg from #13333.

[JohnCremona]

comment:26

I am right now working on making the changes you have been making to the upstream distribution. I will report here when that is done. At the same time I am making the changes suggested by Bernhard Link of debian (but nothing to do with FLINT at this point).

[JohnCremona]

comment:27

I want to make sure that understand the changes that you made so I can make them "upstream" and hence avoid any patching. I realise that this will mean a new version of the spkg: when I am done the eclib version will be bumped up to 2012-08-21 (assuming that I finish today) so the next spkg can have a new name instead of a patch level.

From the Changelog in SPKG.txt:

+ * #13325: let eclib build on Cygwin.
+ * Put -lgmp after -lntl and -lpari in configure.ac.
+ * Add $(EXEEXT) to the targets in tests/Makefile.am.
+ * Add '-no-undefined' flag to libjc.la LDFLAGS so that a shared library
+   is built on Cygwin.
+ * automake and autoconf were run to regenerate the configure script and
+   Makefiles.

1. will no longer be necessary. These flags are now set i nthe various Makefile.am using the macros LIBADD and LDADD, and I did put gmp last.

2. $(EXEEXT). I assume that this is set on cygwin (to ".exe" or something) but not otherwise, so (apart from cluttering up the Makefiles) there will be no effect on other systems? You say that this is done in src/tests, but should it also be done in src/progs? The latter builds some binaries which are actually installed (e.g. mwrank).

3. '-no-indefined' OK I can add that too. By the way, the library name is now libec and not libjc.

4. OK, so I'm a bit uncertain as to which auto* files to actually include. When I change configure.ac or any Makefile.am files I run autoreconf. I never touch or look at configure or the actual Makefiles.

So I will now deal with points 2 and 3 and hand back to you, if that is OK.

[jpflori]

comment:28

Replying to @JohnCremona:

1. will no longer be necessary. These flags are now set i nthe various Makefile.am using the macros LIBADD and LDADD, and I did put gmp last.

Great.

2. $(EXEEXT). I assume that this is set on cygwin (to ".exe" or something) but not otherwise, so (apart from cluttering up the Makefiles) there will be no effect on other systems? You say that this is done in src/tests, but should it also be done in src/progs? The latter builds some binaries which are actually installed (e.g. mwrank).

Yes, this is only "really" needed on Cygwin. On most systems, let's say Linuxes, $(EXEEXT) will be void, so putting it or not won't have any visible effect.

If I remember correctly, the executables in the progs directory already magically included the $(EXEEXT) (or at least the file produced ended up in .exe). There must be some difference between the two Makefile.am you used. I can have a look if you want.

3. '-no-indefined' OK I can add that too. By the way, the library name is now libec and not libjc.

Great (jsut beware of the typo here :)

4. OK, so I'm a bit uncertain as to which auto* files to actually include. When I change configure.ac or any Makefile.am files I run autoreconf. I never touch or look at configure or the actual Makefiles.

I'm not really sure of what should be included in a distribution tarball, I've begun fighting with autotools just a few weeks ago. What was really painfull here is that it seemed that having a more recent configure than aclocal.m4 was detected by configure itself and let it try to regenerate aclocal.m4 (which failed because of the lack of a proper m4 directory with I don't really know what macros inside). The same was true for Makefile.in.

Don't know what the behavior if you actually omit the configure.ac and Makefile.am files.

So I will now deal with points 2 and 3 and hand back to you, if that is OK.

[jpflori]

comment:29

Replying to @jpflori:

Replying to @JohnCremona:

1. will no longer be necessary. These flags are now set i nthe various Makefile.am using the macros LIBADD and LDADD, and I did put gmp last.

Great.

2. $(EXEEXT). I assume that this is set on cygwin (to ".exe" or something) but not otherwise, so (apart from cluttering up the Makefiles) there will be no effect on other systems? You say that this is done in src/tests, but should it also be done in src/progs? The latter builds some binaries which are actually installed (e.g. mwrank).

Yes, this is only "really" needed on Cygwin. On most systems, let's say Linuxes, $(EXEEXT) will be void, so putting it or not won't have any visible effect.

If I remember correctly, the executables in the progs directory already magically included the $(EXEEXT) (or at least the file produced ended up in .exe). There must be some difference between the two Makefile.am you used. I can have a look if you want.

Disregard this last comment, I did not get what you said. The splitting of progs and tests is posterior to the current spkg Sage ships.

But yes, I guess you could add $(EXEEXT) everywhere I guess, I must admit I don't really really remember if this is really necessary on Cygwin... but on Windows executables usually finish with .exe, so it can not hurt. Plus, on recent Cygwin versions, there seems to be some automatic translation from prog to prog.exe (I guess this also made my changes actually work when setting SAGE_CHECK, because I did not add $(EXEEXT) at each invocation of the programs as I just realized).

3. '-no-indefined' OK I can add that too. By the way, the library name is now libec and not libjc.

Great (jsut beware of the typo here :)

4. OK, so I'm a bit uncertain as to which auto* files to actually include. When I change configure.ac or any Makefile.am files I run autoreconf. I never touch or look at configure or the actual Makefiles.

I'm not really sure of what should be included in a distribution tarball, I've begun fighting with autotools just a few weeks ago. What was really painfull here is that it seemed that having a more recent configure than aclocal.m4 was detected by configure itself and let it try to regenerate aclocal.m4 (which failed because of the lack of a proper m4 directory with I don't really know what macros inside). The same was true for Makefile.in.

Don't know what the behavior if you actually omit the configure.ac and Makefile.am files.

So I will now deal with points 2 and 3 and hand back to you, if that is OK.

[JohnCremona]

comment:30

Regarding $(EXEEXT): I have been readong up on this. Yes, the suffix gets automagically added to bin_PROGRAMS targets but apparently not to everything. See http://www.gnu.org/software/automake/manual/automake.html#index-Executable-extension-620 . I assumed that you (or someone) only added this manually where it was needed, but forgot that the clib version now in Sage was as old as it is.

See #13021 for example (not my ticket and I was not CC'ed onto it).

[JohnCremona]

comment:31

On rereading the automake manual reference (previous post) I would assume that the suffix was provided for you unless you find that in some cases it is not, rather than adding the suffix manually everywhere.

[jpflori]

comment:32

I think I now remember what the problem was:

• autotools indeed does its magic with $(EXEEXT),
• but you directly put smattest (and others) in a target, so make tries to build it generically and doesn't use the magic smattest$(EXEEXT) target and its autotools CFLAGS (and the one you provided to it) so it fails
• except on Linux (and others) where the autotools magic defines a target for smattest and we get lucky...

Here is an excerpt of what failed on Cygwin:

libtool: link: g++ -I/home/jp/sage-5.2/local/include -I/home/jp/sage-5.2/local/include -I/home/jp/sage-5.2/local/include -DNTL_ALL -DUSE_PARI_FACTORING -DMETHOD=2 -DNEW_OP_ORDER -g -O3 -o .libs/mwrank.exe mwrank.o  /home/jp/sage-5.2/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/jp/sage-5.2/local/lib -lntl -lpari /home/jp/sage-5.2/local/lib/libgmp.dll.a -L/usr/lib/gcc/i686-pc-cygwin/4.5.3 -L/home/jp/sage-5.2/local/lib
g++ -g -O3     smattest.cc   -o smattest
smattest.cc:30:25: erreur fatale: eclib/arith.h : No such file or directory
compilation terminée.
<builtin>: recipe for target `smattest' failed

After adding $(EXEEXT) I got

/bin/sh ../libtool --tag=CXX    --mode=link g++ -I/home/jp/sage-5.2/local/include  -I/home/jp/sage-5.2/local/include  -I/home/jp/sage-5.2/local/include -DNTL_ALL -DUSE_PARI_FACTORING -DMETHOD=2 -DNEW_OP_ORDER -g -O3  -ljc -L../libsrc -L/home/jp/sage-5.2/local/lib -lntl -lgmp -L/home/jp/sage-5.2/local/lib -lpari -lgmp   -o mwrank.exe mwrank.o  
libtool: link: g++ -I/home/jp/sage-5.2/local/include -I/home/jp/sage-5.2/local/include -I/home/jp/sage-5.2/local/include -DNTL_ALL -DUSE_PARI_FACTORING -DMETHOD=2 -DNEW_OP_ORDER -g -O3 -o .libs/mwrank.exe mwrank.o  /home/jp/sage-5.2/spkg/build/eclib-20120428.p0/src/libsrc/.libs/libjc.dll.a -L../libsrc -L/home/jp/sage-5.2/local/lib /home/jp/sage-5.2/local/lib/libntl.dll.a /usr/lib/gcc/i686-pc-cygwin/4.5.3/libstdc++.dll.a -lpari /home/jp/sage-5.2/local/lib/libgmp.dll.a -L/home/jp/sage-5.2/local/lib -L/usr/lib/gcc/i686-pc-cygwin/4.5.3
g++ -DPACKAGE_NAME=\"eclib\" -DPACKAGE_TARNAME=\"eclib\" -DPACKAGE_VERSION=\"2012-04-25\" -DPACKAGE_STRING=\"eclib\ 2012-04-25\" -DPACKAGE_BUGREPORT=\"john.cremona@gmail.com\" -DPACKAGE_URL=\"\" -DPACKAGE=\"eclib\" -DVERSION=\"2012-04-25\" -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_DLFCN_H=1 -DLT_OBJDIR=\".libs/\" -DHAVE_ALLOCA_H=1 -DHAVE_ALLOCA=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_UNISTD_H=1 -DHAVE__BOOL=1 -DHAVE_STDBOOL_H=1 -Drestrict=__restrict -DHAVE_FLOOR=1 -DHAVE_MEMMOVE=1 -DHAVE_MEMSET=1 -DHAVE_POW=1 -DHAVE_SQRT=1 -DHAVE_STRCHR=1 -I.   -I../libsrc -I/home/jp/sage-5.2/local/include -I/home/jp/sage-5.2/local/include  -I/home/jp/sage-5.2/local/include  -I/home/jp/sage-5.2/local/include  -I/home/jp/sage-5.2/local/include -DNTL_ALL -DUSE_PARI_FACTORING -DMETHOD=2 -DNEW_OP_ORDER -g -O3  -MT smattest.o -MD -MP -MF .deps/smattest.Tpo -c -o smattest.o smattest.cc
mv -f .deps/smattest.Tpo .deps/smattest.Po
/bin/sh ../libtool --tag=CXX    --mode=link g++ -I/home/jp/sage-5.2/local/include  -I/home/jp/sage-5.2/local/include  -I/home/jp/sage-5.2/local/include -DNTL_ALL -DUSE_PARI_FACTORING -DMETHOD=2 -DNEW_OP_ORDER -g -O3  -ljc -L../libsrc -L/home/jp/sage-5.2/local/lib -lntl -lgmp -L/home/jp/sage-5.2/local/lib -lpari -lgmp   -o smattest.exe smattest.o  
libtool: link: g++ -I/home/jp/sage-5.2/local/include -I/home/jp/sage-5.2/local/include -I/home/jp/sage-5.2/local/include -DNTL_ALL -DUSE_PARI_FACTORING -DMETHOD=2 -DNEW_OP_ORDER -g -O3 -o .libs/smattest.exe smattest.o  /home/jp/sage-5.2/spkg/build/eclib-20120428.p0/src/libsrc/.libs/libjc.dll.a -L../libsrc -L/home/jp/sage-5.2/local/lib /home/jp/sage-5.2/local/lib/libntl.dll.a /usr/lib/gcc/i686-pc-cygwin/4.5.3/libstdc++.dll.a -lpari /home/jp/sage-5.2/local/lib/libgmp.dll.a -L/home/jp/sage-5.2/local/lib -L/usr/lib/gcc/i686-pc-cygwin/4.5.3

[JohnCremona]

comment:33

OK -- so I just removed all mention of EXEEXT from the Makefile.am's and redid autoreconf, and in the resulting Makefiles all the targets have got their $(EXEEXT) suffices on correctly. So provided that these Makefiles are in the distribution it should not be necessary to do anything special. Could you try that? There's a new eclib tarball at http://homepages.warwick.ac.uk/staff/J.E.Cremona/ftp/

[jpflori]

comment:34

I fear the problem is still present. Have a look at tests/Makefile.in; there at line 571, the PROCS_TESTS variable is defined as a list of executable names which do not include $(EXEEXT). So when make will try to build the procs_tests target, it try to build targets without the $(EXEEXT), which on Cygwin are not defined by the autotools magic because EXEXT is not empty. On Linux, as EXEEXT is empty, there will be no problem.

I'll confirm that Cygwin fails in a few tens of minutes.

[jpflori]

comment:35

(In the other places there is indeed $(EXEEXT) thanks to the autotools magic, the problem is precisely that target in proc_tests do not refer to this autogenerated targets!)

[jpflori]

comment:36

Mmmm, in fact the build failed while linking libec. Not really sure what the point of LIBADD is, but it does not get used for libec. Although there is a libec_la_LIBADD variable which is empty in Makefile.in. Maybe that's what you meant to add? http://sources.redhat.com/autobook/autobook/autobook_92.html suggests it is at least (no plain LIBADD variable mentionned there, only the LIBADD macro).

[jpflori]

comment:37

Apparently a general AM_LIBADD was suggested: http://osdir.com/ml/automake-gnu/2012-06/msg00019.html

[jpflori]

comment:38

Or you could use LIBS?

[JohnCremona]

comment:39

I'll ask the debian guy about LIBADD etc, since that was one of his.

[jpflori]

comment:40

By the way, using libec_la_LIBADD let libec compile and in fact I got no problems with smattest (and the following programs)!