Home > Archive > Fortran > February 2005 > Building DLLs with Compaq Visual Fortran and Intel Visual Fortran
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Building DLLs with Compaq Visual Fortran and Intel Visual Fortran
|
|
| Evangelos Boutsianis 2005-02-02, 4:00 pm |
| Dear all,
I have lately decided to upgrade from (CVF) Compaq Visual Fortran 6.6 to
(IVF) Intel Visual Fortran 8.1
My main task is CFD where I usually built "user-subroutines" in the form of
a user.dll file which the commercial solver can use and thus implements my
models.
Up till now everything worked fine with CVF. I tried to compile and link an
already used library with IVF. I have used exactly the same compiler and
linker switches with the exception of /iface:cvf and IVF produced the dll
with no errors. However, the solver just hangs ...
I thought about checking the "contents" of the 2 dll files, which are as
follows:
(CVF)
----------------------------------------------------------------------------------------------------------------------------------------
Dump of file ubound.dll
File Type: DLL
Section contains the following exports for ubound.dll
00000000 characteristics
4200DDD4 time date stamp Wed Feb 02 15:04:04 2005
0.00 version
1 ordinal base
6 number of functions
6 number of names
ordinal hint RVA name
1 0 00009EC8 UBOUND
3 1 000094C0 UEXE
5 2 000096A2 ULIB_CHECK_VERSION
2 3 00009EC8 _UBOUND@24
4 4 000094C0 _UEXE@8
6 5 000096A2 _ULIB_CHECK_VERSION@12
Summary
1000 .data
4000 .rdata
2000 .reloc
A000 .text
-------------------------------------------------------------------------------------------------------------------------------------------
and
(IVF)
--------------------------------------------------------------------------------------------------------------------------------------------
Dump of file ubound.dll
File Type: DLL
Section contains the following exports for ubound.dll
00000000 characteristics
4200E4BA time date stamp Wed Feb 02 15:33:30 2005
0.00 version
1 ordinal base
3 number of functions
3 number of names
ordinal hint RVA name
1 0 00009D4E _UBOUND@24
2 1 0000951C _UEXE@8
3 2 000095CC _ULIB_CHECK_VERSION@12
Summary
1000 .data
1000 .data1
6000 .rdata
2000 .reloc
A000 .text
---------------------------------------------------------------------------------------------------------------------------------------
I CANNOT HELP NOTICING THE RESEMBLANCE and definately don't understand the
difference!!! However, I know nothing about dlls and have no idea how to
resolve this issue. Any suggestions would be deeply appreciated.
Vangelis
| |
| Gerald F. Thomas 2005-02-05, 8:58 am |
| Why not show the !DEC metacommands that DLLEXPORT?
On the face of it your CVF DLL has a .def and more but your IVF DLL
doesn't. What gives?
--
You're Welcome,
Gerry T.
______
"Facts are meaningless. You could use facts to prove anything that's even
remotely true." -- Homer Simpson.
"Evangelos Boutsianis" <evangelos.boutsianis@ltnt.iet.mavt.ethz.ch> wrote
in message news:42011269$1@news1.ethz.ch...
> Dear all,
>
> I have lately decided to upgrade from (CVF) Compaq Visual Fortran 6.6 to
> (IVF) Intel Visual Fortran 8.1
> My main task is CFD where I usually built "user-subroutines" in the form
of
> a user.dll file which the commercial solver can use and thus implements
my
> models.
> Up till now everything worked fine with CVF. I tried to compile and link
an
> already used library with IVF. I have used exactly the same compiler and
> linker switches with the exception of /iface:cvf and IVF produced the dll
> with no errors. However, the solver just hangs ...
> I thought about checking the "contents" of the 2 dll files, which are as
> follows:
>
> (CVF)
> -------------------------------------------------------------------------
---------------------------------------------------------------
> Dump of file ubound.dll
>
> File Type: DLL
>
> Section contains the following exports for ubound.dll
>
> 00000000 characteristics
> 4200DDD4 time date stamp Wed Feb 02 15:04:04 2005
> 0.00 version
> 1 ordinal base
> 6 number of functions
> 6 number of names
>
> ordinal hint RVA name
>
> 1 0 00009EC8 UBOUND
> 3 1 000094C0 UEXE
> 5 2 000096A2 ULIB_CHECK_VERSION
> 2 3 00009EC8 _UBOUND@24
> 4 4 000094C0 _UEXE@8
> 6 5 000096A2 _ULIB_CHECK_VERSION@12
>
> Summary
>
> 1000 .data
> 4000 .rdata
> 2000 .reloc
> A000 .text
> -------------------------------------------------------------------------
------------------------------------------------------------------
> and
> (IVF)
> -------------------------------------------------------------------------
-------------------------------------------------------------------
> Dump of file ubound.dll
>
> File Type: DLL
>
> Section contains the following exports for ubound.dll
>
> 00000000 characteristics
> 4200E4BA time date stamp Wed Feb 02 15:33:30 2005
> 0.00 version
> 1 ordinal base
> 3 number of functions
> 3 number of names
>
> ordinal hint RVA name
>
> 1 0 00009D4E _UBOUND@24
> 2 1 0000951C _UEXE@8
> 3 2 000095CC _ULIB_CHECK_VERSION@12
>
> Summary
>
> 1000 .data
> 1000 .data1
> 6000 .rdata
> 2000 .reloc
> A000 .text
> -------------------------------------------------------------------------
--------------------------------------------------------------
>
> I CANNOT HELP NOTICING THE RESEMBLANCE and definately don't understand
the
> difference!!! However, I know nothing about dlls and have no idea how to
> resolve this issue. Any suggestions would be deeply appreciated.
>
> Vangelis
>
>
| |
|
| "Evangelos Boutsianis" wrote
>
> I have lately decided to upgrade from (CVF) Compaq Visual Fortran 6.6 to
> (IVF) Intel Visual Fortran 8.1
Sorry, as you have discovered to your own detriment, you have upgraded
in chronological sense only - IVF is in no way, shape or form an upgrade
from the CVF compiler.
If it still matters, dll diffs you're seeing are probably due to a
change in calling conventions - a misguided attempt to cut out their
turf from the CVF user base.
| |
| Gerald F. Thomas 2005-02-06, 3:58 am |
|
"bv" <bvoh@Xsdynamix.com> wrote in message
news:42056308.3939E629@Xsdynamix.com...
> "Evangelos Boutsianis" wrote
to[color=darkred]
>
> Sorry, as you have discovered to your own detriment, you have upgraded
> in chronological sense only - IVF is in no way, shape or form an upgrade
> from the CVF compiler.
>
> If it still matters, dll diffs you're seeing are probably due to a
> change in calling conventions - a misguided attempt to cut out their
> turf from the CVF user base.
>
Agreed: IVF is a major downgrade wrt CVF. I've previously expounded here
and on the Intel IVF forum (where they're not so naive as to dismiss user
criticisms as the outburst of one who doesn't comply with the drug-pushing
prescriptions of the c.l.f. unqualified) on IVF's inadequacies vis-a-vis
CVF and after two years of floundering, IVF has yet to measure up to the
competition, the unsupported Microsoft (Digital (Compaq) ) VF (MSVF).
Not even Microsoft would be so malicious as to change the default calling
convention between their former (sic MSVF) Fortran 90/95 and current C++
compilers. Intel did so, with apparent impunity. Well, we'll see!
It's been standard CVF support recommendation that .lib generation and
distribution be favored over the use of a .def. This is poor advise which
MSVF never promoted.
--
You're Welcome,
Gerry T.
______
"I promise there will be fewer nuclear disasters with me as your mayor
than with me as your nuclear safety inspector." Homer Simpson
| |
| Aardpig 2005-02-06, 8:57 pm |
| Gerald F. Thomas wrote:
<snip>
> It's been standard CVF support recommendation that .lib generation and
> distribution be favored over the use of a .def. This is poor advise which
> MSVF never promoted.
>
"advice", not "advise". You under-educated arse-fart.
| |
| beliavsky@aol.com 2005-02-06, 8:57 pm |
| PLEASE don't argue with Gerry Thomas. We are unable to grasp his
profound insights, and provoking further comment from him wastes his
time and ours.
"Never wrestle with a pig. You both get dirty and the pig likes it."
| |
| Evangelos Boutsianis 2005-02-06, 8:57 pm |
| Let me try to give you the information that might be missing. In both
attempts I have used the same source file that
includes the following:
SUBROUTINE ubound(bc_index, var_index, face_index, xfc, yfc, zfc)
!DEC$ ATTRIBUTES DLLEXPORT :: ubound
Should I change something here?
Vangelis
"Gerald F. Thomas" <gfthomas@sympatico.ca> wrote in message
news:U70Nd.4751$lw4.1018311@news20.bellglobal.com...
> Why not show the !DEC metacommands that DLLEXPORT?
> On the face of it your CVF DLL has a .def and more but your IVF DLL
> doesn't. What gives?
>
> --
> You're Welcome,
> Gerry T.
> ______
> "Facts are meaningless. You could use facts to prove anything that's even
> remotely true." -- Homer Simpson.
>
>
> "Evangelos Boutsianis" <evangelos.boutsianis@ltnt.iet.mavt.ethz.ch> wrote
> in message news:42011269$1@news1.ethz.ch...
> of
> my
> an
> ---------------------------------------------------------------
> ------------------------------------------------------------------
> -------------------------------------------------------------------
> --------------------------------------------------------------
> the
>
>
| |
| Aardpig 2005-02-06, 8:57 pm |
| beliavsky@aol.com wrote:
> PLEASE don't argue with Gerry Thomas. We are unable to grasp his
> profound insights, and provoking further comment from him wastes his
> time and ours.
>
> "Never wrestle with a pig. You both get dirty and the pig likes it."
>
Agreed, but sometimes you have to stand up to a bully. Just killfile me,
and I'll get on with harassing him out-of-sight.
| |
| Greg Lindahl 2005-02-06, 8:57 pm |
| In article <IPydncU8LfskN5vfRVn-1A@comcast.com>,
Aardpig <aardpig@nospam> wrote:
>Agreed, but sometimes you have to stand up to a bully.
This is just Usenet... we call them kooks. You don't have to bother.
If you do, killfiling you isn't enough, because 3rd parties will get
drawn in.
-- greg
| |
| Gerald F. Thomas 2005-02-06, 8:57 pm |
|
"Evangelos Boutsianis" <evangelos.boutsianis@ltnt.iet.mavt.ethz.ch> wrote
in message news:42069e72$1@news1.ethz.ch...
> Let me try to give you the information that might be missing. In both
> attempts I have used the same source file that
> includes the following:
>
> SUBROUTINE ubound(bc_index, var_index, face_index, xfc, yfc, zfc)
> !DEC$ ATTRIBUTES DLLEXPORT :: ubound
>
> Should I change something here?
>
Try:
SUBROUTINE ubound [STDCALL, ALIAS:'_UBOUND'] (bc_index, var_index,
face_index, xfc, yfc, zfc)
implicit none
integer(4) :: bc_index[REFERENCE], var_index[REFERENCE],
face_index[REFERENCE]
real(8) :: xfc[REFERENCE], yfc[REFERENCE], zfc[REFERENCE]
(ditto for the other exports. If any arguments are arrays, append the dims
to [REFERENCE], ie, [REFERENCE] (dims) )
Your .def file would look like:
;DEF file
LIBRARY
EXPORTS
; Function Ordinal
; -------- -------
;F95 exports
ubound @1
uxe @2
ulib_check_version @3
When you dumpbin/exports you'll see:
1 0 00009EC8 ubound
2 1 000094C0 uexe
3 2 000096A2 ulib_check_version
--
HTH,
Gerry T.
______
"Some of those writing letters to this program are slightly fictitious but
others definitely are not." -- Dick Cavett, host of The Detroit Symphony
Orchestra, PBS Radio.
| |
| Steve Lionel 2005-02-07, 4:03 pm |
| On Sun, 06 Feb 2005 00:24:31 GMT, bv <bvoh@Xsdynamix.com> wrote:
>If it still matters, dll diffs you're seeing are probably due to a
>change in calling conventions - a misguided attempt to cut out their
>turf from the CVF user base.
The change in calling conventions was to improve compatibility with "the rest
of the world". In hindsight, we should have made that change when we brought
out DVF in 1997. The STDCALL default has been nothing but a headache for us
and our customers over the years.
Nevertheless, Intel Visual Fortran offers an /iface:cvf option, which is
applied by default when you convert a project, that keeps the defaults the
same as CVF. So there should not be problems in this regard.
Steve Lionel
Software Products Division
Intel Corporation
Nashua, NH
User communities for Intel Software Development Products
http://softwareforums.intel.com/
Intel Fortran Support
http://developer.intel.com/software/products/support/
|
|
|
|
|