Closed w-bruns closed 2 years ago
I now have dll for Flint, antic and arb, but nor MPFR, and I am still stuck.
Now I have all prerequisites as dll files, including MPFR, thanks to the prompt help bei the MSYS team.
Nevertheless I get stuck with the following linker errors. make distclean etc. hasn't helped, and the errors appear with --disable-static as well with --disable-shared:
C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/11.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: D:/Dropbox/NormalizMSYS/normaliz-3.9.2/local/lib/libflint.a(memory_manager.o): in function `flint_malloc':
D:\Dropbox\NormalizMSYS\normaliz-3.9.2\nmz_opt_lib\Flint_source\flint-2.8.0/memory_manager.c:90: multiple definition of `flint_malloc'; ../src/.libs/libeantic.dll.a(d000379.o):(.text+0x0): first defined here
C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/11.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: D:/Dropbox/NormalizMSYS/normaliz-3.9.2/local/lib/libflint.a(memory_manager.o): in function `flint_free':
D:\Dropbox\NormalizMSYS\normaliz-3.9.2\nmz_opt_lib\Flint_source\flint-2.8.0/memory_manager.c:162: multiple definition of `flint_free'; ../src/.libs/libeantic.dll.a(d000376.o):(.text+0x0): first defined here
C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/11.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: D:/Dropbox/NormalizMSYS/normaliz-3.9.2/local/lib/libflint.a(fmpz_fmpz.o): in function `_fmpz_new_mpz':
D:\Dropbox\NormalizMSYS\normaliz-3.9.2\nmz_opt_lib\Flint_source\flint-2.8.0\fmpz/fmpz.c:67: multiple definition of `_fmpz_new_mpz'; ../src/.libs/libeantic.dll.a(d000121.o):(.text+0x0): first defined here
C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/11.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: D:/Dropbox/NormalizMSYS/normaliz-3.9.2/local/lib/libflint.a(fmpz_fmpz.o): in function `_fmpz_clear_mpz':
D:\Dropbox\NormalizMSYS\normaliz-3.9.2\nmz_opt_lib\Flint_source\flint-2.8.0\fmpz/fmpz.c:127: multiple definition of `_fmpz_clear_mpz'; ../src/.libs/libeantic.dll.a(d000053.o):(.text+0x0): first defined here
C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/11.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: warning: cannot find entry symbol nable-new-dtags; defaulting to 00000003beb81000
collect2.exe: error: ld returned 1 exit status
I have managed to build e-antic --disable-shared under MSYS MinGW44 with g++. Therefore the error messages in my last mail are obsolete.
However I could not link the lib files to Normaliz, neither via autotools, nor via Makefile.classic. The latter works for all other optional libraries.
What do you mean exactly when you say "I could not link"? (I am confused because you are saying that the error messages above are obsolete.)
I have built e-antic 1.1.0 statically. (I will report on a shared buildf later.) I am using Makefile.classic in order to get a static normaliz.exe. This is no problem under Linux, and under MSYS2 I can link all optional packages except e-antic. When I try e-antic, the linker does not find the e-antic symbols and ends with the error messages
C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/11.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: libnormaliz/libnormaliz.a(collection.o):collection.cpp:(.text$_ZN11libnormaliz14ConeCollectionIN6eantic15renf_elem_classEE7flattenEv[_ZN11libnormaliz14ConeCollectionIN6eantic15renf_elem_classEE7flattenEv]+0x170): undefined reference to `__imp__ZN6eantic15renf_elem_classC1EOS0_'
C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/11.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: libnormaliz/libnormaliz.a(collection.o):collection.cpp:(.text$_ZN11libnormaliz14ConeCollectionIN6eantic15renf_elem_classEE7flattenEv[_ZN11libnormaliz14ConeCollectionIN6eantic15renf_elem_classEE7flattenEv]+0x17e): undefined reference to `__imp__ZN6eantic15renf_elem_classD1Ev'
C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/11.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: libnormaliz/libnormaliz.a(collection.o):collection.cpp:(.text$_ZN11libnormaliz14ConeCollectionIN6eantic15renf_elem_classEE7flattenEv[_ZN11libnormaliz14ConeCollectionIN6eantic15renf_elem_classEE7flattenEv]+0x312): undefined reference to `__imp__ZN6eantic15renf_elem_classD1Ev'
Inspection of libeantic.a
and libeanticxx.a
shows that the symbols exist there, but without the prefix imp. The only explanation why this prefix is inserted in the Normaliz compilation is that it is suggested by the e-antic header files. Indeed if I set
#define LIBEANTIC_LIBRARY_IMPORT
#define LIBEANTIC_LIBRARY_EXPORT
#define LIBEANTIC_LIBRARY_HIDDEN
inlocal.h
, then the prefix disappears, but another problem comes up:
C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/11.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: libnormaliz/libnormaliz.a(collection.o):collection.cpp:(.text$_ZN11libnormaliz14ConeCollectionIN6eantic15renf_elem_classEE7flattenEv[_ZN11libnormaliz14ConeCollectionIN6eantic15renf_elem_classEE7flattenEv]+0x175): undefined reference to `eantic::renf_elem_class::~renf_elem_class()'
C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/11.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: libnormaliz/libnormaliz.a(collection.o):collection.cpp:(.text$_ZN11libnormaliz14ConeCollectionIN6eantic15renf_elem_classEE7flattenEv[_ZN11libnormaliz14ConeCollectionIN6eantic15renf_elem_classEE7flattenEv]+0x2f5): undefined reference to `eantic::renf_elem_class::~renf_elem_class()'
I have built e-antic 1.1.0 statically. (I will report on a shared buildf later.) I am using Makefile.classic in order to get a static normaliz.exe. This is no problem under Linux, and under MSYS2 I can link all optional packages except e-antic. When I try e-antic, the linker does not find the e-antic symbols and ends with the error messages
C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/11.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: libnormaliz/libnormaliz.a(collection.o):collection.cpp:(.text$_ZN11libnormaliz14ConeCollectionIN6eantic15renf_elem_classEE7flattenEv[_ZN11libnormaliz14ConeCollectionIN6eantic15renf_elem_classEE7flattenEv]+0x170): undefined reference to `__imp__ZN6eantic15renf_elem_classC1EOS0_' C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/11.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: libnormaliz/libnormaliz.a(collection.o):collection.cpp:(.text$_ZN11libnormaliz14ConeCollectionIN6eantic15renf_elem_classEE7flattenEv[_ZN11libnormaliz14ConeCollectionIN6eantic15renf_elem_classEE7flattenEv]+0x17e): undefined reference to `__imp__ZN6eantic15renf_elem_classD1Ev' C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/11.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: libnormaliz/libnormaliz.a(collection.o):collection.cpp:(.text$_ZN11libnormaliz14ConeCollectionIN6eantic15renf_elem_classEE7flattenEv[_ZN11libnormaliz14ConeCollectionIN6eantic15renf_elem_classEE7flattenEv]+0x312): undefined reference to `__imp__ZN6eantic15renf_elem_classD1Ev'
Inspection of
libeantic.a
andlibeanticxx.a
shows that the symbols exist there, but without the prefix imp. The only explanation why this prefix is inserted in the Normaliz compilation is that it is suggested by the e-antic header files.
We don't set such a prefix namespace __imp__
anywhere unless this is some compiler magic on Windows.
Indeed if I set
#define LIBEANTIC_LIBRARY_IMPORT #define LIBEANTIC_LIBRARY_EXPORT #define LIBEANTIC_LIBRARY_HIDDEN
in
local.h
, then the prefix disappears, but another problem comes up:C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/11.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: libnormaliz/libnormaliz.a(collection.o):collection.cpp:(.text$_ZN11libnormaliz14ConeCollectionIN6eantic15renf_elem_classEE7flattenEv[_ZN11libnormaliz14ConeCollectionIN6eantic15renf_elem_classEE7flattenEv]+0x175): undefined reference to `eantic::renf_elem_class::~renf_elem_class()' C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/11.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: libnormaliz/libnormaliz.a(collection.o):collection.cpp:(.text$_ZN11libnormaliz14ConeCollectionIN6eantic15renf_elem_classEE7flattenEv[_ZN11libnormaliz14ConeCollectionIN6eantic15renf_elem_classEE7flattenEv]+0x2f5): undefined reference to `eantic::renf_elem_class::~renf_elem_class()'
I can't see anything special about ~renf_elem_class
except that this destructor is marked noexcept
.
Nicht gerade hilfreich.
Winfried
Am 25.02.2022 um 20:32 schrieb Julian Rüth @.***>:
I have built e-antic 1.1.0 statically. (I will report on a shared buildf later.) I am using Makefile.classic in order to get a static normaliz.exe. This is no problem under Linux, and under MSYS2 I can link all optional packages except e-antic. When I try e-antic, the linker does not find the e-antic symbols and ends with the error messages
C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/11.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: libnormaliz/libnormaliz.a(collection.o):collection.cpp:(.text$_ZN11libnormaliz14ConeCollectionIN6eantic15renf_elem_classEE7flattenEv[_ZN11libnormaliz14ConeCollectionIN6eantic15renf_elem_classEE7flattenEv]+0x170): undefined reference to
__imp__ZN6eantic15renf_elem_classC1EOS0_' C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/11.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: libnormaliz/libnormaliz.a(collection.o):collection.cpp:(.text$_ZN11libnormaliz14ConeCollectionIN6eantic15renf_elem_classEE7flattenEv[_ZN11libnormaliz14ConeCollectionIN6eantic15renf_elem_classEE7flattenEv]+0x17e): undefined reference to
impZN6eantic15renf_elem_classD1Ev' C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/11.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: libnormaliz/libnormaliz.a(collection.o):collection.cpp:(.text$_ZN11libnormaliz14ConeCollectionIN6eantic15renf_elem_classEE7flattenEv[_ZN11libnormaliz14ConeCollectionIN6eantic15renf_elem_classEE7flattenEv]+0x312): undefined reference to `impZN6eantic15renf_elem_classD1Ev' Inspection of libeantic.a and libeanticxx.a shows that the symbols exist there, but without the prefix imp. The only explanation why this prefix is inserted in the Normaliz compilation is that it is suggested by the e-antic header files.We don't set such a prefix namespace imp anywhere unless this is some compiler magic on Windows.
Indeed if I set
define LIBEANTIC_LIBRARY_IMPORT
define LIBEANTIC_LIBRARY_EXPORT
define LIBEANTIC_LIBRARY_HIDDEN
in local.h, then the prefix disappears, but another problem comes up:
C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/11.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: libnormaliz/libnormaliz.a(collection.o):collection.cpp:(.text$_ZN11libnormaliz14ConeCollectionIN6eantic15renf_elem_classEE7flattenEv[_ZN11libnormaliz14ConeCollectionIN6eantic15renf_elem_classEE7flattenEv]+0x175): undefined reference to
eantic::renf_elem_class::~renf_elem_class()' C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/11.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: libnormaliz/libnormaliz.a(collection.o):collection.cpp:(.text$_ZN11libnormaliz14ConeCollectionIN6eantic15renf_elem_classEE7flattenEv[_ZN11libnormaliz14ConeCollectionIN6eantic15renf_elem_classEE7flattenEv]+0x2f5): undefined reference to
eantic::renf_elem_class::~renf_elem_class()' I can't see anything special about ~renf_elem_class except that this destructor is marked noexcept.— Reply to this email directly, view it on GitHub, or unsubscribe. Triage notifications on the go with GitHub Mobile for iOS or Android. You are receiving this because you authored the thread.
Sorry, I am not sure what you are trying to say.
(I am essentially completely clueless about Windows so I am sorry if I cannot be of too much help here.)
I am sorry. My last comment was a mistake in sending the mail.
The problem has to do with the compiler magic.
I am not sure whom one could ask. I will go on experimenting.
As said, I can build e-antic 1.1.0 under MSYS2 MinGW64 with g++ --disabled-sahred
.
I cannot build it --disable-static
. Then I see some error messages again:
C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/11.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: D:/local/lib/libflint.a(memory_manager.o): in function `flint_malloc':
D:\Dropbox\NormalizMSYS\normaliz-3.9.2\nmz_opt_lib\Flint_source\flint-2.8.0/memory_manager.c:90: multiple definition of `flint_malloc'; ../src/.libs/libeantic.dll.a(d000379.o):(.text+0x0): first defined here
C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/11.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: D:/local/lib/libflint.a(memory_manager.o): in function `flint_free':
D:\Dropbox\NormalizMSYS\normaliz-3.9.2\nmz_opt_lib\Flint_source\flint-2.8.0/memory_manager.c:162: multiple definition of `flint_free'; ../src/.libs/libeantic.dll.a(d000376.o):(.text+0x0): first defined here
C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/11.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: D:/local/lib/libflint.a(fmpz_fmpz.o): in function `_fmpz_new_mpz':
D:\Dropbox\NormalizMSYS\normaliz-3.9.2\nmz_opt_lib\Flint_source\flint-2.8.0\fmpz/fmpz.c:67: multiple definition of `_fmpz_new_mpz'; ../src/.libs/libeantic.dll.a(d000121.o):(.text+0x0): first defined here
C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/11.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: D:/local/lib/libflint.a(fmpz_fmpz.o): in function `_fmpz_clear_mpz':
D:\Dropbox\NormalizMSYS\normaliz-3.9.2\nmz_opt_lib\Flint_source\flint-2.8.0\fmpz/fmpz.c:127: multiple definition of `_fmpz_clear_mpz'; ../src/.libs/libeantic.dll.a(d000053.o):(.text+0x0): first defined here
collect2.exe: error: ld returned 1 exit status
make[1]: *** [Makefile:449: libeanticxx.la] Error 1
make[1]: Leaving directory '/d/FlintTest/e-antic-1.1.0/libeantic/srcxx'
make: *** [Makefile:430: all-recursive] Error 1
Finally success, most likely because it is Sunday.
The problem with the shared build reported above, suggested to try again with the Flint distribution of MSYS instead of my own, and a shared build of e-antic was possible. Whether it yielded the dynamic libraries intended, is unclear to me. I got files with the suffixes a
and dll.a
The file libeanticxx.a
does not use the suffix __imp__
, but libeantic.dll.a
does.
A static build of Normaliz then succeeded, and as the test suite shows, it is completely successful.
Great it worked out. Is there something we could should in e-antic to make this easier now?
I think, e-aqntic is well-behaved also under MSYSY2. I can treat it with the same scripts as under Linux or MacOS. Not true for other packages for which the authors' configurations do not provide shared builds. Under Linux and MacOS the autotools shared builds simply take the static libraries and import them. Not true under MSYS.
Nevertheless I can get a static build of Normaliz with all packages. This was the most important goal. I am working on a shared build.
Nice. @w-bruns so this issue can be closed then?
I am trying to build Normaliz under MSYS MinGW64 with all optional packages.
The first problem I encountered was the missing eer.h. I tried to install the rat tail of header files it needs, and gave up. Commenting its inclusion in refine_embedding was the easier solution, and it is my impression that it is actually superfluous there.
The real problem
I have only static versions of GMP, MPFR, Flint. antic and arb. The package manager of MinGW installs GMP only statically.
However, as the message above and several others following it show I really need shared libraries for e-antic. Could this be changed?