- CLN-list - ginac.de

Re: [CLN-list] Error building cln on M1 Mac
by Richard B. Kreckel 05 Mar '23

05 Mar '23

Hi Ron, (Sending this to mailing list, too.) On 3/5/23 01:44, Ron Garret wrote: > I tried to build cln on an M1 mac and got the following error: > > > depbase=`echo base/low/cl_low_div.lo | sed 's|[^/]*$|.deps/&|;s|\.lo$||'`;\ > /bin/sh ../libtool --tag=CXX --mode=compile g++ -std=gnu++11 > -DHAVE_CONFIG_H -I. -I../autoconf -I../include -I../src -I../include > -I../src -g -O2 -MT base/low/cl_low_div.lo -MD -MP -MF $depbase.Tpo -c > -o base/low/cl_low_div.lo base/low/cl_low_div.cc <http://cl_low_div.cc> &&\ > mv -f $depbase.Tpo $depbase.Plo > libtool: compile: g++ -std=gnu++11 -DHAVE_CONFIG_H -I. -I../autoconf > -I../include -I../src -I../include -I../src -g -O2 -MT > base/low/cl_low_div.lo -MD -MP -MF base/low/.deps/cl_low_div.Tpo -c > base/low/cl_low_div.cc <http://cl_low_div.cc> -fno-common -DPIC -o > base/low/.libs/cl_low_div.o > *base/low/cl_low_div.cc:13 <http://cl_low_div.cc:13>:8: **error: > **declaration of 'divu_16_rest' in global scope conflicts with > declaration with C language linkage* > uint16 divu_16_rest; > * ^* > *./base/cl_low.h:447:21: note: *declared with C language linkage here > extern "C" uint16 divu_16_rest; // -> Rest r > * ^* > *base/low/cl_low_div.cc:104 <http://cl_low_div.cc:104>:8: **error: > **declaration of 'divu_32_rest' in global scope conflicts with > declaration with C language linkage* > uint32 divu_32_rest; > * ^* > *./base/cl_low.h:597:21: note: *declared with C language linkage here > extern "C" uint32 divu_32_rest; // -> Rest r > * ^* > *base/low/cl_low_div.cc:210 <http://cl_low_div.cc:210>:8: **error: > **declaration of 'divu_64_rest' in global scope conflicts with > declaration with C language linkage* > uint64 divu_64_rest; > * ^* > *./base/cl_low.h:987:21: note: *declared with C language linkage here > extern "C" uint64 divu_64_rest; // -> Rest r > * ^* > 3 errors generated. > > > From a cursory inspection of the code I suspect this is a problem with > the preprocessor. Specifically, this code in cl_low.h > > #elifdefined(__arm__) && !defined(NO_ASM) > ... > #defineNEED_VAR_divu_16_rest > > looks highly suspect to me. I have not traced the problem back any > further than that. > > I tried configure CPPFLAGS=-DNO_ASM but that did not fix the problem, > which surprised me. It really looks like that should have worked. Did you use the CLN off from git? I'm asking because patch 6edafa136b which is not in the released 1.3.6. All my best, -richy. -- Richard B. Kreckel <https://in.terlu.de/~kreckel/>

3 4

Global static class instance
by Jan Rheinländer 17 Jan '23

17 Jan '23

Hi, in file include/cln/lfloat_class.h there is the line static cl_LF_globals_init_helper cl_LF_globals_init_helper_instance; Now as far as I can see this will instantiate an instance of class cl_LF_globals_init_helper in every object file that includes the header (https://stackoverflow.com/questions/11967502/okay-to-declare-static-global-… seems to support this). Wouldn't it be better to replace static by extern and define the instance in some .cc file? Regards, Jan Rheinländer

2 1

Re: [CLN-list] Getting a build error
by Bork, Alexander 27 Apr '21

27 Apr '21

Hello Richard, I was running into the same error during compilation on a MacBook Pro 13'' with the M1 chip using Apple clang version 12.0.0. Applying the patch does indeed help with the build error described earlier. However, there are problems with compilation of cl_asm_arm_.cc (see attached file). My assumption is that it’s due to the architecture of the Apple Silicon chip. Is this a known problem? Best regards, Alex Bork

2 3

Getting a build error
by Philip Huffman 14 Apr '21

14 Apr '21

Hello, When I try to build CLN-1.3.6 on my laptop this is the result, below. I did ./configure and make. Any assistance would be most welcome. Thank you, Phil Huffman libtool: compile: g++ -std=gnu++11 -DHAVE_CONFIG_H -I. -I../autoconf -I../include -I../src -I../include -I../src -g -O2 -MT base/low/cl_low_div.lo -MD -MP -MF base/low/.deps/cl_low_div.Tpo -c base/low/cl_low_div.cc -fno-common -DPIC -o base/low/.libs/cl_low_div.o base/low/cl_low_div.cc:13:8: error: declaration of 'divu_16_rest' in global scope conflicts with declaration with C language linkage uint16 divu_16_rest; ^ ./base/cl_low.h:447:21: note: declared with C language linkage here extern "C" uint16 divu_16_rest; // -> Rest r ^ base/low/cl_low_div.cc:104:8: error: declaration of 'divu_32_rest' in global scope conflicts with declaration with C language linkage uint32 divu_32_rest; ^ ./base/cl_low.h:597:21: note: declared with C language linkage here extern "C" uint32 divu_32_rest; // -> Rest r ^ base/low/cl_low_div.cc:210:8: error: declaration of 'divu_64_rest' in global scope conflicts with declaration with C language linkage uint64 divu_64_rest; ^ ./base/cl_low.h:987:21: note: declared with C language linkage here extern "C" uint64 divu_64_rest; // -> Rest r ^ Hardware Overview: Model Name: MacBook Air Model Identifier: MacBookAir10,1 Chip: Apple M1 Total Number of Cores: 8 (4 performance and 4 efficiency) Memory: 16 GB System Firmware Version: 6723.81.1 Serial Number (system): FVFFF4WCQ6LR Hardware UUID: F736846B-85AC-56FD-8081-0C79C98784E6 Provisioning UDID: 00008103-0011212236DA001E Activation Lock Status: Disabled System Software Overview: System Version: macOS 11.2.3 (20D91) Kernel Version: Darwin 20.3.0 Boot Volume: MacOS HD Boot Mode: Normal Computer Name: Phil’s MacBook Air User Name: Phil Huffman (prh) Secure Virtual Memory: Enabled System Integrity Protection: Enabled

2 1

CMakeLists.txt: Improving GiNaC/CLN (& ease of) integration?
by Xunie 01 Feb '21

01 Feb '21

Hiya, fine folks, 🤠 I'm trying to integrate GiNaC into my CMake-based project and I'm having some difficulty setting up the build. I was hoping you all could point me in the right direction. My questions: #1: How do you build GiNaC/CLN when working on your own projects? Am I the only one that uses CMake? #2: Could we make the CMake build system (and the integration of GiNaC) slightly easier to work with? >From a quick glance, CLN and GiNaC seem tightly interwoven. Am I correct in assuming there's a reason CLN doesn't have a CMakeLists.txt? Or is this mainly historical and can I safely start adding a CMake build? -------------------------- # My problem: My general git/CMake/C++ workflow consists of integrating every dependency I have as a git submodule under a common directory and point my CMakeLists.txt at each dependency. This has worked for me so far and seems like a reasonably clean way of dealing with dependencies on platforms where they might not be immediately available (i.e. MINGW). GiNaC's CMake build searches via a module ('cmake/modules/FindCLN.cmake') for a fully built CLN. This is simply not possible during the configuration step of my CMake build since at that point, CLN isn't even fully configured yet! Anyone have any idea how best to integrate GiNaC and CLN? How do YOU do it? Are there any big projects using GiNaC that I can look at? # How do we improve the CMake building experience of GiNaC & CLN? I'm open to suggestions, but I think merely adding a CMakeLists.txt to CLN should enable a better GiNaC build experience without having to modify GiNaC itself! Maybe modify that module just a tad bit but that oughta do it. If so desired, CLN's CMake build could just be made a proxy for the autotools build. I've also noticed that CLN's autogen.sh downloads some things via HTTPS from some git repo. This could immediately be looked at during this process. # The task (I estimate) there's 1202 source files in CLN as of writing so this is quite a task. I even bumped into source files specific to HP/PA ("Hewlett Packard Precision Architecture") which preceded Itanium which itself will be Discontinued in 2021! This makes CLN quite the antique! None the worse for wear I guess. ;-) Unless I'm mistaken, I doubt anyone still uses HP/PA in production in this day and age. (Ahh, they don't make 'em like they used to...) All in all: Should I or anyone else start working on CLN's CMakeLists.txt? Kind Regards & Happy Holidays, Xunie

4 12

Fw: Re: CMakeLists.txt: Improving GiNaC/CLN (& ease of) integration?
by Xunie 29 Dec '20

29 Dec '20

Hey Bruno, (Sorry you got this e-mail twice, I sent the first one to you directly instead of the mailing list!) On Monday, December 28, 2020 4:00 AM, Bruno Haible <bruno(a)clisp.org> wrote: > It seems that using a CMake 'ExternalProject' would allow you to use CLN's > configure-based build system from CMake [1]. No? About 2 years ago, I tried to integrate GiNaC into the same project I am trying to integrate it into right now. I failed and gave up. I've spent the last week wrestling with ExternalProject and looking at that exact same stackexchange answer trying to get it working this time. It was a highly frustrating experience. ExternalProject is and always will be a hack to incorporate non-CMake projects into CMake. > It is usually a waste of time to maintain two build systems (for CLN, in this > case) in parallel, when one is sufficient. Maybe, maybe not. GiNaC already has CMake support, why not CLN? Considering the (apparent) complexity and vintage of CLN, I certainly think maintaining a modern CMake build is not wasted effort. CMake has got to be the most popular C++ build system right now. I can't find any numbers on it, but seeing CMake-less projects is an exceptional rarity for me. But that's just my (n=1) experience. In the interest of making GiNaC/CLN easier to use, full CMake build support will improve user-experience. That's just my two cents, though. Personally I'm gonna build on Alexey's cmake branch, try to fix some CMP0002 warnings/errors I ran into and failing that, doing what he does and build CLN in-source inside GiNaC's source tree. It certainly beats wrangling autotools on my two platforms. I am trying my best to make my project testable and this includes sanity-testing my dependencies. God knows how much time and effort I'd have to invest trying to FULLY integrate CLN's autotools tests/exams into my CMake build. THAT is wasted effort. But hey, Alexey already did incorporate the tests it seems. :) If he's been using CMake to build CLN for a decade now, I have to ask: why isn't it incorporated already? All in all, a 2nd CMake build is not at all wasted effort if you ask me. Kind Regards, Xunie

1 0

Linking against cln fails when built with link-time-optimization
by Atri Bhattacharya 01 Nov '20

01 Nov '20

Hello, When the shared library for CLN is built with link-time optimization [1] (LTO) enabled, linking against libcln.so fails (for example GiNaC fails to build). Turning off link-time optimization fixes the linking issue, but I wonder if this is a bug in CLN that needs fixing or a compiler issue and if we can build and use LTO enabled CLN in the future. This issue was first reported [2] against openSUSE Tumbleweed which builds its packages with LTO flags by default; we are currently in the process of working around this by disabling the LTO flags specifically for CLN [3]. Thanks in advance for any suggestion as to how to fix TLO-enabled CLN builds or if indeed disabling LTO is the only way to go (at least for now). I maintain openSUSE's CLN and GiNaC packages. Cheers, [1] https://gcc.gnu.org/wiki/LinkTimeOptimization [2] https://bugzilla.opensuse.org/show_bug.cgi?id=1176710 [3] https://build.opensuse.org/request/show/835441 -- Atri Bhattacharya

4 9

CLN Library issue
by Oleg Popov 06 Apr '20

06 Apr '20

Dear GiNaC team, I have the following problem with cln library: When i try to run cln example or use it in my code, I run into the following errors: No member named 'memcpy' in namespace 'std'; did you mean 'wmemcpy'? Implicit instantiation of undefined template 'std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >' I have spent some time trying to find out what causes the problem, but did not succeed. I am using Mac os 10.14.6 and xcode 11.3.1. I tried using cln from brew distribution, as well as, compiling it from source (cln webpage). P.S. The errors arise at the moment I try to include cln path in the Xcode's "Header Search Path". Sincerely and thanks for your help, ---------------------------------------------------------------------------------------------------------------------- Oleg Popov Postdoctoral Research Associate <https://www.kaist.ac.kr/html/en/> <https://www.kaist.ac.kr/html/en/>Department of Physics, Korea Advanced Institute of Science and Technology (KAIST) 291 Daehak-ro, Yuseong-gu, Daejeon, 34141, Korea ----------------------------------------------------------------------------------------------------------------------

1 0

Re: [CLN-list] CLN-list Digest, Vol 91, Issue 2
by Po-Hsun Tseng 11 Feb '20

11 Feb '20

Thanks, it works for me! Po-Hsun Tseng (Rocky) On Mon, Feb 10, 2020 at 7:00 PM <cln-list-request(a)ginac.de> wrote: > Send CLN-list mailing list submissions to > cln-list(a)ginac.de > > To subscribe or unsubscribe via the World Wide Web, visit > https://www.ginac.de/mailman/listinfo/cln-list > or, via email, send a message with subject or body 'help' to > cln-list-request(a)ginac.de > > You can reach the person managing the list at > cln-list-owner(a)ginac.de > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of CLN-list digest..." > > > Today's Topics: > > 1. Re: adding two different precision number (Po-Hsun Tseng) > 2. print multi-precision floating number in scientific notation > (Po-Hsun Tseng) > 3. Re: print multi-precision floating number in scientific > notation (Richard B. Kreckel) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Sun, 9 Feb 2020 21:35:30 +0800 > From: Po-Hsun Tseng <zengbs(a)gmail.com> > To: Bruno Haible <bruno(a)clisp.org> > Cc: cln-list(a)ginac.de > Subject: Re: [CLN-list] adding two different precision number > Message-ID: > < > CA+HRcQvs_sxgtgZU7z4qR_1shrhTo2YWmNPfee2Lx9gDpdQkPg(a)mail.gmail.com> > Content-Type: text/plain; charset="utf-8" > > Dear Bruno, > > Thank you for your quick and detailed reply. > > Po-Hsun Tseng (Rocky) > > > On Sun, Feb 9, 2020 at 6:37 PM Bruno Haible <bruno(a)clisp.org> wrote: > > > Hi, > > > > > 1. Does CLN support performing two different precision number with > basic > > > overloading operators (+,-,*, and /)? > > > > Yes. > > > > > 2. If yes, how does CLN treat that? eg. zero padding on the > > precision-less > > > number before doing operation? > > > > It does zero-padding on the operand with the smaller precision, then the > > operation on the then equal-size operands, and finally rounding > > (round-to-even) > > to the smallest precision among the operands. > > > > Example (using decimal numbers for illustrative purposes): > > > > 3.14149265358979323 > > + 2.718282 > > --------------------- > > 3.14149265358979323 > > + 2.71828200000000000 > > --------------------- > > 5.85969465358979323 > > --------------------- > > 5.859695 > > > > Therefore, when some computation returns a result, usually a few decimal > > places at the end can be wrong, but CLN will never give you a 50-digit > > result when in fact the accurary is only 10 digits - UNLESS you use > > conversion functions [1] explicitly. > > > > Bruno > > > > [1] https://www.ginac.de/CLN/cln.html#Conversion-functions > > > > >

1 0

print multi-precision floating number in scientific notation
by Po-Hsun Tseng 10 Feb '20

10 Feb '20

Hi CLN developers, Sorry for frequently asking questions. I have checked manual and searched mailing list for full example, but nothing inside. Moreover, I only familiar with C... Question: How to use `print_float()` to print multi-precision floating number in scientific notation on terminal? below is the full code I have ever tried, but it always gives me compilation error. thanks. #include <cln/io.h> #include <cln/float.h> #include <cln/float_io.h> using namespace cln; int main( ) { int N = 10; cl_F x[N]; for (int i=0 ;i<N;i++) x[i] = "0.333333333333333333333333333333333333333333333333333333333333"; // cl_print_flags.float_readably = true; for (int i=0 ;i<N;i++) print_float(stdout, cl_print_flags.float_readably, x[i]); return 0 ; }

2 1