On 2009-03-27 10:20, Werner Smekal wrote:
> Hi Arjen,
>
> I need dlltool to create the import libraries, otherwise they are not
> created (for me). You could comment it in bindings/f77/CMakeList.txt and
> see if for you the import libraries are created. But then: why for you
> and not for me?
Hi Arjen,
I need dlltool to create the import libraries, otherwise they are not
created (for me). You could comment it in bindings/f77/CMakeList.txt
and see if for you the import libraries are created. But then: why for
you and not for me?
Regards,
Werner
On 27.03.2009, at 10:15, Arjen Mar
Hi Werner,
I have run into a problem with dlltool: is that still required in your
case? I run into it, because my rather basic installation of MinGW
does not have it (the tdragon one): make/cmake complains about an
unknown tool.
Regards,
Arjen
On 2009-03-24 09:51, Werner Smekal wrote:
> Hi Arje
[Repost due to mail configuration problem]
Hi Arjen,
> very odd! I will delve into this myself :(
>
I've already found the problem. The .def file needs something like
LIBRARY libplplotf77d.dll
at the top of the file at least for MinGW. Fortran 77 and 95 examples
compile and work now. I'm sorr
Hi Werner,
glad you found that out, but I am slightly puzzled:
- I do not recall ever needing that line
- the actual line will depend on the option to use double-precision
or not, so that complicates matters
Furthermore, while trying to reproduce your problem I ran into
one or two disturbing i
Hi Werner,
very odd! I will delve into this myself :(
Regards,
Arjen
On 2009-03-24 09:51, Werner Smekal wrote:
> Hi Arjen,
>>
>> On 2009-03-24 09:38, Werner Smekal wrote:
>>> Hi,
>>>
>>> I'm using the dynamic drivers and it exits with a message like
>>> (translated from German):
>>>
>>> "The ap
Hi Arjen,
>
> On 2009-03-24 09:38, Werner Smekal wrote:
>> Hi,
>>
>> I'm using the dynamic drivers and it exits with a message like
>> (translated from German):
>>
>> "The application could not be started, since (null).dll wasn't
>> found. A
>> new installation of the application might solve the
Hi Werner,
the def-file is a file with instructions for the linker, so as far as
CMake is concerned, it has the same function as a source file. I am
not sure why it works for me and not for you (right now, it is not
part of the dependencies - we need to take a look at that).
This requires furthe
On 2009-03-24 09:38, Werner Smekal wrote:
> Hi,
>
> I'm using the dynamic drivers and it exits with a message like
> (translated from German):
>
> "The application could not be started, since (null).dll wasn't found. A
> new installation of the application might solve the problem."
>
> Some
Hi,
I'm using the dynamic drivers and it exits with a message like
(translated from German):
"The application could not be started, since (null).dll wasn't found.
A new installation of the application might solve the problem."
Some problem converting C to Fortran strings?
Regards,
Werner
O
Hi Arjen,
>
> right, my Fortran compiler is usually gfortran or g95 - g77 is a very
> old compiler that is no longer actively maintained. I can imagine
> that the compiler does not produce import libraries - shared libraries
> under Windows simply have too many pecularities, so they are probably
>
Hi Werner,
what is the reason they do not run? If you do not get any output,
the program simply stops, that could be due to a missing DLL (sometimes
you get a message, sometimes you don't under Windows).
Regards,
Arjen
On 2009-03-24 09:27, Werner Smekal wrote:
> Hi Alan,
>
>> "trim" is recogni
Hi Alan,
> "trim" is recognized by the gfortran compiler (at least the version
> of it
> that I have), but not g77 (which I believe is what you still must
> use with
> MinGW). Our other f77 examples use lnblnk instead of trim and
> apparently
> you (and anybody else who has tested our f77 e
Hello Alan,
For MinGW we also have g95 and gfortran available. But it can't
hurt to test with a FORTRAN 77 compiler perse.
Regards,
Arjen
On 2009-03-20 02:31, Alan W. Irwin wrote:
>
> "trim" is recognized by the gfortran compiler (at least the version of it
> that I have), but not g77 (which
Hi Werner,
right, my Fortran compiler is usually gfortran or g95 - g77 is a very
old compiler that is no longer actively maintained. I can imagine
that the compiler does not produce import libraries - shared libraries
under Windows simply have too many pecularities, so they are probably
beyond g77
On 2009-03-19 22:08+0100 Werner Smekal wrote:
> Example 23 doesn't compile now. I get the following message:
>
> [ 77%] Building Fortran object examples/f77/CMakeFiles/x23f.dir/x23f.f.obj
> Z:\DevZone\PLdev\build\gcc\debug\examples\f77\x23f.f: In program `x23f':
> Z:\DevZone\PLdev\build\gcc\debug\
Hi Arjen,
>>
> Well, the cause of the problem is clear now: when linking the Fortran
> bindings
> into a DLL, gfortran would need the option -Wl,-out-implib,... (or
> something
> similar) to produce the missing library.
>
> This option _is_ present in the gcc part to create the DLL
> libplplo
Alan W. Irwin wrote:
>Try it now (after revision 8862). What I did was make a local copy of
>CMakeFortranInformation.cmake modified (I hope) to allow what you want
>(check for Fortran platform files in ${CMAKE_MODULE_PATH}/Platform). I
>have checked (with temporary message commands) that
>cmake/
On 2008-10-08 09:01+0200 Arjen Markus wrote:
> Alan W. Irwin wrote:
>
>>
>> Hi Arjen:
>>
>> Assuming I understand the naming conventions properly, I think you
>> just need
>> another Platform file called Windows-GNU-Fortran.cmake with the
>> appropriate
>> gfortran flags corresponding to the equiv
Alan W. Irwin wrote:
>
> Hi Arjen:
>
> Assuming I understand the naming conventions properly, I think you
> just need
> another Platform file called Windows-GNU-Fortran.cmake with the
> appropriate
> gfortran flags corresponding to the equivalent C flags in
> Windows-gcc.cmake.
> The location f
Alan W. Irwin wrote:
> On 2008-10-06 09:29+0200 Arjen Markus wrote:
>
>> Alan W. Irwin wrote:
>>
>>> On 2008-10-02 22:04+0200 Arjen Markus wrote:
>>>
>>>
Hello,
I am picking up the issue of gfortran 4.3.2 under MinGW again.
I have modified the source code (the import/export stu
Alan W. Irwin wrote:
On 2008-10-02 22:04+0200 Arjen Markus wrote:
Hello,
I am picking up the issue of gfortran 4.3.2 under MinGW again.
I have modified the source code (the import/export stuff) so
that the libraries are created appropriately, but while
building the examples, I run into the
On 2008-10-02 22:04+0200 Arjen Markus wrote:
> Hello,
>
> I am picking up the issue of gfortran 4.3.2 under MinGW again.
> I have modified the source code (the import/export stuff) so
> that the libraries are created appropriately, but while
> building the examples, I run into the problem that the
> On 2008-10-02 22:04+0200 Arjen Markus wrote:
>
>> Hello,
>>
>> I am picking up the issue of gfortran 4.3.2 under MinGW again.
>> I have modified the source code (the import/export stuff) so
>> that the libraries are created appropriately, but while
>> building the examples, I run into the problem
Hello,
I am picking up the issue of gfortran 4.3.2 under MinGW again.
I have modified the source code (the import/export stuff) so
that the libraries are created appropriately, but while
building the examples, I run into the problem that the file
"libplplotf77d.dll.a" is not found (there is a file
25 matches
Mail list logo
