This is the mail archive of the
gsl-discuss@sources.redhat.com
mailing list for the GSL project.
Re: BORLAND C++
- From: Brian Gough <bjg at network-theory dot co dot uk>
- To: "Santiago Calderon" <sacate at jazzfutboleros dot com>
- Cc: <gsl-discuss at sources dot redhat dot com>
- Date: Thu, 13 Dec 2001 22:34:19 +0000 (GMT)
- Subject: Re: BORLAND C++
- References: <003201c183b4$a8f70f00$0be6a8c0@SACATE>
Santiago Calderon writes:
> I was looking for and I found that the problem was
> caused when you tried to write in some memory variable that
> it seems to belong to the dll part and it is not exported.
> Well, I solved the problem in this situation simply adding
> the *.c file of gsl code involve with this variable in my
> project.
>
> In the test.c example of the randist directory I added the
> mt.c file of the gsl source in the randist directory to my
> project to use the variable of gsl involved in this case that
> caused the problems from this intead of from the dll directly and
> it works.
>
> I do not know exactly whay this problem happens but the
> method I write solved my problems by now.
Hi,
The errors are related to static data (e.g. pointers) not being
imported. There is some information on the gnuwin32 site at
http://gnuwin32.sourceforge.net/compile.html
In MSVC the extension __declspec(dllimport) can be added to the header
files to handle that, I don't know what other compilers do though.
regards
Brian