Welcome to our forums
Paul, Will i be able to use third-party 32bit LIB files with 64bit code in the places where more then 2GB is not needed?
Dan
No, that would not work. Also it is unlikely that you will be able to use third party 64 bit static lib files, at least not at the moment.
If you need to use a third party compiler, then you will probably need to create a 64 bit DLL.
Paul,
Is it possible to post an example of building and loading/using a .dll with slink64, say with three .f95 files. (an example with SLINK also would be good) Would there be any change if one of the .f95 files also had a module ?
John
slink /dll /exportall file1.obj file2.obj file3.obj /file:mylib.dll
slink64 file1.obj file2.obj file3.obj /file mylib.dll
You can use modules but module data is only local to its own DLL or executable. Data can not be shared.
Hello Paul,
in a post of mine as of 2nd November 2015 I addressed an integer*2 problem which you told me about that it had been fixed.
Now I wonder how I would get hold of this fix. Is it a part of the Beta version addressed by the link
http://www.ftn95.co.uk/ftn95/ftn95-8.00beta/FTN95_Update_Beta.2.exe
?
Regards, Dietmar
Dietmar
It will be in any beta released after that date. I understand that a beta 3 is about to be released.
On Fri Oct 30, 2015,
Quoted from PaulLaidler
I was hoping that a DOS command like COPY would do the trick but I have tried COPY and it does not work for me.
I do not know what you exactly did, but for using the CMD.EXE COPY command with non-text files you must use the /B option. Otherwise, each file will be truncated at the first CTRL+Z (0x1A) byte (a gift to us that originated in VMS and CPM). I cannot verify this comment/suggestion because the beta release has not been made generally available.
I will have used /B. The 64 bit beta is available on request provided that you have a support licence.
In what state F64 is right now? 'When i'm 64' 😃?
When are you 64?
We are hoping the 64-bit compiler will be quite soon.
When are you 64?
We are hoping the 64-bit compiler will be quite soon.
Well, it will take some time to me to reach 64 😃
I count months from the point i expected it to be ready a year ago. Every month of delay for me like an extra tooth pain
Will the 64 bit debugger work with it too?
Well, it will take some time to me to reach 64 😃
I count months from the point i expected it to be ready a year ago. Every month of delay for me like an extra tooth pain
Will the 64 bit debugger work with it too?
There is a 64-bit debugger (a beta one I must add).
Please accelerate the release
Hope you are talking about true 64bit debugger, not the trick of scaling the task down to 32bit and use older 32bit debugger to find the error. That is totally unacceptable for me as scaling down the elephant to mosquito and then back
I have seen those elephant mosquitoes and they are impressive beasts
OK, but please do not leave from your sight while working on F64 that those are still a mosquitos, while we need the elephants 😃
one more month... one+ year delay. what the hell, Silverfrost?
Hello,
having successfully ported some small Fortran applications (with and without a GUI) from 32 bit to 64 bit, we have tried to do the same for a bigger application, too. Because there is no way to produce static libraries in the 64 bit version of the SALFORD compile environment, we decided to create an object file for every of our libraries and link against these object files.
However, we ran into several proplems where slim64.exe produced an access violation at run time. One of these problems is the following.
IMPLICIT NONE
INTEGER*2 plus
INTEGER*2 a,b,res
a=1
b=2
res=plus(a,b)
write(*,*) 'a=',a,'b=',b,'res=',res
stop
end
function plus(x,y)
integer*2 x,y
integer*2 plus
plus=x+y
return
end
We compiled sample2 successfully using command
ftn95 sample2 /ALL_WARNINGS/NON_STANDARD/SINGLE_THREADED/OLD_ARRAYS/ALT_KINDS/PERSIST/ZEROISE/UNLIMITED_ERRORS/FIXED_FORMAT/SAVE/NO_WARN73/WIDE_SOURCE /CFPP /BINARY_folder SALFORD64 /64
, we linked using command
slink64 sample2.lnk
with file sample2. lnk loading the object file twice!
Link file sample2.lnk is
lo salford64\sample2 lo salford64\sample2 file salford64\sample2.exe
This resulted in the runtime error mentioned above with error file
Runtime error from program:c:\win32app\silverfrost_ftn95-8.00_beta.14\ftn95\slink64.exe Access Violation The instruction at address 00407515 attempted to read from location 00000018
00407464 build_exception_table(<ptr>char,<ptr>char,int) [+00b1] 004026e6 build_executable(void) [+1348] 00401000 main [+0b3d]
eax=0358a304 ebx=0000167f ecx=00000000 edx=0358a370 esi=0358a328 edi=00000002 ebp=0358a340 esp=0358a304 IOPL=1 ds=002b es=002b fs=0053 gs=002b cs=0023 ss=002b flgs=00010293 [CA OP NZ NS DN NV]
00407515 mov esi,[ecx+0x18] 00407518 mov edx,[ebp+0x8] 0040751b mov [edx],esi
The link could be executed successfully if deleting one of the load object statements in the link file sample2.lnk. However, it is very strange that slink64 results in a runtime error and does **not **produce an error message like 'object loaded several times', e.g.
Moreover, when linking against libraries, in some cases we loaded special libraries several times. This forced us to filter the link files produced from our 32 build environment, creating link files where static libraries (.lib) were substituted by object files (.obj) and where there were no multiple loads. However, we then ran into the same runtime error when loading about 30 object files (being different in pairs) within slink64. And that is why we have created this entry.
We started with a link file loading several object files of the form
004026e6 build_executable(void) [+1348] 00401000 main [+0b3d]
eax=0358a304 ebx=0000167f ecx=00000000 edx=0358a370 esi=0358a328 edi=00000002 ebp=0358a340 esp=0358a304 IOPL=1 ds=002b es=002b fs=0053 gs=002b cs=0023 ss=002b flgs=00010293 [CA OP NZ NS DN NV]
00407515 mov esi,[ecx+0x18] 00407518 mov edx,[ebp+0x8] 0040751b mov [edx],esi
The link could be executed successfully if deleting one of the load object statements in the link file sample2.lnk. However, it is very strange that slink64 results in a runtime error and does **not **produce an error message like 'object loaded several times', e.g.
Moreover, when linking against libraries, in some cases we loaded special libraries several times. This forced us to filter the link files produced from our 32 build environment, creating link files where static libraries (.lib) were substituted by object files (.obj) and where there were no multiple loads. However, we then ran into the same runtime error when loading about 30 object files (being different in pairs) within slink64. And that is why we have created this entry.
We started with a link file loading several object files of the form
004026e6 build_executable(void) [+1348] 00401000 main [+0b3d]
eax=0358a304 ebx=0000167f ecx=00000000 edx=0358a370 esi=0358a328 edi=00000002 ebp=0358a340 esp=0358a304 IOPL=1 ds=002b es=002b fs=0053 gs=002b cs=0023 ss=002b flgs=00010293 [CA OP NZ NS DN NV]
00407515 mov esi,[ecx+0x18] 00407518 mov edx,[ebp+0x8] 0040751b mov [edx],esi
The link could be executed successfully if deleting one of the load object statements in the link file sample2.lnk. However, it is very strange that slink64 results in a runtime error and does **not **produce an error message like 'object loaded several times', e.g.
Moreover, when linking against libraries, in some cases we loaded special libraries several times. This forced us to filter the link files produced from our 32 build environment, creating link files where static libraries (.lib) were substituted by object files (.obj) and where there were no multiple loads. However, we then ran into the same runtime error when loading about 30 object files (being different in pairs) within slink64. And that is why we have created this entry.
We started with a link file loading several object files of the form
004026e6 build_executable(void) [+1348] 00401000 main [+0b3d]
eax=0358a304 ebx=0000167f ecx=00000000 edx=0358a370 esi=0358a328 edi=00000002 ebp=0358a340 esp=0358a304 IOPL=1 ds=002b es=002b fs=0053 gs=002b cs=0023 ss=002b flgs=00010293 [CA OP NZ NS DN NV]
00407515 mov esi,[ecx+0x18] 00407518 mov edx,[ebp+0x8] 0040751b mov [edx],esi
The link could be executed successfully if deleting one of the load object statements in the link file sample2.lnk. However, it is very strange that slink64 results in a runtime error and does **not **produce an error message like 'object loaded several times', e.g.
Moreover, when linking against libraries, in some cases we loaded special libraries several times. This forced us to filter the link files produced from our 32 build environment, creating link files where static libraries (.lib) were substituted by object files (.obj) and where there were no multiple loads. However, we then ran into the same runtime error when loading about 30 object files (being different in pairs) within slink64. And that is why we have created this entry.
We started with a link file loading several object files of the form
[quote:b752783d2a]salford64\filenname1.obj
or
[quote:b752783d2a]..\lib64\filename2.obj
. We linked successfully in the sense that the runtime error mentioned above did **not **occur. Of cource we did not succeed in creating an exe file working correctly (we sometimes could create an executable ignoring unresolved symbols; however, when executing it we ran into problems where subroutines or functions were missing). Finally we added a first object file as the last of the load statements where the runtime error mentioned above occurred. Our first idea was that this object file (say sample.obj) was corrupted. But deleting some of the other object files made the linking step **not **produce the runtime error any more although sample.obj was loaded.
We have no idea of what has gone wrong and would appreciate any hint.
We should remark that we used the beta 3 version of the salford 64 bit compile enviroment.
Regards, Dietmar
Can you check that none of the object files has zero size. There is a bug in the latest release that has now been fixed.