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.