Re: [CLN-list] cln compile error
In "/cln/src/float/transcendental/cl_LF_zeta_int.cc" there are two occurrences of "_N" and two of "_s". I renamed both variables as you recommended and the error disappeared. I haven't encountered this problem again but I'm not done yet. I have another compile issue, this time due to an apparent problem with undefined variables. I've attached two screen shots (with signifcant snipping between them) that may be useful. I've also attached the config.log. Thanks again for any help! Regards, Chris Bouchard ---- Original message ----
Date: Fri, 12 Oct 2007 16:44:57 +0200 From: "Richard B. Kreckel" <kreckel@ginac.de> Subject: Re: [CLN-list] cln compile error To: CLN discussion list <cln-list@ginac.de>
cbouchrd@uiuc.edu wrote:
I'm getting a compile error similar to that reported in the Nov '07 thread of same subject name. I'm too ignorant, however, to apply the fix provided in that thread to my problem (if, in fact, it is applicable).
I've included the config.log and a screen shot of the compile error.
At first blush I thought the problem was in line 115 of "cl_LF_zeta_int.cc". After scanning the config.log and reading the old thread, though, it seems possible that the problem is within "confdefs.h"
My operating system is Windows XP with CYGWIN.
Thanks for any help. I look forward to using xloops/GiNaC/CLN in the near future!
You are using a prerelease of CLN 1.2.0 from CVS and your compiler is defining either _s or _N as some number. Can you, please, rename that variable and try again?
I wish to fix such things before the release of CLN 1.2.0, but I suspect there are a number of other places where you'll have to apply the same fix. Please, find them and send them to me (or this list).
Thanks in advance -richy. -- Richard B. Kreckel <http://www.ginac.de/~kreckel/> _______________________________________________ CLN-list mailing list CLN-list@ginac.de https://www.cebix.net/mailman/listinfo/cln-list
Hi! cbouchrd@uiuc.edu wrote:
In "/cln/src/float/transcendental/cl_LF_zeta_int.cc" there are two occurrences of "_N" and two of "_s". I renamed both variables as you recommended and the error disappeared. I haven't encountered this problem again but I'm not done yet.
Okay, I've renamed them in CVS. Thank you.
I have another compile issue, this time due to an apparent problem with undefined variables.
I've attached two screen shots (with signifcant snipping between them) that may be useful. I've also attached the config.log.
Hopefully some Cygwin expert can have a look into this. On Linux, I geat a weak symbol "W" for cln::zerop(cln::cl_I const&) inside cl_I_ring.o. I don't quite comprehend what generates it, but anyway: what's with weak symbols on Cygwin? -richy. -- Richard B. Kreckel <http://www.ginac.de/~kreckel/>
Hi! On Fri, Oct 12, 2007 at 11:51:32PM +0200, Richard B. Kreckel wrote:
Hopefully some Cygwin expert can have a look into this. On Linux, I geat a weak symbol "W" for cln::zerop(cln::cl_I const&) inside cl_I_ring.o. I don't quite comprehend what generates it,
I think it is MAYBE_INLINE hack.
but anyway: what's with weak symbols on Cygwin?
COFF/PE (win32 binary format) does not support weak symbols. Best regards, Alexei -- All science is either physics or stamp collecting.
Alexei Sheplyakov wrote:
Hopefully some Cygwin expert can have a look into this. On Linux, I geat a weak symbol "W" for cln::zerop(cln::cl_I const&) inside cl_I_ring.o. I don't quite comprehend what generates it,
I think it is MAYBE_INLINE hack.
Why do you think that it is related to MAYBE_INLINE? cln/src/integer/elem/cl_I_zerop.c does not use MAYBE_INLINE. Why do you think MAYBE_INLINE is a hack? I don't see how it would violate ISO C++. Chris Bouchard's error message was this: ../src/.libs/libcln.a(cl_I_ring.o):cl_I_ring.cc:(.text$_ZN5zeropERKNS_4cl_IE[cln::zerop(cln::cl_I const&)]+0x0): multiple definition of `cln::zerop(cln::cl_I const&)' ../src/.libs/libcln.a(cl_I_zerop.o):cl_I_zerop.cc:(.text+0x0): first defined here So let's look at the two compilation units cl_I_zerop.cc and cl_I_ring.cc. cl_I_zerop.cc contains this code: ------------------------------------------------------------------------- extern bool zerop (const cl_I& x); // from <cln/integer.h> bool zerop (const cl_I& x) { return inline_zerop(x); } ------------------------------------------------------------------------- That it leads to an exported symbol cln::zerop in the object file, is fine. cl_I_ring.cc contains this 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, ... }; ------------------------------------------------------------------------- You can see that it leads to a symbol cln::zerop in the object file, in the segment .text$_ZN5zeropERKNS_4cl_IE[cln::zerop(cln::cl_I const&)] To me, that indicates that g++ has tried to avoid a collision with the cln::zerop symbol in the .text segment, but somehow the linker does not treat the segments that way. C++ inline functions are certainly tricky to compile, given that ISO C++ section 7.1.2.(4) says: "An inline function with external linkage shall have the same address in all translation units." And here the problem is that we take its address... But I must admit that CLN is outside the ISO C++ specification because it also says in 7.1.2.(4): "If a function with external linkage is declared inline in one transla- tion unit, it shall be declared inline in all translation units in which it appears" and CLN declares cln::zerop only inline in those compilation units that include "cl_I.h" (except cl_I_zerop.cc), not in all other compilation units. But this is necessary for good inlining... Bruno
Hello!
I think it is MAYBE_INLINE hack.
Why do you think that it is related to MAYBE_INLINE?
See this message: http://www.ginac.de/pipermail/ginac-list/2003-November/000434.html
Why do you think MAYBE_INLINE is a hack? I don't see how it would violate ISO C++.
As you've pointed out yourself,
But I must admit that CLN is outside the ISO C++ specification because it also says in 7.1.2.(4): "If a function with external linkage is declared inline in one transla- tion unit, it shall be declared inline in all translation units in which it appears" and CLN declares cln::zerop only inline in those compilation units that include "cl_I.h" (except cl_I_zerop.cc), not in all other compilation units.
Chris Bouchard's error message was this:
../src/.libs/libcln.a(cl_I_ring.o):cl_I_ring.cc:(.text$_ZN5zeropERKNS_4cl_IE[cln::zerop(cln::cl_I const&)]+0x0): multiple definition of `cln::zerop(cln::cl_I const&)'
../src/.libs/libcln.a(cl_I_zerop.o):cl_I_zerop.cc:(.text+0x0): first defined here
So let's look at the two compilation units cl_I_zerop.cc and cl_I_ring.cc.
cl_I_zerop.cc contains this code: ------------------------------------------------------------------------- extern bool zerop (const cl_I& x); // from <cln/integer.h> bool zerop (const cl_I& x) { return inline_zerop(x); } -------------------------------------------------------------------------
That it leads to an exported symbol cln::zerop in the object file, is fine.
So far so good.
cl_I_ring.cc contains this 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, ... }; -------------------------------------------------------------------------
You can see that it leads to a symbol cln::zerop in the object file, in the segment .text$_ZN5zeropERKNS_4cl_IE[cln::zerop(cln::cl_I const&)]
To me, that indicates that g++ has tried to avoid a collision with the cln::zerop symbol in the .text segment, but somehow the linker does not treat the segments that way.
Not exactly. g++ decided that inline zerop(cln::cl_I const&) is too complicated to be inlined and emitted it out-of-line. Such functions are placed into the .text<mangled name of the function> section (on ELF it would be placed into .text section as a weak symbol). We end up with duplicate symbols: one in the .text section (extern bool zerop), and another one in the .text<mangled name of the function> section. Linker reports the error, and that is it. This sutiation is impossible with standard-compliant code, since the function will be either inline in all translation units (there will be one symbol in the .text<mangled name of the function> section), or non-inline (there will be one symbol in the .text section). On ELF platform the linker discards weak symbol[s] with no error, so MAYBE_INLINE hack [kind of] works there.
and CLN declares cln::zerop only inline in those compilation units that include "cl_I.h" (except cl_I_zerop.cc), not in all other compilation units. But this is necessary for good inlining...
I doubt it. MAYBE_INLINE or not, but the compiler emits this function out-of-line anyway -- on Linux there is a weak symbol for cln::zerop(cln::cl_I const&) inside cl_I_ring.o, and there is .text$_ZN5zeropERKNS_4cl_IE section on woe32. Best regards, Alexei. -- All science is either physics or stamp collecting.
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
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. Best regards, Alexei -- All science is either physics or stamp collecting.
participants (4)
-
Alexei Sheplyakov
-
Bruno Haible
-
cbouchrd＠uiuc.edu
-
Richard B. Kreckel