View previous topic :: View next topic |
Author |
Message |
dbradly
Joined: 20 Nov 2006 Posts: 31
|
Posted: Fri Jan 12, 2007 11:55 am Post subject: FTN95 v5.01 |
|
|
I have upgraded to v5.01 and trying to rebuild our software compatible for VS2005. I have a simple Win32 example which now gives an error at link time when it didn't with v4.x. I am now using /clr /clr_ver 2 when compiling and using dbk_link2.
The code has a call
type (GDIM) paper
integer i,ipapty, ndc,ndt
!
call gEnqDrawingLimits(paper,ipapty)
and an interface:
subroutine gEnqDrawingLimits(dim,type)
use gino_f77
assembly_interface(name="EnqDrawingLimits")
type (GDIM), intent(out) :: dim
integer, intent(out) :: type
real px,py
dim=new@("GinoGraphics.GDIM")
call papenq(px,py,type)
dim%xpap=px
dim%ypap=py
end subroutine
When compiling I get an error:
[DBK_LINK Ver. 2.0.0 Copyright(c) Silverfrost Ltd 2001-2006]
*** Attempt to call Void GENQDRAWINGLIMITS(GINO_F77!GDIM*, Int32*) as if it were GENQDRAWINGLIMITS(GINO_F77!GDIM*, System.Int32*)
What is the difference between Int32* and System.Int32* and how do I avoid this error? |
|
Back to top |
|
|
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 7927 Location: Salford, UK
|
Posted: Fri Jan 12, 2007 7:03 pm Post subject: |
|
|
We can take a look at this but it may take a little while because the main expert is currently on holiday.
Can you supply a complete sample so we are sure of the problem.
i.e. code we can compile without change that illustrates the problem. |
|
Back to top |
|
|
dbradly
Joined: 20 Nov 2006 Posts: 31
|
Posted: Mon Jan 15, 2007 11:12 am Post subject: |
|
|
Paul,
I have puttogether a very cut down example which shows the problem. How can I send you a zip file with the 5 files necessary? |
|
Back to top |
|
|
dbradly
Joined: 20 Nov 2006 Posts: 31
|
Posted: Thu Jan 18, 2007 12:12 pm Post subject: |
|
|
Didi you get the zip file? |
|
Back to top |
|
|
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 7927 Location: Salford, UK
|
Posted: Sat Jan 20, 2007 8:24 am Post subject: |
|
|
Yes thanks. Presumably my email reply did not get back to you. |
|
Back to top |
|
|
dbradly
Joined: 20 Nov 2006 Posts: 31
|
Posted: Mon Jan 22, 2007 5:04 pm Post subject: |
|
|
Paul,
Yes, I got your reply, but you didn't acknowledge the zip file, only metioning the /ignore switch suggestion for the other problem I had.
Have you managed to reproduce the unmatched variable types in the code I sent? |
|
Back to top |
|
|
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 7927 Location: Salford, UK
|
Posted: Mon Jan 22, 2007 6:07 pm Post subject: |
|
|
Hope to look at this tomorrow. |
|
Back to top |
|
|
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 7927 Location: Salford, UK
|
Posted: Tue Jan 23, 2007 8:24 pm Post subject: |
|
|
David
We have had a look at this but we need to do some further test which may take some time to complete.
In the meantime the problem raises two questions...
1) Do you get the same problem on your machine if you build for .NET 1.x?
2) It is necessary to build for .NET 2.0?
At the moment we have chosen to build and release ftn95lib.dll for .NET 1.x only and maybe you should do the same for your DLLs. They will still be available under .NET 2.0. The only essential reason for building a .NET 2.0 assembly is if you want to include .NET 2.0 features in your DLL, i.e. if you want to do something that cannot be done with .NET 1.x. The alternative is either to release two versions of your DLL or to require your users to upgrade to .NET 2.0. |
|
Back to top |
|
|
dbradly
Joined: 20 Nov 2006 Posts: 31
|
Posted: Fri Jan 26, 2007 4:12 pm Post subject: |
|
|
Paul,
I am somewhat confused over all the different components and versions. The reason why we bought FTN95 v 5.0 was because we understood that we needed this version to be able to build dll's which were compatible with VS 2005 (and presumably .NET 2.0). Hense we are now using the /CLR_VER 2 switch.
As you know we have written a C# interface between the dll's built with FTN95 so that GINO is accessible from all the different .NET languages, which all worked fine under VS 2003 (.NET 1.1).
I am fully expecting that we might have to supply two different version of GINO.NET, but I am not sure yet.
If that helps clarify things from our point of view, any information from your side would be helpful. |
|
Back to top |
|
|
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 7927 Location: Salford, UK
|
Posted: Sat Jan 27, 2007 2:08 pm Post subject: |
|
|
David
Just to confirm, my understanding is that you do not need to create a 2.0 release. Your 1.1 build will run OK under 2.0. You will only need to build for 1.1 if you have C# components that are not available under .NET 1.1. |
|
Back to top |
|
|
dbradly
Joined: 20 Nov 2006 Posts: 31
|
Posted: Wed Jan 31, 2007 5:04 pm Post subject: |
|
|
Paul,
No, you do not understand our situation.
We have GINO 6.5 built using FTN95 3.4 , which works under .NET 1.1 (VS2003). Unfortunately we have some users who have upgraded to .NET 2.0 (VS2005) and they report that they can no longer use our 1.1 implementation. You yourself said that the previous release of the compiler was not compatible with VS2005.
We are therefore trying to build a set of GINO dll's etc. that can be used under .NET 2.0 (VS2005) and so I am trying to build our next release using FTN95 5.01 with the /CLR_VER 2 switch which I understood we needed to get things to work in the new Microsoft Environment.
It is when we tested the new version that we get the compiler error that I reported and sent to you. I admit that the test was using a F90 test program and obviously uses F90 modules which would not be used by C#, VB users, so we will test the new implementation under VS2005 and see if it works there anyway.
I presume that the error we found is not simple to fix. |
|
Back to top |
|
|
Martin
Joined: 09 Sep 2004 Posts: 43
|
Posted: Thu Feb 01, 2007 10:31 pm Post subject: |
|
|
Hi David,
As Paul said, there should not be a problem with using a .NET 1.1 library assembly from a .NET 2.0 program assembly. The .NET 2.0 framework is backwards compatible with 1.1. The main reason I can see for building a .NET 2.0 assembly is to take advantage of the new features (e.g. new standard classes).
Do you have any more information on the problems your users are having with using your .NET 1.1 library? Have you been able to reproduce these problems yourself? If so perhaps you could upload / send us a sample of the problem so we can take a closer look at it. |
|
Back to top |
|
|
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 7927 Location: Salford, UK
|
Posted: Wed Feb 07, 2007 10:36 am Post subject: |
|
|
The original bug in this thread has now been fixed. |
|
Back to top |
|
|
|