c++ - Progresses...still a little problem (1 easy question)
- Stefano (28/28) Mar 07 2006 I think i have solved the config.h configuration, patching the configure...
- Walter Bright (6/46) Mar 09 2006 I don't even know what extern inline should mean :-(
- Stefano (20/28) Mar 10 2006 Thank you for your reply, when you have time also reply to my last e-mai...
- Walter Bright (4/4) Mar 11 2006 I'll add the inline thing in to the queue of bugs to be fixed. In the
I think i have solved the config.h configuration, patching the configure script to run with dmc (problem with cpp, the gnu preprocessor) and editing by hand obvious mistakes. The inline problem is that dmc can't take extern inline but inline and static inline are ok. Just to be sure, inline and __inline has the same meaning for dmc? And what is the difference between static inline and inline for dmc? I'm going to debug the rng (random number generator) problem, maybe you could help me with the smaller one: I still have the problem of _atanh: symbol undefind in libgsl.lib That is: libgsl.lib have the _gsl_atanh symbol, and if i specify that i don't have atanh in the math.h library, than: #if !HAVE_DECL_ATANH #define atanh gsl_atanh #endif So obviously no problem. Instead if i specify that i have this function in dm\include\math.h (and it's true), when i link testcomplex.obj and libgsl.lib to create the test executable (for gsl complex functions) it gives the error (as now atanh is not inside libgsl.lib). Why is it searching for this symbol and is not just using the function atanh? Maybe i'm doing something wrong when creating the libgsl.lib library? (I just linked the various .obj files with lib -c -p256 libgsl.lib ...). If i run libunres on libgsl.lib i get the _atanh symbol with _fopen _fprintf and the other system function (still, defined in the various dm\include headers). I know this is probably a stupid mistake, but i'm a newbie :) Thank you in advance Stefano
Mar 07 2006
"Stefano" <Stefano_member pathlink.com> wrote in message news:dujrue$13qu$1 digitaldaemon.com...I think i have solved the config.h configuration, patching the configure script to run with dmc (problem with cpp, the gnu preprocessor) and editing by hand obvious mistakes. The inline problem is that dmc can't take extern inlineI don't even know what extern inline should mean :-(but inline and static inline are ok. Just to be sure, inline and __inline has the same meaning for dmc?Yes.And what is the difference between static inline and inline for dmc?None.I'm going to debug the rng (random number generator) problem, maybe you could help me with the smaller one: I still have the problem of _atanh: symbol undefind in libgsl.libUnfortunately, atanh isn't implemented in dmc's library yet.That is: libgsl.lib have the _gsl_atanh symbol, and if i specify that i don't have atanh in the math.h library, than: #if !HAVE_DECL_ATANH #define atanh gsl_atanh #endif So obviously no problem. Instead if i specify that i have this function in dm\include\math.h (and it's true), when i link testcomplex.obj and libgsl.lib to create the test executable (for gsl complex functions) it gives the error (as now atanh is not inside libgsl.lib). Why is it searching for this symbol and is not just using the function atanh? Maybe i'm doing something wrong when creating the libgsl.lib library? (I just linked the various .obj files with lib -c -p256 libgsl.lib ...). If i run libunres on libgsl.lib i get the _atanh symbol with _fopen _fprintf and the other system function (still, defined in the various dm\include headers). I know this is probably a stupid mistake, but i'm a newbie :) Thank you in advance Stefano
Mar 09 2006
Thank you for your reply, when you have time also reply to my last e-mail. Let me summirize the situation: I have now succesfully ported the gnu scientific library 1.7 for dmc,all tests passed; the problem is that i have to disable inlining, and that really impacts performances, nearly double of the gcc ones. To be able to use inlining i need the static inline dmc implementation to follow the C99 standard: the scope of the function is limited to the single .c file. To see the differences between the C99 standard and the gunC implementation (NOT C++ !) of inline, static inline, extern inline, see: http://www.greenend.org.uk/rjk/2003/03/inline.html The way extern inline is used in gsl is the gnuC implementation, but that should not be a problem as substituting extern inline with static inline (in the gnuC implementation) works in the majority of the situations (see discussion in linux kernel mailinglist). I would really like to have this feature supported, as will make gsl compile ok right out of the box with dmc. Only minor problem is in one static function that gets re-declared (after the definition) in the same .c file, and that erase the previous definition using dmc. Let me know it this is possible. Thank youThe inline problem is that dmc can't take extern inlineI don't even know what extern inline should mean :-(but inline and static inline are ok. Just to be sure, inline and __inline has the same meaning for dmc?Yes.And what is the difference between static inline and inline for dmc?None.
Mar 10 2006
I'll add the inline thing in to the queue of bugs to be fixed. In the meantime, you can make it work out of the box now by using the -D compiler switch to rename the static inlines to unique names for each source file. Bit of a pain, but doable.
Mar 11 2006