Re: [GiNaC-list] Problem using a user-defined class on Mac OS X.
Dear David
This alone doesn't exhibit the issue in the original example. What you've written above is just a plain partial specialization, no violation at all. Now, suppose that the last definition above (foo<T*>::data) was replaced in a *different* translation unit with:
template <> void* foo<void*>::data = &something_else;
which is similar to the original code in this thread. The instantiation of foo<void*>::data can now be different-valued. (Is this analogous to the GiNaC source or proposed patch in question?)
No, there is only one instantiation in the GiNaC source. Both in the unmodified one and the one that I modified to work on Mac OS X. So it cannot have different values. The point is that in the original GiNaC code there would be two instances of, say, foo<void*>::data inside the executable. One comming from the shared library and the other one coming from the executable itself. Library code would modify the first one and code from the executable would modify the other one. To reproduce it in toy code, I think you would have to create a dynamic library on the Mac, but I havn't tried yet. I guess, it could have something to do with the so-called two-level namespaces that the man page of the linker talk about. I could test that. Best wishes, Chris
Hello once again, On Thu, Apr 05, 2007 at 10:59:40AM +0200, Chris.Dams@mi.infn.it wrote:
No, there is only one instantiation in the GiNaC source. Both in the unmodified one and the one that I modified to work on Mac OS X. So it cannot have different values.
So far so good...
The point is that in the original GiNaC code there would be two instances of, say, foo<void*>::data inside the executable.
But foo<T>::data is a static memeber. There should be only one instance.
One comming from the shared library and the other one coming from the executable itself. Library code would modify the first one and code from the executable would modify the other one.
Could you please run nm -B -C -D /path/to/libginac.so nm -B -C /path/to/your/binary (or nm -B /path/to/libginac.so | c++filt, or whatever is it on OS X) both on the original and modified shared objects/binaries and post the difference? Best regards, Alexei -- All science is either physics or stamp collecting.
Dear Alexei
The point is that in the original GiNaC code there would be two instances of, say, foo<void*>::data inside the executable.
But foo<T>::data is a static memeber. There should be only one instance.
Yes, there should be one. Unfortunately there are two.
One comming from the shared library and the other one coming from the executable itself. Library code would modify the first one and code from the executable would modify the other one.
Could you please run nm -B -C -D /path/to/libginac.so nm -B -C /path/to/your/binary (or nm -B /path/to/libginac.so | c++filt, or whatever is it on OS X)
Those options are not recognized on OS X, but I did do the following: for the unpatched lib:
nm ~/lib/libginac-1.4.0.0.0.dylib | grep class_info | grep first 003a4124 s __ZN5GiNaC10class_infoINS_21print_context_optionsEE5firstE 003a3c10 s __ZN5GiNaC10class_infoINS_24registered_class_optionsEE5firstE
nm gendiags | grep class_info | grep first 002a2174 s __ZN5GiNaC10class_infoINS_24registered_class_optionsEE5firstE
for the patched lib:
nm ~/lib/libginac-1.4.0.0.0.dylib | grep class_info | grep first 00000000 a _GLOBAL__D__ZN5GiNaC10class_infoINS_24registered_class_optionsEE5firstE.eh 00000000 a _GLOBAL__I__ZN5GiNaC10class_infoINS_24registered_class_optionsEE5firstE.eh 002f3c60 s __GLOBAL__D__ZN5GiNaC10class_infoINS_24registered_class_optionsEE5firstE 002f3c50 s __GLOBAL__I__ZN5GiNaC10class_infoINS_24registered_class_optionsEE5firstE 00323940 D __ZN5GiNaC10class_infoINS_21print_context_optionsEE5firstE 00323938 D __ZN5GiNaC10class_infoINS_24registered_class_optionsEE5firstE
nm gendiags | grep class_info | grep first U __ZN5GiNaC10class_infoINS_24registered_class_optionsEE5firstE
Best wishes, Chris
Dear all, I did some more tests regarding the problem with the fact that class_info<registered_class>::first occurs more then once in the executable. I discovered two things. (1) the problem does not occur when using the static GiNaC library. (2) I produced a simple test case that exhibits the problem. // file test.h #include <iostream> #include <vector> template <class T> class test { public: test() { std::cout << "the address of v is " << (int)&v << std::endl; } void method() {} private: static std::vector<T> v; }; template <class T> std::vector<T> test<T>::v; extern test<int> t; // file test.C #include "test.h" test<int> t; // file main.C #include "test.h" int main() { t.method(); test<int> t2; return 0; } // compiling: $ g++ -c -o test.o test.C $ g++ -c -o main.o main.C $ g++ -dynamiclib -o test.dylib test.o $ g++ -o main main.o -L. -ltest $ ./main the address of v is 4563560 the address of v is 343368 $ g++ -o main main.o test.o $ ./main the address of v is 343376 the address of v is 343376 I think I will find some gcc or Mac ld forum/newsgroup or whatever to see if anyone knows about this. Best wishes, Chris
participants (2)
-
Chris.Dams＠mi.infn.it
-
varg＠theor.jinr.ru