From fausap at libero.it Fri Apr 2 00:41:25 2004 From: fausap at libero.it (Fausto Saporito) Date: Fri, 2 Apr 2004 00:41:25 +0200 Subject: calling ginac from Fortran 90 Message-ID: Hello all, I'm wondering if it's possible to call GINAC from Fortran 90 programs. Do you have any hints? thanks in advance, Fausto From Christian.Bauer at Uni-Mainz.DE Sat Apr 3 12:46:46 2004 From: Christian.Bauer at Uni-Mainz.DE (Christian Bauer) Date: Sat, 3 Apr 2004 12:46:46 +0200 Subject: calling ginac from Fortran 90 In-Reply-To: References: Message-ID: <20040403104646.GA1591@thep.physik.uni-mainz.de> Hi! On Fri, Apr 02, 2004 at 12:41:25AM +0200, Fausto Saporito wrote: > I'm wondering if it's possible to call GINAC from Fortran 90 programs. > Do you have any hints? I don't think that's easily possible. Maybe if you write C wrappers for all GiNaC methods and an appropriate interface block for the Fortran program. Bye, Christian -- / Physics is an algorithm \/ http://www.uni-mainz.de/~bauec002/ From fausap at libero.it Sat Apr 3 16:28:05 2004 From: fausap at libero.it (Fausto Saporito) Date: Sat, 3 Apr 2004 16:28:05 +0200 Subject: calling ginac from Fortran 90 In-Reply-To: <20040403104646.GA1591@thep.physik.uni-mainz.de> References: <20040403104646.GA1591@thep.physik.uni-mainz.de> Message-ID: <1EFAA3EC-857B-11D8-A240-00039377C352@libero.it> Hi Christian, thanks a lot. I was thinking something like this too. :-) By the way, do you think it's possible to compile GINAC under OpenVMS? thanks, fausto Il giorno 03/apr/04, alle 12:46, Christian Bauer ha scritto: > Hi! > > On Fri, Apr 02, 2004 at 12:41:25AM +0200, Fausto Saporito wrote: >> I'm wondering if it's possible to call GINAC from Fortran 90 programs. >> Do you have any hints? > > I don't think that's easily possible. Maybe if you write C wrappers for > all GiNaC methods and an appropriate interface block for the Fortran > program. > > Bye, > Christian > > -- > / Physics is an algorithm > \/ http://www.uni-mainz.de/~bauec002/ > From Christian.Bauer at Uni-Mainz.DE Sat Apr 3 22:32:38 2004 From: Christian.Bauer at Uni-Mainz.DE (Christian Bauer) Date: Sat, 3 Apr 2004 22:32:38 +0200 Subject: calling ginac from Fortran 90 In-Reply-To: <1EFAA3EC-857B-11D8-A240-00039377C352@libero.it> References: <20040403104646.GA1591@thep.physik.uni-mainz.de> <1EFAA3EC-857B-11D8-A240-00039377C352@libero.it> Message-ID: <20040403203238.GB1591@thep.physik.uni-mainz.de> Hi! On Sat, Apr 03, 2004 at 04:28:05PM +0200, Fausto Saporito wrote: > By the way, do you think it's possible to compile GINAC under OpenVMS? Why not? It's just a C++ library, after all. :-) Bye, Christian -- / Physics is an algorithm \/ http://www.uni-mainz.de/~bauec002/ From fausap at libero.it Sat Apr 3 23:33:42 2004 From: fausap at libero.it (Fausto Saporito) Date: Sat, 3 Apr 2004 23:33:42 +0200 Subject: calling ginac from Fortran 90 In-Reply-To: <20040403203238.GB1591@thep.physik.uni-mainz.de> References: <20040403104646.GA1591@thep.physik.uni-mainz.de> <1EFAA3EC-857B-11D8-A240-00039377C352@libero.it> <20040403203238.GB1591@thep.physik.uni-mainz.de> Message-ID: <943965B8-85B6-11D8-A240-00039377C352@libero.it> Hi, yes... it should be easy. :-) But unfortunately under VMS there's no configure, so I have some probs to generate some machine dependent files, like config.h and so on. By the way, I'll try, but if you have a step list about the order of compiling, it should be nice. The same happens for CLN library too. :-) thanks, fausto Il giorno 03/apr/04, alle 22:32, Christian Bauer ha scritto: > Hi! > > On Sat, Apr 03, 2004 at 04:28:05PM +0200, Fausto Saporito wrote: >> By the way, do you think it's possible to compile GINAC under OpenVMS? > > Why not? It's just a C++ library, after all. :-) > > Bye, > Christian > > -- > / Physics is an algorithm > \/ http://www.uni-mainz.de/~bauec002/ > From fausap at libero.it Sun Apr 4 19:51:53 2004 From: fausap at libero.it (Fausto Saporito) Date: Sun, 4 Apr 2004 19:51:53 +0200 Subject: CLN on VMS Message-ID: Hello all, as first step to compile GINAC, I need CLN under VMS :-) So i'm trying to compile CLN with DEC C++ compiler. I hope this is the right place to post something related to CLN, otherwise I apologize for this. Let's start... Now, i generated config.h and intparam.h and I'm starting from src/base directory. I hope it's fine. By the way, I have some probs with io.h file, it seems that DEC compiler complaints a lot about it :-) For example, this is an output for cl_as_err.cc (i'm sorry for the output but it's very ugly I know!) Just two notes: 1) I have to remove all std:: occurence before a stream, because the compiler doesn't like them :-) I don't know why 2) It seems the cl_FN_tag is not defined, but I checked in object.h and i think it's all ok. If somebody knows what could be the reason, should be great! $ cxx/include_dir=("../../include","dka0:[porting.dist.include]") cl_as_err.cc void* operator new (size_t size, void* ptr) { (void)size; return ptr; } ..............^ %CXX-W-NOCORDEL, function "cln::cl_gcobject::operator new(size_t, void *)" has no corresponding operator delete (to be called if an exception is thrown during initialization of an allocated object) at line number 339 in file DKA0:[WORK.cln116.include.cln]object.h;2 void* operator new (size_t size, void* ptr) { (void)size; return ptr; } ..............^ %CXX-W-NOCORDEL, function "cln::cl_gcpointer::operator new(size_t, void *)" has no corresponding operator delete (to be called if an exception is thrown during initialization of an allocated object) at line number 389 in file DKA0:[WORK.cln116.include.cln]object.h;2 void* operator new (size_t size, void* ptr) { (void)size; return ptr; } ..............^ %CXX-W-NOCORDEL, function "cln::cl_rcobject::operator new(size_t, void *)" has no corresponding operator delete (to be called if an exception is thrown during initialization of an allocated object) at line number 439 in file DKA0:[WORK.cln116.include.cln]object.h;2 void* operator new (size_t size, void* ptr) { (void)size; return ptr; } ..............^ %CXX-W-NOCORDEL, function "cln::cl_rcpointer::operator new(size_t, void *)" has no corresponding operator delete (to be called if an exception is thrown during initialization of an allocated object) at line number 489 in file DKA0:[WORK.cln116.include.cln]object.h;2 : cl_gcobject ((cl_private_thing) cl_combine(cl_FN_tag,0)) {} .....................................................^ %CXX-E-UNDECLARED, identifier "cl_FN_tag" is undefined at line number 187 in file DKA0:[WORK.cln116.include.cln]number.h;2 CL_DEFINE_INT_CONSTRUCTORS(cl_number) ^ %CXX-E-UNDECLARED, identifier "cl_FN_tag" is undefined at line number 191 in file DKA0:[WORK.cln116.include.cln]number.h;2 CL_DEFINE_INT_ASSIGNMENT_OPERATORS(cl_number) ^ %CXX-E-UNDECLARED, identifier "cl_FN_tag" is undefined at line number 192 in file DKA0:[WORK.cln116.include.cln]number.h;2 %CXX-I-MESSAGE, 5 errors detected in the compilation of "DKA0:[WORK.cln116.src.base]cl_as_err.cc;3". thanks in advance, Fausto From fausap at libero.it Sun Apr 4 20:04:12 2004 From: fausap at libero.it (Fausto Saporito) Date: Sun, 4 Apr 2004 20:04:12 +0200 Subject: error in object.h (CLN) ? Message-ID: <7A20AE4A-8662-11D8-A240-00039377C352@libero.it> Hi all, following my previous posting about cln compiling under VMS (Alpha arch) I found an error (???) in object.h file. The cl_word_alignment for alpha machines is 8, but in this define there's no such value: // Definition of the tags. #if !defined(CL_WIDE_POINTERS) #if (cl_word_alignment == 2) #define cl_FN_tag 1 #define cl_SF_tag 3 // must satisfy the cl_immediate_p predicate! #endif #if (cl_word_alignment == 4) #define cl_FN_tag 1 #define cl_SF_tag 2 #endif #else // CL_WIDE_POINTERS // Single Floats are immediate as well. #define cl_FN_tag 1 #define cl_SF_tag 2 #define cl_FF_tag 3 #endif There's only 2 and 4. Now CL_WIDE_POINTERS is defined only if long_bitsize is 64, I checked in my intparam.h (generated by intparam.c) and long_bitsize is 32. Is it correct for an Alpha machine? Maybe it's correct that 8 is missing because in this case CL_WIDE_POINTERS should be defined and all is fine. Please, someone could check this? thanks a lot, Fausto From jbrunen at datasolid.de Mon Apr 5 11:34:36 2004 From: jbrunen at datasolid.de (Johannes Brunen) Date: Mon, 5 Apr 2004 11:34:36 +0200 Subject: segmentation fault on GiNaC-1.2.0 using MinGW on Win XP Message-ID: <23D83A07C60A0E47AD964F74DA9694010292F0@mail.datasolid.de> Hi, I'm not subscribed to this list, but I have detected a problem with the new release of GiNaC, which I would like to report. After properly building GiNaC-1.2.0 on windows XP using the MinGW / MSYS platform I got a segmentation fault on starting my demo application. This didn't happen with GiNaC-1.1.7. After looking to the source code I found a problem with the current implementation: In file uitils.cpp the following constants are defined: _num0_p _num0 _ex0 These are initialized on behalf of constructor library_init() which is called by statement static library_init library_initialize from file ex.h (line 53). The constructor function_options::function_options(std::string const & n, std::string const & tn) in file function.cpp (line 56) calls function initialize() (line 67 )which has a statement symtree = 0; in its implementation (line 82). Symtree is of type ex which is initialized by ex(int) which calls basic & ex::construct_from_int(int i) in file ex.cpp (line 329). The relevant line is case 0: return const_cast(_num0); Reference counting, now, forces usage of operator-> on the _num0 object. Now, here is the problem: It may happen that the construtor of function_options() is called before the call of library_init(). function_options() is called during registration of class container by statement GINAC_DECLARE_REGISTERED_CLASS(container, basic) in file container.h (line 130). The construction order of static objects in different translation units is undefined in C++. Therefore the problem may or may not show up. With kind regards and a lot of respect Johannes From cbq at software.ict.ac.cn Mon Apr 5 12:18:28 2004 From: cbq at software.ict.ac.cn (=?GB2312?Q?=B3=CC=B2=AE=C8=BA?=) Date: Mon, 5 Apr 2004 18:18:28 +0800 Subject: segmentation fault on GiNaC-1.2.0 using MinGW on Win XP Message-ID: <20040405101838.6C3C23000663@mailgate2.zdv.Uni-Mainz.DE> Hello,Johannes Brunen! I can't say anything about your trouble. But I have a trouble about ginac-1.1.7. I had tyied to insatll ginac1.1.7 using MinGW(but no MSYS) on windows XP, but I failed. You said you had build ginac1.1.7 successfully on the windows XP, Would you tell me how did you do it? I read this mail:http://www.ginac.de/lists/ginac-list/msg00410.html Did you meet this trouble ever? Thank you very much! sincerely, Boqun Cheng ======= 2004-04-05 11:34:00 You say:====== >Hi, > >I'm not subscribed to this list, but I have detected a problem with the new release of GiNaC, which I would like to report. > >After properly building GiNaC-1.2.0 on windows XP using the MinGW / MSYS platform I got a segmentation fault on >starting my demo application. This didn't happen with GiNaC-1.1.7. > >After looking to the source code I found a problem with the current implementation: > >In file uitils.cpp the following constants are defined: >_num0_p >_num0 >_ex0 > >These are initialized on behalf of constructor library_init() which is called by statement >static library_init library_initialize from file ex.h (line 53). > >The constructor function_options::function_options(std::string const & n, std::string const & tn) >in file function.cpp (line 56) calls function initialize() (line 67 )which has a statement >symtree = 0; in its implementation (line 82). > >Symtree is of type ex which is initialized by ex(int) which calls >basic & ex::construct_from_int(int i) in file ex.cpp (line 329). >The relevant line is case 0: return const_cast(_num0); > >Reference counting, now, forces usage of operator-> on the _num0 object. >Now, here is the problem: It may happen that the construtor of function_options() is called before >the call of library_init(). >function_options() is called during registration of class container by statement >GINAC_DECLARE_REGISTERED_CLASS(container, basic) in file container.h (line 130). > >The construction order of static objects in different translation units is undefined in C++. Therefore >the problem may or may not show up. > >With kind regards and a lot of respect > >Johannes ==== ????????cbq at software.ict.ac.cn ??????????2004-04-05 From kreckel at thep.physik.uni-mainz.de Mon Apr 5 21:38:22 2004 From: kreckel at thep.physik.uni-mainz.de (Richard B. Kreckel) Date: Mon, 5 Apr 2004 21:38:22 +0200 (CEST) Subject: error in object.h (CLN) ? In-Reply-To: <7A20AE4A-8662-11D8-A240-00039377C352@libero.it> Message-ID: On Sun, 4 Apr 2004, Fausto Saporito wrote: > following my previous posting about cln compiling under VMS (Alpha > arch) I found an error (???) in object.h file. > The cl_word_alignment for alpha machines is 8, but in this define > there's no such value: > > // Definition of the tags. > #if !defined(CL_WIDE_POINTERS) > #if (cl_word_alignment == 2) > #define cl_FN_tag 1 > #define cl_SF_tag 3 // must satisfy the cl_immediate_p > predicate! > #endif > #if (cl_word_alignment == 4) > #define cl_FN_tag 1 > #define cl_SF_tag 2 > #endif > #else // CL_WIDE_POINTERS > // Single Floats are immediate as well. > #define cl_FN_tag 1 > #define cl_SF_tag 2 > #define cl_FF_tag 3 > #endif > > There's only 2 and 4. > Now CL_WIDE_POINTERS is defined only if long_bitsize is 64, Where did you get that from? In cln/objec.h:70 it's defined only if cl_pointer_size is 64. And these two are a priori unrelated. > I checked > in my intparam.h (generated by intparam.c) and long_bitsize is 32. Is > it correct for an Alpha machine? This depends on the ABI definition. On UNICOS Max, for instance, even an int is 64 bit. OTOH, those cranks at MS want long to be 32 bits, even on 64 bit architectures. I'm surprised to hear that VMS does this, too. > Maybe it's correct that 8 is missing because in this case > CL_WIDE_POINTERS should be defined and all is fine. Yes, I guess this should be the case. Regards -richy. -- Richard B. Kreckel From kreckel at thep.physik.uni-mainz.de Mon Apr 5 21:43:37 2004 From: kreckel at thep.physik.uni-mainz.de (Richard B. Kreckel) Date: Mon, 5 Apr 2004 21:43:37 +0200 (CEST) Subject: CLN on VMS In-Reply-To: Message-ID: On Sun, 4 Apr 2004, Fausto Saporito wrote: > as first step to compile GINAC, I need CLN under VMS :-) > So i'm trying to compile CLN with DEC C++ compiler. > > I hope this is the right place to post something related to CLN, > otherwise I apologize for this. > > Let's start... > Now, i generated config.h and intparam.h and I'm starting from src/base > directory. I hope it's fine. > > By the way, I have some probs with io.h file, it seems that DEC > compiler complaints a lot about it :-) > For example, this is an output for cl_as_err.cc (i'm sorry for the > output but it's very ugly I know!) > > Just two notes: > > 1) I have to remove all std:: occurence before a stream, because the > compiler doesn't like them :-) I don't know why Uh, uh. This does not bode well. Probably your compiler is too dated. There have been plenty of #ifdefs in CLN's sources to work around DEC CC's idiosyncracies, but I haven't maintained them during the last few years. I was actually planning to remove the remaining ones. > 2) It seems the cl_FN_tag is not defined, but I checked in object.h and > i think it's all ok. If somebody knows what could be the reason, should > be great! > > $ cxx/include_dir=("../../include","dka0:[porting.dist.include]") > cl_as_err.cc > > void* operator new (size_t size, void* ptr) { (void)size; > return ptr; } > ..............^ > %CXX-W-NOCORDEL, function > "cln::cl_gcobject::operator new(size_t, void *)" has no > corresponding operator delete (to be called if an exception is > thrown during initialization of an allocated object) > at line number 339 in file DKA0:[WORK.cln116.include.cln]object.h;2 [...] I assume these are mere warnings. Never mind. Silly compiler. Regards -richy. -- Richard B. Kreckel From kreckel at thep.physik.uni-mainz.de Mon Apr 5 22:32:03 2004 From: kreckel at thep.physik.uni-mainz.de (Richard B. Kreckel) Date: Mon, 5 Apr 2004 22:32:03 +0200 (CEST) Subject: segmentation fault on GiNaC-1.2.0 using MinGW on Win XP In-Reply-To: <23D83A07C60A0E47AD964F74DA9694010292F0@mail.datasolid.de> Message-ID: On Mon, 5 Apr 2004, Johannes Brunen wrote: > I'm not subscribed to this list, but I have detected a problem with the new release of GiNaC, which I would like to report. > > After properly building GiNaC-1.2.0 on windows XP using the MinGW / MSYS platform I got a segmentation fault on > starting my demo application. This didn't happen with GiNaC-1.1.7. > > After looking to the source code I found a problem with the current implementation: > > In file uitils.cpp the following constants are defined: > _num0_p > _num0 > _ex0 > > These are initialized on behalf of constructor library_init() which is called by statement > static library_init library_initialize from file ex.h (line 53). > > The constructor function_options::function_options(std::string const & n, std::string const & tn) > in file function.cpp (line 56) calls function initialize() (line 67 )which has a statement > symtree = 0; in its implementation (line 82). > > Symtree is of type ex which is initialized by ex(int) which calls > basic & ex::construct_from_int(int i) in file ex.cpp (line 329). > The relevant line is case 0: return const_cast(_num0); > > Reference counting, now, forces usage of operator-> on the _num0 object. > Now, here is the problem: It may happen that the construtor of function_options() is called before > the call of library_init(). > function_options() is called during registration of class container by statement > GINAC_DECLARE_REGISTERED_CLASS(container, basic) in file container.h (line 130). > > The construction order of static objects in different translation units is undefined in C++. Therefore > the problem may or may not show up. Congratulations on your excellent analysis. Well, the fix has been applied to CVS already: Regards -richy. -- Richard B. Kreckel From Christian.Bauer at Uni-Mainz.DE Tue Apr 6 17:29:09 2004 From: Christian.Bauer at Uni-Mainz.DE (Christian Bauer) Date: Tue, 6 Apr 2004 17:29:09 +0200 Subject: segmentation fault on GiNaC-1.2.0 using MinGW on Win XP In-Reply-To: References: <23D83A07C60A0E47AD964F74DA9694010292F0@mail.datasolid.de> Message-ID: <20040406152908.GG1591@thep.physik.uni-mainz.de> Hi! On Mon, Apr 05, 2004 at 10:32:03PM +0200, Richard B. Kreckel wrote: > Congratulations on your excellent analysis. Well, the fix has been > applied to CVS already: > I'm beginning to have doubts whether this is the proper fix, because: > On Mon, 5 Apr 2004, Johannes Brunen wrote: > > It may happen that the construtor of function_options() is called before > > the call of library_init(). > > function_options() is called during registration of class container by statement > > GINAC_DECLARE_REGISTERED_CLASS(container, basic) in file container.h (line 130). Isn't library_init() supposed to solve all problems of this kind by being the first static object to appear in any compilation unit? library_init() is declared in ex.h which is the first file included from container.h, so it can't come from there. And the GiNaC class registry doesn't use function_options, so I don't understand why the declaration of container<> would create a function_options object. The only compilation units creating function_options are the various inifcns*.cpp files which include inifcns.h -> function.h -> exprseq.h -> container.h -> ex.h and should see library_init() before any function_options. Did I overlook something? Bye, Christian -- / Physics is an algorithm \/ http://www.uni-mainz.de/~bauec002/ From jbrunen at datasolid.de Wed Apr 7 13:28:29 2004 From: jbrunen at datasolid.de (Johannes Brunen) Date: Wed, 7 Apr 2004 13:28:29 +0200 Subject: segmentation fault on GiNaC-1.2.0 using MinGW on Win XP Message-ID: <23D83A07C60A0E47AD964F74DA9694010292F1@mail.datasolid.de> Hi Christian, I second your doubts. I think that the problem is a little more hidden. After I added some print statements into the library_init's constructor I could confirm that this function is called before the call of function_options::initialize() function, as it was intended. However, the initilaization of the const _num0 reference happens at some time later. Therefore it is undefined at the point of usage in the ex::construct_from_int(int i) call from function_options::initialize(). At the point of _num0 initialization the counter has already a value of count == 33. I still think that the problem lies in the initialization order of statics defined in different translation units. Unfortunately, I couldn't find an exact explanation of my guess. With best regards Johannes From Christian.Bauer at Uni-Mainz.DE Thu Apr 8 15:57:35 2004 From: Christian.Bauer at Uni-Mainz.DE (Christian Bauer) Date: Thu, 8 Apr 2004 15:57:35 +0200 Subject: segmentation fault on GiNaC-1.2.0 using MinGW on Win XP In-Reply-To: <23D83A07C60A0E47AD964F74DA9694010292F1@mail.datasolid.de> References: <23D83A07C60A0E47AD964F74DA9694010292F1@mail.datasolid.de> Message-ID: <20040408135735.GM1591@thep.physik.uni-mainz.de> Hi! On Wed, Apr 07, 2004 at 01:28:29PM +0200, Johannes Brunen wrote: > However, the initilaization of the const _num0 reference happens at some > time later. Therefore it is undefined at the point of usage in the > ex::construct_from_int(int i) call from function_options::initialize(). Ah, of course. This explains it. The ex() default ctor uses _num0_bp directly, so static ex objects are always initialized correctly as long as you're only using the default ctor. Maybe the ex::construct_from_*() functions should also use the _num*_bp pointers instead of the references? Bye, Christian -- / Physics is an algorithm \/ http://www.uni-mainz.de/~bauec002/ From fausap at libero.it Fri Apr 9 10:42:46 2004 From: fausap at libero.it (fausap at libero.it) Date: Fri, 9 Apr 2004 10:42:46 +0200 Subject: error in object.h (CLN) ? Message-ID: ---------- Initial Header ----------- >From : owner-ginac-devel at thep.physik.uni-mainz.de To : "GiNaC developers list" ginac-devel at thep.physik.uni-mainz.de Cc : "Fausto Saporito" fausap at libero.it Date : Mon, 5 Apr 2004 21:38:22 +0200 (CEST) Subject : Re: error in object.h (CLN) ? > > There's only 2 and 4. > > Now CL_WIDE_POINTERS is defined only if long_bitsize is 64, I'm sorry but now I'm not in Italy, so I don't remember where I found this relationship. By the way, I missed during the compiling of intparam.c to define _HAVE_LONGLONG. If I add this define, because LONGLONG is ok on VMS, the intparam.h is quite different. Anyway I had always the problem. So, just to test, I modified manually the long_bitsize definition to 64 (in intparam.h), and all was fine. > > Where did you get that from? In cln/objec.h:70 it's defined only if > cl_pointer_size is 64. And these two are a priori unrelated. Yes... but I remember, but I'm not sure I don't have now the source code, that if cl_pointer_size is related to long_bitsize... I'll try to download the source code on my laptop and I'll check :-) regards, fausto From kreckel at thep.physik.uni-mainz.de Mon Apr 12 00:09:00 2004 From: kreckel at thep.physik.uni-mainz.de (Richard B. Kreckel) Date: Mon, 12 Apr 2004 00:09:00 +0200 (CEST) Subject: segmentation fault on GiNaC-1.2.0 using MinGW on Win XP In-Reply-To: <20040408135735.GM1591@thep.physik.uni-mainz.de> Message-ID: Hi! On Thu, 8 Apr 2004, Christian Bauer wrote: > On Wed, Apr 07, 2004 at 01:28:29PM +0200, Johannes Brunen wrote: > > However, the initilaization of the const _num0 reference happens at some > > time later. Therefore it is undefined at the point of usage in the > > ex::construct_from_int(int i) call from function_options::initialize(). > > Ah, of course. This explains it. The ex() default ctor uses _num0_bp > directly, so static ex objects are always initialized correctly as long > as you're only using the default ctor. The joy of the initializion order! It all looks so correct until you realize that the const references themselves aren't initialized yet while the objects they're supposed to reference are already initialized. This is pervert. I still do hope that the C++ Committee does see the light some lucky day and realize that they can do a great favor to the language and its community by simply demanding that if dependencies form a DAG, then that DAG shall be established by the linker. AIX seems to do it. Patches for GNU ld to that effect have been suggested. It's so obviously the correct thing to do! Rather, they say nothing. The GNU folks then say the order is determined by the link line. Hahaha! Very funny. I have 855 modules in CLN. Under no circumstances am I going to manually arrange that link line. This problem is definitely the most irritating issue of C++. It is also the issue most insistently dodged by the Standard Committee. > Maybe the ex::construct_from_*() functions should also use the _num*_bp > pointers instead of the references? Definitely. Basically, this was the situation in the GiNaC 1.1 tree. I have applied a patch on GiNaC-1.2 and HEAD to that effect. FYI: I've also undone the previous patch in function.pl, since it isn't needed anymore and the original version (albeit equivalent) seems to make the intent clearer. Cheers -richy. -- Richard B. Kreckel From gdr at integrable-solutions.net Wed Apr 14 20:00:04 2004 From: gdr at integrable-solutions.net (Gabriel Dos Reis) Date: 14 Apr 2004 20:00:04 +0200 Subject: segmentation fault on GiNaC-1.2.0 using MinGW on Win XP In-Reply-To: References: Message-ID: "Richard B. Kreckel" writes: | Hi! | | On Thu, 8 Apr 2004, Christian Bauer wrote: | > On Wed, Apr 07, 2004 at 01:28:29PM +0200, Johannes Brunen wrote: | > > However, the initilaization of the const _num0 reference happens at some | > > time later. Therefore it is undefined at the point of usage in the | > > ex::construct_from_int(int i) call from function_options::initialize(). | > | > Ah, of course. This explains it. The ex() default ctor uses _num0_bp | > directly, so static ex objects are always initialized correctly as long | > as you're only using the default ctor. | | The joy of the initializion order! | | It all looks so correct until you realize that the const references | themselves aren't initialized yet while the objects they're supposed to | reference are already initialized. This is pervert. :-/ | I still do hope that the C++ Committee does see the light some lucky day | and realize that they can do a great favor to the language and its | community by simply demanding that if dependencies form a DAG, then that | DAG shall be established by the linker. AIX seems to do it. Patches for | GNU ld to that effect have been suggested. It's so obviously the correct | thing to do! Rather, they say nothing. The GNU folks then say the order | is determined by the link line. Hahaha! Very funny. I have 855 modules | in CLN. Under no circumstances am I going to manually arrange that link | line. This problem is definitely the most irritating issue of C++. It is | also the issue most insistently dodged by the Standard Committee. I think that the committee level, the question is what can we do about this without falling into describing a particular implementation. At the "GNU folks" level, I think the issue is different :-) You said, patches have been suggested for GNU ld, do you have some reference handy? -- Gaby From aej at WPI.EDU Thu Apr 15 18:53:28 2004 From: aej at WPI.EDU (Allan E. Johannesen) Date: Thu, 15 Apr 2004 12:53:28 -0400 Subject: No subject Message-ID: <200404151653.i3FGrSmv027614@mail1.WPI.EDU> I will be out of the office until Monday, April 26 I have received your message, but if you require faster action, please contact the help desk. helpdesk at wpi.edu or (508)831-5888 For network probems, you might email netops at wpi.edu For telephone problems, you might email telecom at wpi.edu For UNIX problems, you might email root at wpi.edu From kreckel at thep.physik.uni-mainz.de Fri Apr 16 23:28:14 2004 From: kreckel at thep.physik.uni-mainz.de (Richard B. Kreckel) Date: Fri, 16 Apr 2004 23:28:14 +0200 (CEST) Subject: segmentation fault on GiNaC-1.2.0 using MinGW on Win XP In-Reply-To: Message-ID: On 14 Apr 2004, Gabriel Dos Reis wrote: > "Richard B. Kreckel" writes: [...] > | I still do hope that the C++ Committee does see the light some lucky day > | and realize that they can do a great favor to the language and its > | community by simply demanding that if dependencies form a DAG, then that > | DAG shall be established by the linker. AIX seems to do it. Patches for > | GNU ld to that effect have been suggested. It's so obviously the correct > | thing to do! Rather, they say nothing. The GNU folks then say the order > | is determined by the link line. Hahaha! Very funny. I have 855 modules > | in CLN. Under no circumstances am I going to manually arrange that link > | line. This problem is definitely the most irritating issue of C++. It is > | also the issue most insistently dodged by the Standard Committee. > > > I think that the committee level, the question is what can we do > about this without falling into describing a particular implementation. > > > At the "GNU folks" level, I think the issue is different :-) > You said, patches have been suggested for GNU ld, do you have some > reference handy? Bruno, may I ask if you still have that old patch for GNU ld mentioned in the cln/modules.h comment lying around somewhere? If so, it would be interesting to have a look at it and see if it is still useful. Luck -richy. -- Richard B. Kreckel From chrisd at sci.kun.nl Fri Apr 16 20:03:50 2004 From: chrisd at sci.kun.nl (Chris Dams) Date: Fri, 16 Apr 2004 18:03:50 +0000 (UTC) Subject: patch for expansion of log. Message-ID: Hello, I found out that trying to calculate log(a*x+b*x*x*log(x)).series(x==0,3) does not terminate. This is because in the function the argument has a pole even if a log(a*x) is subtracted. The attached patch should solve this. With this patch the result of the calculation is (log(x*a))+(a^(-1)*b*log(x))*x+(-1/2*a^(-2)*b^2*log(x)^2)*x^2+Order(x^3) as expected. Have a nice weekend, Chris Dams -------------- next part -------------- Index: inifcns_trans.cpp =================================================================== RCS file: /home/cvs/GiNaC/ginac/inifcns_trans.cpp,v retrieving revision 1.54 diff -r1.54 inifcns_trans.cpp 200a201,216 > if(n==0 && coeff==1) { > epvector epv; > ex acc=(new pseries(rel, epv))->setflag(status_flags::dynallocated); > epv.reserve(2); > epv.push_back(expair(-1, _ex0)); > epv.push_back(expair(Order(_ex1), order)); > ex rest=pseries(rel, epv).add_series(argser); > for(int i=order-1; i>0; --i) { > epvector cterm; > cterm.reserve(1); > cterm.push_back(expair(i%2 ? _ex1/i : _ex_1/i, _ex0)); > acc = pseries(rel, cterm).add_series(ex_to(acc)); > acc = (ex_to(rest)).mul_series(ex_to(acc)); > } > return acc; > } From vollinga at thep.physik.uni-mainz.de Sat Apr 17 14:40:44 2004 From: vollinga at thep.physik.uni-mainz.de (Jens Vollinga) Date: Sat, 17 Apr 2004 14:40:44 +0200 Subject: patch for expansion of log. In-Reply-To: References: Message-ID: <20040417124044.GA7334@thep.physik.uni-mainz.de> Hi. On Fri, Apr 16, 2004 at 06:03:50PM +0000, Chris Dams wrote: > > Hello, > > I found out that trying to calculate > > log(a*x+b*x*x*log(x)).series(x==0,3) > > does not terminate. This is because in the function the argument has a > pole even if a log(a*x) is subtracted. The attached patch should solve > this. With this patch the result of the calculation is > > (log(x*a))+(a^(-1)*b*log(x))*x+(-1/2*a^(-2)*b^2*log(x)^2)*x^2+Order(x^3) > > as expected. > Your patch has been applied. Thanks! Bye, and nice weekend too, Jens From chrisd at sci.kun.nl Mon Apr 19 12:24:43 2004 From: chrisd at sci.kun.nl (Chris Dams) Date: Mon, 19 Apr 2004 10:24:43 +0000 (UTC) Subject: expansion of log Message-ID: Hello all, The patch I sent last friday turned up in the source. That's the good part, but unfortunately at the wrong spot. The line const ex newarg = ex_to((arg/coeff).series(rel, order+n, options)).shift_exponents(-n).convert_to_poly(true); should appear after the patch. If it comes before, the patch does not solve anything. Bye, Chris Dams From vollinga at thep.physik.uni-mainz.de Mon Apr 19 13:07:03 2004 From: vollinga at thep.physik.uni-mainz.de (Jens Vollinga) Date: Mon, 19 Apr 2004 13:07:03 +0200 Subject: expansion of log In-Reply-To: References: Message-ID: <20040419110703.GA21023@thep.physik.uni-mainz.de> Hello. On Mon, Apr 19, 2004 at 10:24:43AM +0000, Chris Dams wrote: > > Hello all, > > The patch I sent last friday turned up in the source. That's the good > part, but unfortunately at the wrong spot. The line > > const ex newarg = ex_to((arg/coeff).series(rel, order+n, options)).shift_exponents(-n).convert_to_poly(true); > > should appear after the patch. If it comes before, the patch does not > solve anything. Oops, yes that happens if you apply patches manually ... ;-) But the applied patch is actually solving the problem, isn't it? So it's just a code style issue, or did I get it wrong? It will be corrected nevertheless. Bye, Jens From chrisd at sci.kun.nl Mon Apr 19 15:35:49 2004 From: chrisd at sci.kun.nl (Chris Dams) Date: Mon, 19 Apr 2004 13:35:49 +0000 (UTC) Subject: expansion of log In-Reply-To: <20040419110703.GA21023@thep.physik.uni-mainz.de> Message-ID: Hello Jens, On Mon, 19 Apr 2004, Jens Vollinga wrote: > Oops, yes that happens if you apply patches manually ... ;-) But the > applied patch is actually solving the problem, isn't it? So it's just a > code style issue, or did I get it wrong? It will be corrected nevertheless. My original patch solved the issue, but the lines that are inserted in the patch appeared at the wrong spot, resulting again in non-termination of the series function. The line that I cited in my previous mail should definitely not appear before my patch because it causes non-termination. Bye, Chris Dams From chrisd at sci.kun.nl Mon Apr 19 16:01:35 2004 From: chrisd at sci.kun.nl (Chris Dams) Date: Mon, 19 Apr 2004 14:01:35 +0000 (UTC) Subject: series taking too looooooong. Message-ID: Hello, I found out that if I make the series expansion of a multiplication that has somewhere in it a factor to a rather large power (say 8), determining the lowest order of that takes very long. For instance, determinging the lowest order of b0^(-10)*(-2*b0^(-7)*log(-b0^(-2)*b1*recs)*b1^3*recs^4-b0^(-5)*log(-b0^(-2)*b1*recs)^2*b1^2*recs^3+b0^(-5)*b1^2*recs^3+b0^(-7)*log(-b0^(-2)*b1*recs)^3*b1^3*recs^4+b0^(-3)*log(-b0^(-2)*b1*recs)*b1*recs^2+3*b0^(-6)*b2*log(-b0^(-2)*b1*recs)*b1*recs^4-1/2*b0^(-7)*b1^3*recs^4-b0^(-4)*b2*recs^3+1/2*b0^(-5)*recs^4*b3-b0^(-1)*recs-b0^(-5)*log(-b0^(-2)*b1*recs)*b1^2*recs^3+5/2*b0^(-7)*log(-b0^(-2)*b1*recs)^2*b1^3*recs^4)^8*b1^9 with respect to the variable recs takes a few seconds on my pentium 1.8 GHz. The attached patch should make this much faster by determining the lowest order of the base and simply multiplying it with the exponent. Bye, Chris -------------- next part -------------- Index: pseries.cpp =================================================================== RCS file: /home/cvs/GiNaC/ginac/pseries.cpp,v retrieving revision 1.76 diff -r1.76 pseries.cpp 787,788c787,794 < < ex buf = recombine_pair_to_ex(*it); --- > ex expon = it->coeff; > int factor = 1; > ex buf; > if(expon.info(info_flags::integer)) { > buf = it->rest; > factor = ex_to(expon).to_int(); > } else > buf = recombine_pair_to_ex(*it); 804c810 < ldegrees.push_back(real_ldegree); --- > ldegrees.push_back(factor*real_ldegree); From bruno at clisp.org Mon Apr 19 15:24:38 2004 From: bruno at clisp.org (Bruno Haible) Date: Mon, 19 Apr 2004 15:24:38 +0200 Subject: segmentation fault on GiNaC-1.2.0 using MinGW on Win XP In-Reply-To: References: Message-ID: <200404191524.38826.bruno@clisp.org> Richard B. Kreckel wrote: > Bruno, may I ask if you still have that old patch for GNU ld mentioned in > the cln/modules.h comment lying around somewhere? If so, it would be > interesting to have a look at it and see if it is still useful. The patch is certainly outdated; however the comments at the end of Ian Lance Taylor's reply should still be useful. What is the "full runtime dependency analysis, done by the compiler", that he is talking about? Bruno -------------- next part -------------- An embedded message was scrubbed... From: unknown sender Subject: no subject Date: no date Size: 44384 URL: From vollinga at thep.physik.uni-mainz.de Mon Apr 19 16:29:03 2004 From: vollinga at thep.physik.uni-mainz.de (Jens Vollinga) Date: Mon, 19 Apr 2004 16:29:03 +0200 Subject: series taking too looooooong. In-Reply-To: References: Message-ID: <20040419142903.GA23541@thep.physik.uni-mainz.de> Hello. On Mon, Apr 19, 2004 at 02:01:35PM +0000, Chris Dams wrote: > > Hello, > > I found out that if I make the series expansion of a multiplication that > has somewhere in it a factor to a rather large power (say 8), determining > the lowest order of that takes very long. For instance, determinging the > lowest order of > > b0^(-10)*(-2*b0^(-7)*log(-b0^(-2)*b1*recs)*b1^3*recs^4-b0^(-5)*log(-b0^(-2)*b1*recs)^2*b1^2*recs^3+b0^(-5)*b1^2*recs^3+b0^(-7)*log(-b0^(-2)*b1*recs)^3*b1^3*recs^4+b0^(-3)*log(-b0^(-2)*b1*recs)*b1*recs^2+3*b0^(-6)*b2*log(-b0^(-2)*b1*recs)*b1*recs^4-1/2*b0^(-7)*b1^3*recs^4-b0^(-4)*b2*recs^3+1/2*b0^(-5)*recs^4*b3-b0^(-1)*recs-b0^(-5)*log(-b0^(-2)*b1*recs)*b1^2*recs^3+5/2*b0^(-7)*log(-b0^(-2)*b1*recs)^2*b1^3*recs^4)^8*b1^9 > > with respect to the variable recs takes a few seconds on my pentium 1.8 > GHz. > > The attached patch should make this much faster by determining the lowest > order of the base and simply multiplying it with the exponent. Patch is applied. Thanks! Bye, Jens From chrisd at sci.kun.nl Wed Apr 21 13:58:37 2004 From: chrisd at sci.kun.nl (Chris Dams) Date: Wed, 21 Apr 2004 11:58:37 +0000 (UTC) Subject: series expansion of powers. Message-ID: Hello, Recently I had to find the power series to 11th order of the fifth power of a polynomial of degree 11 containing all kinds of symbols. The thing that was raised to the fifth power had 139 terms. The point of course is that in this case you do not want to have the full expansion of this power because it is way too large, takes too much time, and not necesary to find the answer. However, using the series method falls back on basic::series and this uses expand() internally. The conclusion would be that power::series is a bit to eager to use basic::series. Changing the line if (!must_expand_basis && !exponent.info(info_flags::negint)) that occurs in power::series into if (!must_expand_basis && !exponent.info(info_flags::negint) && !is_a(basis)) makes this calculation finish within the second. Bye, Chris Dams From Christian.Bauer at Uni-Mainz.DE Wed Apr 21 18:40:24 2004 From: Christian.Bauer at Uni-Mainz.DE (Christian Bauer) Date: Wed, 21 Apr 2004 18:40:24 +0200 Subject: series expansion of powers. In-Reply-To: References: Message-ID: <20040421164024.GC1462@thep.physik.uni-mainz.de> Hi! On Wed, Apr 21, 2004 at 11:58:37AM +0000, Chris Dams wrote: > The conclusion would be that power::series is a bit to eager to use > basic::series. Jo... :) Bye, Christian -- / Physics is an algorithm \/ http://www.uni-mainz.de/~bauec002/ From gwright at comcast.net Fri Apr 23 16:18:03 2004 From: gwright at comcast.net (Gregory Wright) Date: Fri, 23 Apr 2004 10:18:03 -0400 Subject: Link failure on OS X 10.3.3 Message-ID: <08A376B7-9531-11D8-84EF-00039398F084@comcast.net> Hi, While building 1.2.0 on Mac OS X 10.3.3 (Panther) I had a link error. The underlying CLN is version 1.1.6 built with gmp 4.1.2. The compiler is ranger> gcc --version gcc (GCC) 3.3 20030304 (Apple Computer, Inc. build 1495) Copyright (C) 2002 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. The error is below. The multiply defined symbols are harmless, but the undefined symbols are the problem. Is this perhaps some link-ordering issue? Does anyone have any ideas? Please cc: to me directly as I am not subscribed to the list yet. Thanks. Best Wishes, Greg Wright if g++ -DHAVE_CONFIG_H -I. -I. -I.. -I./../ginac -I../ginac -DIN_GINAC -I/opt/local/include -I/opt/local/include -I/opt/local/include -g -O2 -MT ginsh_lexer.o -MD -MP -MF ".deps/ginsh_lexer.Tpo" \ -c -o ginsh_lexer.o `test -f 'ginsh_lexer.cc' || echo './'`ginsh_lexer.cc; \ then mv -f ".deps/ginsh_lexer.Tpo" ".deps/ginsh_lexer.Po"; \ else rm -f ".deps/ginsh_lexer.Tpo"; exit 1; \ fi /bin/sh ../libtool --mode=link g++ -g -O2 -L/opt/local/lib -o ginsh ginsh_parser.o ginsh_lexer.o ../ginac/libginac.la -lreadline -lncurses -L/opt/local/lib -lcln -lgmp mkdir .libs g++ -g -O2 -o .libs/ginsh ginsh_parser.o ginsh_lexer.o -Wl,-bind_at_load -L/opt/local/lib ../ginac/.libs/libginac.dylib -lreadline -lncurses /opt/local/lib/libcln.dylib -lstdc++ /opt/local/lib/libgmp.dylib ld: warning multiple definitions of symbol _PC /opt/local/lib/libreadline.dylib(terminal.so) definition of _PC /usr/lib/libncurses.dylib(lib_tputs.o) definition of _PC ld: warning multiple definitions of symbol _BC /opt/local/lib/libreadline.dylib(terminal.so) definition of _BC /usr/lib/libncurses.dylib(lib_termcap.o) definition of _BC ld: warning multiple definitions of symbol _UP /opt/local/lib/libreadline.dylib(terminal.so) definition of _UP /usr/lib/libncurses.dylib(lib_termcap.o) definition of _UP ld: Undefined symbols: __GLOBAL__I_cl_module__cl_C_ring__firstglobalfun __GLOBAL__I_cl_module__cl_DF_globals__firstglobalfun __GLOBAL__I_cl_module__cl_FF_globals__firstglobalfun __GLOBAL__I_cl_module__cl_GV_I__firstglobalfun __GLOBAL__I_cl_module__cl_GV_number__firstglobalfun __GLOBAL__I_cl_module__cl_I_ring__firstglobalfun __GLOBAL__I_cl_module__cl_LF_globals__firstglobalfun __GLOBAL__I_cl_module__cl_MI__firstglobalfun __GLOBAL__I_cl_module__cl_RA_ring__firstglobalfun __GLOBAL__I_cl_module__cl_R_ring__firstglobalfun __GLOBAL__I_cl_module__cl_SV_number__firstglobalfun __GLOBAL__I_cl_module__cl_SV_ringelt__firstglobalfun __GLOBAL__I_cl_module__cl_UP__firstglobalfun __GLOBAL__I_cl_module__cl_UP_no_ring__firstglobalfun __GLOBAL__I_cl_module__cl_ieee__firstglobalfun __GLOBAL__I_cl_module__cl_no_ring__firstglobalfun __GLOBAL__I_cl_module__cl_prin_globals__firstglobalfun __GLOBAL__I_cl_module__cl_random_def__firstglobalfun __GLOBAL__I_cl_module__cl_st_null__firstglobalfun __GLOBAL__I_cl_module__cl_symbol__firstglobalfun make[2]: *** [ginsh] Error 1 make[1]: *** [all-recursive] Error 1 make: *** [all] Error 2 Error: Target com.apple.build returned: shell command "cd "/Users/gwright/src/darwinports/dports/math/GiNaC/work/GiNaC-1.2.0" && make all" returned error 2 Command output: ld: warning multiple definitions of symbol _BC /opt/local/lib/libreadline.dylib(terminal.so) definition of _BC /usr/lib/libncurses.dylib(lib_termcap.o) definition of _BC ld: warning multiple definitions of symbol _UP /opt/local/lib/libreadline.dylib(terminal.so) definition of _UP /usr/lib/libncurses.dylib(lib_termcap.o) definition of _UP ld: Undefined symbols: __GLOBAL__I_cl_module__cl_C_ring__firstglobalfun __GLOBAL__I_cl_module__cl_DF_globals__firstglobalfun __GLOBAL__I_cl_module__cl_FF_globals__firstglobalfun __GLOBAL__I_cl_module__cl_GV_I__firstglobalfun __GLOBAL__I_cl_module__cl_GV_number__firstglobalfun __GLOBAL__I_cl_module__cl_I_ring__firstglobalfun __GLOBAL__I_cl_module__cl_LF_globals__firstglobalfun __GLOBAL__I_cl_module__cl_MI__firstglobalfun __GLOBAL__I_cl_module__cl_RA_ring__firstglobalfun __GLOBAL__I_cl_module__cl_R_ring__firstglobalfun __GLOBAL__I_cl_module__cl_SV_number__firstglobalfun __GLOBAL__I_cl_module__cl_SV_ringelt__firstglobalfun __GLOBAL__I_cl_module__cl_UP__firstglobalfun __GLOBAL__I_cl_module__cl_UP_no_ring__firstglobalfun __GLOBAL__I_cl_module__cl_ieee__firstglobalfun __GLOBAL__I_cl_module__cl_no_ring__firstglobalfun __GLOBAL__I_cl_module__cl_prin_globals__firstglobalfun __GLOBAL__I_cl_module__cl_random_def__firstglobalfun __GLOBAL__I_cl_module__cl_st_null__firstglobalfun __GLOBAL__I_cl_module__cl_symbol__firstglobalfun make[2]: *** [ginsh] Error 1 make[1]: *** [all-recursive] Error 1 make: *** [all] Error 2 From Christian.Bauer at Uni-Mainz.DE Fri Apr 23 21:03:12 2004 From: Christian.Bauer at Uni-Mainz.DE (Christian Bauer) Date: Fri, 23 Apr 2004 21:03:12 +0200 Subject: GiNaC 1.2.1 now available Message-ID: <20040423190312.GI1462@thep.physik.uni-mainz.de> Hello! GiNaC 1.2.1 is now available! The changes are: - Fixed infinite recursion in atan2_evalf() and improved atan2_eval(). - Added automatic evaluations for trigonometric functions with negative arguments (e.g. sin(-2) -> -sin(2)). - Fixed a static initialization order goof-up. - Fixed various bugs in series expansion. If you had problems using GiNaC 1.2 on certain platforms because you were getting segmentation faults all the way, this release should solve the issue. You can download GiNaC 1.2.1 as always from ftp://ftpthep.physik.uni-mainz.de/pub/GiNaC Bye, Jens and Christian -- / Physics is an algorithm \/ http://www.uni-mainz.de/~bauec002/ From gwright at comcast.net Mon Apr 26 21:52:31 2004 From: gwright at comcast.net (Gregory Wright) Date: Mon, 26 Apr 2004 15:52:31 -0400 Subject: Link Failure with 1.2.1 and Mac OS X 10.3.3 Message-ID: <40EFFE5A-97BB-11D8-84EF-00039398F084@comcast.net> Hi, The latest still fails to link on Mac OS 10.3.3. Build log is below. Any suggestions? Best Wishes, Greg if g++ -DHAVE_CONFIG_H -I. -I. -I.. -I./../ginac -I../ginac -DIN_GINAC -I/opt/local/include -I/opt/local/include -I/opt/local/include -g -O2 -MT ginsh_lexer.o -MD -MP -MF ".deps/ginsh_lexer.Tpo" \ -c -o ginsh_lexer.o `test -f 'ginsh_lexer.cc' || echo './'`ginsh_lexer.cc; \ then mv -f ".deps/ginsh_lexer.Tpo" ".deps/ginsh_lexer.Po"; \ else rm -f ".deps/ginsh_lexer.Tpo"; exit 1; \ fi /bin/sh ../libtool --mode=link g++ -g -O2 -L/opt/local/lib -o ginsh ginsh_parser.o ginsh_lexer.o ../ginac/libginac.la -lreadline -lncurses -L/opt/local/lib -lcln -lgmp mkdir .libs g++ -g -O2 -o .libs/ginsh ginsh_parser.o ginsh_lexer.o -Wl,-bind_at_load -L/opt/local/lib ../ginac/.libs/libginac.dylib -lreadline -lncurses /opt/local/lib/libcln.dylib -lstdc++ /opt/local/lib/libgmp.dylib ld: warning multiple definitions of symbol _PC /opt/local/lib/libreadline.dylib(terminal.so) definition of _PC /usr/lib/libncurses.dylib(lib_tputs.o) definition of _PC ld: warning multiple definitions of symbol _BC /opt/local/lib/libreadline.dylib(terminal.so) definition of _BC /usr/lib/libncurses.dylib(lib_termcap.o) definition of _BC ld: warning multiple definitions of symbol _UP /opt/local/lib/libreadline.dylib(terminal.so) definition of _UP /usr/lib/libncurses.dylib(lib_termcap.o) definition of _UP ld: Undefined symbols: __GLOBAL__I_cl_module__cl_C_ring__firstglobalfun __GLOBAL__I_cl_module__cl_DF_globals__firstglobalfun __GLOBAL__I_cl_module__cl_FF_globals__firstglobalfun __GLOBAL__I_cl_module__cl_GV_I__firstglobalfun __GLOBAL__I_cl_module__cl_GV_number__firstglobalfun __GLOBAL__I_cl_module__cl_I_ring__firstglobalfun __GLOBAL__I_cl_module__cl_LF_globals__firstglobalfun __GLOBAL__I_cl_module__cl_MI__firstglobalfun __GLOBAL__I_cl_module__cl_RA_ring__firstglobalfun __GLOBAL__I_cl_module__cl_R_ring__firstglobalfun __GLOBAL__I_cl_module__cl_SV_number__firstglobalfun __GLOBAL__I_cl_module__cl_SV_ringelt__firstglobalfun __GLOBAL__I_cl_module__cl_UP__firstglobalfun __GLOBAL__I_cl_module__cl_UP_no_ring__firstglobalfun __GLOBAL__I_cl_module__cl_ieee__firstglobalfun __GLOBAL__I_cl_module__cl_no_ring__firstglobalfun __GLOBAL__I_cl_module__cl_prin_globals__firstglobalfun __GLOBAL__I_cl_module__cl_random_def__firstglobalfun __GLOBAL__I_cl_module__cl_st_null__firstglobalfun __GLOBAL__I_cl_module__cl_symbol__firstglobalfun make[2]: *** [ginsh] Error 1 make[1]: *** [all-recursive] Error 1 make: *** [all] Error 2 Error: Target com.apple.build returned: shell command "cd "/Users/gwright/src/darwinports/dports/math/GiNaC/work/GiNaC-1.2.1" && make all" returned error 2 Command output: ld: warning multiple definitions of symbol _BC /opt/local/lib/libreadline.dylib(terminal.so) definition of _BC /usr/lib/libncurses.dylib(lib_termcap.o) definition of _BC ld: warning multiple definitions of symbol _UP /opt/local/lib/libreadline.dylib(terminal.so) definition of _UP /usr/lib/libncurses.dylib(lib_termcap.o) definition of _UP ld: Undefined symbols: __GLOBAL__I_cl_module__cl_C_ring__firstglobalfun __GLOBAL__I_cl_module__cl_DF_globals__firstglobalfun __GLOBAL__I_cl_module__cl_FF_globals__firstglobalfun __GLOBAL__I_cl_module__cl_GV_I__firstglobalfun __GLOBAL__I_cl_module__cl_GV_number__firstglobalfun __GLOBAL__I_cl_module__cl_I_ring__firstglobalfun __GLOBAL__I_cl_module__cl_LF_globals__firstglobalfun __GLOBAL__I_cl_module__cl_MI__firstglobalfun __GLOBAL__I_cl_module__cl_RA_ring__firstglobalfun __GLOBAL__I_cl_module__cl_R_ring__firstglobalfun __GLOBAL__I_cl_module__cl_SV_number__firstglobalfun __GLOBAL__I_cl_module__cl_SV_ringelt__firstglobalfun __GLOBAL__I_cl_module__cl_UP__firstglobalfun __GLOBAL__I_cl_module__cl_UP_no_ring__firstglobalfun __GLOBAL__I_cl_module__cl_ieee__firstglobalfun __GLOBAL__I_cl_module__cl_no_ring__firstglobalfun __GLOBAL__I_cl_module__cl_prin_globals__firstglobalfun __GLOBAL__I_cl_module__cl_random_def__firstglobalfun __GLOBAL__I_cl_module__cl_st_null__firstglobalfun __GLOBAL__I_cl_module__cl_symbol__firstglobalfun make[2]: *** [ginsh] Error 1 make[1]: *** [all-recursive] Error 1 make: *** [all] Error 2 Warning: the following items did not execute (for GiNaC): com.apple.build ranger> From kreckel at thep.physik.uni-mainz.de Mon Apr 26 23:46:24 2004 From: kreckel at thep.physik.uni-mainz.de (Richard B. Kreckel) Date: Mon, 26 Apr 2004 23:46:24 +0200 (CEST) Subject: Link Failure with 1.2.1 and Mac OS X 10.3.3 In-Reply-To: <40EFFE5A-97BB-11D8-84EF-00039398F084@comcast.net> Message-ID: On Mon, 26 Apr 2004, Gregory Wright wrote: > The latest still fails to link on Mac OS 10.3.3. Build log is below. > Any suggestions? It appears like the compiler fails to emit code for the PROVIDE/REQUIRE macros defined in cln/modules.h or something similar. This is a known bug in your environment. I'm still waiting for somebody knowledgeable about the MacOS X toolchain who understands the problem and can provide a patch for CLN. Regards -richy. -- Richard B. Kreckel