• Stefano <Stefano_member pathlink.com> Mar 07 2006
• "Walter Bright" <newshound digitalmars.com> Mar 09 2006
• Stefano <Stefano_member pathlink.com> Mar 10 2006
• "Walter Bright" <newshound digitalmars.com> Mar 11 2006

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

"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 inline


I 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.lib


Unfortunately, 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


 

 The inline problem is that dmc can't take extern inline


I 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.


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 you

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.