Re: [CLN-list] CLN vs Cygwin [Was: cln compile error]
Hi, Sorry for the delay... ---- Original message ----
Date: Sat, 13 Oct 2007 19:17:13 +0400 From: Alexei Sheplyakov <varg@theor.jinr.ru> Subject: [CLN-list] CLN vs Cygwin [Was: cln compile error] To: CLN discussion list <cln-list@ginac.de>
Hello!
On Fri, Oct 12, 2007 at 12:10:56PM -0500, cbouchrd@uiuc.edu wrote:
I have another compile issue, this time due to an apparent problem with undefined variables.
Do you have the same problem when compiling static library only? i.e. make clean &&./configure --disable-shared && make
Yes. I've now compiled both ways and the on screen indications are identical.
I've attached two screen shots (with signifcant snipping between them) that may be useful.
Unfortunately the text is almost unreadable (should I upgrade my glasses?). Could you please send the compilation log instead? E.g.
make 2>&1 | gzip -9 > compile.log.gz
and post the compile.log.gz file.
The file is attached.
Best regards, Alexei
-- All science is either physics or stamp collecting.
________________ signature.asc (1k bytes) ________________ _______________________________________________ CLN-list mailing list CLN-list@ginac.de https://www.cebix.net/mailman/listinfo/cln-list
Thanks, Chris
Hello! On Tue, Oct 16, 2007 at 08:05:43PM -0500, cbouchrd@uiuc.edu wrote:
Do you have the same problem when compiling static library only? i.e. make clean &&./configure --disable-shared && make
Yes. I've now compiled both ways and the on screen indications are identical.
Could you please try this patch: [PATCH] zerop(cl_I& const): be more ISO C++ friendly. CLN's MAYBE_INLINE violates ISO C++, which demands (in 7.1.2.4) "If a function with external linkage is declared inline in one translation unit, it shall be declared inline in all translation units in which it appears; no diagnostic is required." This results in link errors on non-ELF platforms (MinGW, Cygwin, Darwin). In particular, cl_I_ring.cc contains the following code: extern bool zerop (const cl_I& x); // from <cln/integer.h> inline bool zerop (const cl_I& x) // from cl_I.h { return x.word == cl_combine(cl_FN_tag,0); } static cl_number_ring_ops<cl_I> I_ops = { cl_I_p, equal, zerop, // ... Since the address of zerop is taken here, the compiler is forced to emit zerop function out-of-line. This results in duplicate symbols (which is an error). --- src/integer/ring/cl_I_ring.cc | 5 ++++- 1 files changed, 4 insertions(+), 1 deletions(-) diff --git a/src/integer/ring/cl_I_ring.cc b/src/integer/ring/cl_I_ring.cc index 416738a..fd96c12 100644 --- a/src/integer/ring/cl_I_ring.cc +++ b/src/integer/ring/cl_I_ring.cc @@ -13,7 +13,9 @@ CL_PROVIDE(cl_I_ring) #include "cln/integer.h" #include "cln/integer_io.h" +#define zerop inline_zerop #include "cl_I.h" +#undef zerop namespace cln { @@ -34,10 +36,11 @@ static const _cl_ring_element I_zero (cl_heap_ring* R) return _cl_ring_element(R, (cl_I)0); } +static bool I_zerop (cl_heap_ring* R, const _cl_ring_element& x) __attribute__((flatten)); static bool I_zerop (cl_heap_ring* R, const _cl_ring_element& x) { unused R; - return zerop(The(cl_I)(x)); + return inline_zerop(The(cl_I)(x)); } static const _cl_ring_element I_plus (cl_heap_ring* R, const _cl_ring_element& x, const _cl_ring_element& y) -- 1.5.3.2 Best regards, Alexei -- All science is either physics or stamp collecting.
participants (2)
-
Alexei Sheplyakov
-
cbouchrd＠uiuc.edu