BORLAND C++

BORLAND C++

[Santiago Calderon]

Hello everybody,
 
I was using the Borland C++ version of gsl and I would
like to share some points about.
If you trie to use the test programs in order to check
that the library works (you have them in the subdirectories
of the source of gsl) you will be surprised because they
compile fine (I really tested only the test.c files of the
diff and randist directories) but some of them works and
some of them produce funny memory access violations or thinks
like that.
 
For example, the test.c program of the diff directory works
fine, but if you trie the test.c program of the randist
directory it compiles fine but you (I least I had) will
have access violations errors.
 
 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.
 
Santiago Calderon

Re: BORLAND C++

[Brian Gough]

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

Re: BORLAND C++

[Santiago Calderon]

Hi Brian,

In the Borland C++ compiler is the some as far as I know.

When you build the dll you must define this variables as
__declspec(dllexport)

and when you write an application that use the dll you must define
the variable in you include files as
__declspec(dllimport)

I suppose that to solve that definitively , the source of the library should
be
modified so that the dll knows about these variable to be exported
using the __declspec(dllexport)  and when we use it in the program
using the __declspec(dllimport), at least to do it fully compatible with
Borland compiler (and perhaps MSCV??).


Regard



----- Original Message -----
From: "Brian Gough" <bjg@network-theory.co.uk>
To: "Santiago Calderon" <sacate@jazzfutboleros.com>
Cc: <gsl-discuss@sources.redhat.com>
Sent: Thursday, December 13, 2001 11:34 PM
Subject: Re: BORLAND C++
> 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
>

Re: BORLAND C++

[Brian Gough]

Santiago Calderon writes:
 >  In the Borland C++ compiler is the some as far as I know.
 >  When you build the dll you must define this variables as
 > __declspec(dllexport)
 >  and when you write an application that use the dll you must define
 > the variable in you include files as __declspec(dllimport)
 >  I suppose that to solve that definitively , the source of the
 > library should be modified so that the dll knows about these
 > variable to be exported using the __declspec(dllexport) and when we
 > use it in the program using the __declspec(dllimport), at least to
 > do it fully compatible with Borland compiler (and perhaps MSCV??).

There's a perl script in msvc/mkdllheaders.pl which I've been using
to add this to the headers of the Windows version.

regards
Brian


#!/usr/bin/perl

while (<>) {
    if (/^extern/ && !/^extern inline/) {
        $a = $_; $a =~ s/^extern/__declspec(dllexport)/;
        $b = $_; $b =~ s/^extern/__declspec(dllimport)/;
        print "#ifdef GSL_EXPORTS\n";
        print "$a";
        print "#elif defined(GSL_IMPORTS)\n";
        print "$b";
        print "#else\n";
        print "$_";
        print "#endif\n";
    } else {
        print;
    }
}

Re: BORLAND C++

[Brian Gough]

Santiago Calderon writes:
 >  In the Borland C++ compiler is the some as far as I know.
 >  When you build the dll you must define this variables as
 > __declspec(dllexport)
 >  and when you write an application that use the dll you must define
 > the variable in you include files as __declspec(dllimport)
 >  I suppose that to solve that definitively , the source of the
 > library should be modified so that the dll knows about these
 > variable to be exported using the __declspec(dllexport) and when we
 > use it in the program using the __declspec(dllimport), at least to
 > do it fully compatible with Borland compiler (and perhaps MSCV??).

There's a perl script in msvc/mkdllheaders.pl which I've been using
to add this to the headers of the Windows version.

regards
Brian


#!/usr/bin/perl

while (<>) {
    if (/^extern/ && !/^extern inline/) {
        $a = $_; $a =~ s/^extern/__declspec(dllexport)/;
        $b = $_; $b =~ s/^extern/__declspec(dllimport)/;
        print "#ifdef GSL_EXPORTS\n";
        print "$a";
        print "#elif defined(GSL_IMPORTS)\n";
        print "$b";
        print "#else\n";
        print "$_";
        print "#endif\n";
    } else {
        print;
    }
}

Re: BORLAND C++

[Santiago Calderon]

Hi Brian,

In the Borland C++ compiler is the some as far as I know.

When you build the dll you must define this variables as
__declspec(dllexport)

and when you write an application that use the dll you must define
the variable in you include files as
__declspec(dllimport)

I suppose that to solve that definitively , the source of the library should
be
modified so that the dll knows about these variable to be exported
using the __declspec(dllexport)  and when we use it in the program
using the __declspec(dllimport), at least to do it fully compatible with
Borland compiler (and perhaps MSCV??).


Regard



----- Original Message -----
From: "Brian Gough" <bjg@network-theory.co.uk>
To: "Santiago Calderon" <sacate@jazzfutboleros.com>
Cc: <gsl-discuss@sources.redhat.com>
Sent: Thursday, December 13, 2001 11:34 PM
Subject: Re: BORLAND C++
> 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
>

Re: BORLAND C++

[Brian Gough]

Santiago Calderon writes:
 >  In the Borland C++ compiler is the some as far as I know.
 >  When you build the dll you must define this variables as
 > __declspec(dllexport)
 >  and when you write an application that use the dll you must define
 > the variable in you include files as __declspec(dllimport)
 >  I suppose that to solve that definitively , the source of the
 > library should be modified so that the dll knows about these
 > variable to be exported using the __declspec(dllexport) and when we
 > use it in the program using the __declspec(dllimport), at least to
 > do it fully compatible with Borland compiler (and perhaps MSCV??).

There's a perl script in msvc/mkdllheaders.pl which I've been using
to add this to the headers of the Windows version.

regards
Brian


#!/usr/bin/perl

while (<>) {
    if (/^extern/ && !/^extern inline/) {
        $a = $_; $a =~ s/^extern/__declspec(dllexport)/;
        $b = $_; $b =~ s/^extern/__declspec(dllimport)/;
        print "#ifdef GSL_EXPORTS\n";
        print "$a";
        print "#elif defined(GSL_IMPORTS)\n";
        print "$b";
        print "#else\n";
        print "$_";
        print "#endif\n";
    } else {
        print;
    }
}

Re: BORLAND C++

[Brian Gough]

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

BORLAND C++

[Santiago Calderon]

Hello everybody,
 
I was using the Borland C++ version of gsl and I would
like to share some points about.
If you trie to use the test programs in order to check
that the library works (you have them in the subdirectories
of the source of gsl) you will be surprised because they
compile fine (I really tested only the test.c files of the
diff and randist directories) but some of them works and
some of them produce funny memory access violations or thinks
like that.
 
For example, the test.c program of the diff directory works
fine, but if you trie the test.c program of the randist
directory it compiles fine but you (I least I had) will
have access violations errors.
 
 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.
 
Santiago Calderon

Re: Borland C++

[Santiago Calderon]

Hi viadrina,

I use the Borland C++ Builder 5.0, although I suppose there would not be any
problem with
the Borland C++ 5.5.

You can find the libraries in the page

http://sourceforge.net/project/showfiles.php?group_id=23617&release_id=60979

In this page you will find a gsl section,
you need to download the files:

gsl-1.0-bin.zip (include the dll libraries)
gsl-1.0-doc.zip (documentation)
gsl-1.0-lib.zip (imported static library to compile with Borland, the ones
called ...bcc.lib)

I reached this web page from http://gnuwin32.sourceforge.net/ that is
refered from
http://sources.redhat.com/gsl/

In the projects that I have using gsl I faced 3 different situations, but in
all the projects I have added
the lisgsl-bcc.lib and the libgslcblas-bcc.lib that are the imports
libraries needed to compile and that
requiere to have later the dll´s in the system in order the exe to work.

The 3 situation I found are,

1- I added to the projects only the 2 libraries I mentioned and the source
of the code calling gsl functions
without putting in it the config.h file and it compiles and works. An
example is the test program gsl_testdiff.c
include with the source of the library

2-I added to the projects only the 2 libraries I mentioned and the source of
the code calling gsl functions
without putting in it the config.h file and it compiles but does not works.
An example is the test program gsl_testrndf.c
include with the source of the library. To solve that I needed to add the
mt.c source file of the gsl library to my project
and remove the config.h in it. In that way the project compiles and works

3-I added to the projects only the 2 libraries and previously and I modified
the config.h file to do it to work with Borland,
to do that I needed only to put into comments the following lines in the
config.h:

    //#define PACKAGE "gsl"

   //#define HAVE_INLINE 1

 Once you have modified the config.h of gsl, the compile step will not cause
any problem in the sense you will not have to avoid the config.h and the
only question in your project is to know by debugging, just in case you have
a problem running the program, with part of the source of the gsl you should
add, but it is not to difficult.

So the third option should work in any case

 I hope that help you


Regards
Santiago

----- Original Message -----
From: "Viadrina" <sliwa@euv-frankfurt-o.de>
To: <gsl-discuss@sources.redhat.com>
Sent: Wednesday, April 17, 2002 12:32 PM
Subject: Borland C++


> Does anybody know, where I can find all the necessary gsl libraries for
Borland 5.5.
> I was trying to translate the MS Visual C++ projects into Borland's ones.
Finaly I did it, but
> I could compile only the blas library. For GSL it didn't work. There were
tons of warnings and I
> couldn't finish it finaly. But I know, that poeple use GSL under Borland
environment.
>
> Thanks for all hints
>
> Przem
>
>
>
>

Borland C++

[Viadrina]

Does anybody know, where I can find all the necessary gsl libraries for Borland 5.5.
I was trying to translate the MS Visual C++ projects into Borland's ones. Finaly I did it, but 
I could compile only the blas library. For GSL it didn't work. There were tons of warnings and I 
couldn't finish it finaly. But I know, that poeple use GSL under Borland environment.

Thanks for all hints

Przem

Re: Borland C++

[Brian Gough]

Viadrina writes:
 > Does anybody know, where I can find all the necessary gsl libraries
 > for Borland 5.5.  I was trying to translate the MS Visual C++
 > projects into Borland's ones. Finaly I did it, but I could compile
 > only the blas library. For GSL it didn't work. There were tons of
 > warnings and I couldn't finish it finaly. But I know, that poeple
 > use GSL under Borland environment.

I don't know much about it but there are some previous postings in
the list archives, accessible from http://sources.redhat.com/gsl/

Brian

Re: Borland C++

[Santiago Calderon]

Hi viadrina,

I use the Borland C++ Builder 5.0, although I suppose there would not be any
problem with
the Borland C++ 5.5.

You can find the libraries in the page

http://sourceforge.net/project/showfiles.php?group_id=23617&release_id=60979

In this page you will find a gsl section,
you need to download the files:

gsl-1.0-bin.zip (include the dll libraries)
gsl-1.0-doc.zip (documentation)
gsl-1.0-lib.zip (imported static library to compile with Borland, the ones
called ...bcc.lib)

I reached this web page from http://gnuwin32.sourceforge.net/ that is
refered from
http://sources.redhat.com/gsl/

In the projects that I have using gsl I faced 3 different situations, but in
all the projects I have added
the lisgsl-bcc.lib and the libgslcblas-bcc.lib that are the imports
libraries needed to compile and that
requiere to have later the dll´s in the system in order the exe to work.

The 3 situation I found are,

1- I added to the projects only the 2 libraries I mentioned and the source
of the code calling gsl functions
without putting in it the config.h file and it compiles and works. An
example is the test program gsl_testdiff.c
include with the source of the library

2-I added to the projects only the 2 libraries I mentioned and the source of
the code calling gsl functions
without putting in it the config.h file and it compiles but does not works.
An example is the test program gsl_testrndf.c
include with the source of the library. To solve that I needed to add the
mt.c source file of the gsl library to my project
and remove the config.h in it. In that way the project compiles and works

3-I added to the projects only the 2 libraries and previously and I modified
the config.h file to do it to work with Borland,
to do that I needed only to put into comments the following lines in the
config.h:

    //#define PACKAGE "gsl"

   //#define HAVE_INLINE 1

 Once you have modified the config.h of gsl, the compile step will not cause
any problem in the sense you will not have to avoid the config.h and the
only question in your project is to know by debugging, just in case you have
a problem running the program, with part of the source of the gsl you should
add, but it is not to difficult.

So the third option should work in any case

 I hope that help you


Regards
Santiago

----- Original Message -----
From: "Viadrina" <sliwa@euv-frankfurt-o.de>
To: <gsl-discuss@sources.redhat.com>
Sent: Wednesday, April 17, 2002 12:32 PM
Subject: Borland C++


> Does anybody know, where I can find all the necessary gsl libraries for
Borland 5.5.
> I was trying to translate the MS Visual C++ projects into Borland's ones.
Finaly I did it, but
> I could compile only the blas library. For GSL it didn't work. There were
tons of warnings and I
> couldn't finish it finaly. But I know, that poeple use GSL under Borland
environment.
>
> Thanks for all hints
>
> Przem
>
>
>
>

Re: Borland C++

[Brian Gough]

Viadrina writes:
 > Does anybody know, where I can find all the necessary gsl libraries
 > for Borland 5.5.  I was trying to translate the MS Visual C++
 > projects into Borland's ones. Finaly I did it, but I could compile
 > only the blas library. For GSL it didn't work. There were tons of
 > warnings and I couldn't finish it finaly. But I know, that poeple
 > use GSL under Borland environment.

I don't know much about it but there are some previous postings in
the list archives, accessible from http://sources.redhat.com/gsl/

Brian

Borland C++

[Viadrina]

Does anybody know, where I can find all the necessary gsl libraries for Borland 5.5.
I was trying to translate the MS Visual C++ projects into Borland's ones. Finaly I did it, but 
I could compile only the blas library. For GSL it didn't work. There were tons of warnings and I 
couldn't finish it finaly. But I know, that poeple use GSL under Borland environment.

Thanks for all hints

Przem

Re: Borland C++

[Przemyslaw Sliwa]

On Mon, 3 Dec 2001, Brian Gough wrote:

> Przemyslaw Sliwa writes:
>  > A stupid quastion.
>  >  I'm using the libraries *-bcc.lib, libgslcblas.dll and libgsl.dll
>  > under Windows. I can compile and link my program without any
>  > problems. But when I start to use my *.exe program it gives me some
>  > error messages about the memory. The libs *dll are in the same
>  > folder. What should I change in the options of my project?
>  >  Please Help!!!
> 
> If nobody knows here you could try the gnuwin32-users mailing list.
Thanks, but I was looking for a link to the mailing list. I couldn't find
it. Please give me the adress, if You can. 

 It
> might help to post the program and error message too.
> 
Thanks 
Przem

Re: Borland C++

[Brian Gough]

Przemyslaw Sliwa writes:
 > A stupid quastion.
 >  I'm using the libraries *-bcc.lib, libgslcblas.dll and libgsl.dll
 > under Windows. I can compile and link my program without any
 > problems. But when I start to use my *.exe program it gives me some
 > error messages about the memory. The libs *dll are in the same
 > folder. What should I change in the options of my project?
 >  Please Help!!!

If nobody knows here you could try the gnuwin32-users mailing list. It
might help to post the program and error message too.

Borland C++

[Przemyslaw Sliwa]

A stupid quastion.

I'm using the libraries *-bcc.lib, libgslcblas.dll and libgsl.dll under
Windows. I can compile and link my program without any problems. But when
I start to use my *.exe program it gives me some error messages about the
memory. The libs *dll are in the same folder. What should I change in the
options of my project?

Please Help!!!

Przem

Re: Borland C++

[Brian Gough]

Przemyslaw Sliwa writes:
 > > If nobody knows here you could try the gnuwin32-users mailing list.
 > Thanks, but I was looking for a link to the mailing list. I couldn't find
 > it. Please give me the adress, if You can. 

http://gnuwin32.sourceforge.net/lists.html

Re: Borland C++

[Przemyslaw Sliwa]

On Mon, 3 Dec 2001, Brian Gough wrote:

> Przemyslaw Sliwa writes:
>  > A stupid quastion.
>  >  I'm using the libraries *-bcc.lib, libgslcblas.dll and libgsl.dll
>  > under Windows. I can compile and link my program without any
>  > problems. But when I start to use my *.exe program it gives me some
>  > error messages about the memory. The libs *dll are in the same
>  > folder. What should I change in the options of my project?
>  >  Please Help!!!
> 
> If nobody knows here you could try the gnuwin32-users mailing list.
Thanks, but I was looking for a link to the mailing list. I couldn't find
it. Please give me the adress, if You can. 

 It
> might help to post the program and error message too.
> 
Thanks 
Przem

Re: Borland C++

[Brian Gough]

Przemyslaw Sliwa writes:
 > > If nobody knows here you could try the gnuwin32-users mailing list.
 > Thanks, but I was looking for a link to the mailing list. I couldn't find
 > it. Please give me the adress, if You can. 

http://gnuwin32.sourceforge.net/lists.html

Re: Borland C++

[Przemyslaw Sliwa]

On Mon, 3 Dec 2001, Brian Gough wrote:

> Przemyslaw Sliwa writes:
>  > A stupid quastion.
>  >  I'm using the libraries *-bcc.lib, libgslcblas.dll and libgsl.dll
>  > under Windows. I can compile and link my program without any
>  > problems. But when I start to use my *.exe program it gives me some
>  > error messages about the memory. The libs *dll are in the same
>  > folder. What should I change in the options of my project?
>  >  Please Help!!!
> 
> If nobody knows here you could try the gnuwin32-users mailing list.
Thanks, but I was looking for a link to the mailing list. I couldn't find
it. Please give me the adress, if You can. 

 It
> might help to post the program and error message too.
> 
Thanks 
Przem

Re: Borland C++

[Brian Gough]

Przemyslaw Sliwa writes:
 > A stupid quastion.
 >  I'm using the libraries *-bcc.lib, libgslcblas.dll and libgsl.dll
 > under Windows. I can compile and link my program without any
 > problems. But when I start to use my *.exe program it gives me some
 > error messages about the memory. The libs *dll are in the same
 > folder. What should I change in the options of my project?
 >  Please Help!!!

If nobody knows here you could try the gnuwin32-users mailing list. It
might help to post the program and error message too.

Borland C++

[Przemyslaw Sliwa]

A stupid quastion.

I'm using the libraries *-bcc.lib, libgslcblas.dll and libgsl.dll under
Windows. I can compile and link my program without any problems. But when
I start to use my *.exe program it gives me some error messages about the
memory. The libs *dll are in the same folder. What should I change in the
options of my project?

Please Help!!!

Przem