compiling stripack.f90

[markcmiller86]

Date: Wed, 02 Dec 2020 04:54:26 -0800
From: cessenat at free.fr (Olivier Cessenat)
This post was imported from the [email protected] email archive

---

Dear VisIt developers,

I would like to use the full featured 'FFP' database plugin on Windows,
i.e. with stripack.

I do not have Visual Studio 2017 but gfortran 6.3.0. It is Windows 10
Entreprise 64 bits.

VisIt 3.1.2 is installed.

I compiled stripack.f90 to make a libstripack.ddl with

gfortran -fdefault-real-8 -fdefault-double-8 -shared -fPIC -o
libstripack.dll stripack.f

and configured the env variable VISIT_FFP_STRIPACK_PATH to
C: Users myname libstripack.dll

but it does not work.

Is there a way to do it ? [I feel Google should tell but I didn't find]

Further, is there a way to build a user database plugin (I've got one
that also uses Fortran) against an installed version of VisIt but with
GNU tools, not Visual Studio ?

Thanks a lot,

Olivier Cessenat.

---

[markcmiller86]

Date: Wed, 02 Dec 2020 13:38:49 -0800
From: biagas2 at llnl.gov (Biagas, Kathleen)
This post was imported from the [email protected] email archive

---

Hello Olivier,

Have you tried setting VISIT_FFP_STRIPACK_PATH environment var to only include the path, (without
the libstripack.dll)?

I don't know about using gnu tools to build a plugin against a windows-installed version, AFAIK this
has never been tested.  You could give it  a try simply by running (from the dir where your plugin
exists)
path to visit.exe -xml2cmake -clobber yourdb.xml
Then run cmake and make(?) using your gnu tools.

Kathleen

-----Original Message-----
From: Olivier Cessenat via visit-developers <visit-developers at elist.ornl.gov>
Sent: Wednesday, December 2, 2020 4:54 AM
To: visit-developers <visit-developers at elist.ornl.gov>
Cc: Olivier Cessenat <cessenat at free.fr>
Subject: [visit-developers] [EXTERNAL] Compiling stripack.f90

Dear VisIt developers,

I would like to use the full featured 'FFP' database plugin on Windows, i.e. with stripack.

I do not have Visual Studio 2017 but gfortran 6.3.0. It is Windows 10 Entreprise 64 bits.

VisIt 3.1.2 is installed.

I compiled stripack.f90 to make a libstripack.ddl with

gfortran -fdefault-real-8 -fdefault-double-8 -shared -fPIC -o libstripack.dll stripack.f

and configured the env variable VISIT_FFP_STRIPACK_PATH to C: Users myname libstripack.dll

but it does not work.

Is there a way to do it ? [I feel Google should tell but I didn't find]

Further, is there a way to build a user database plugin (I've got one that also uses Fortran)
against an installed version of VisIt but with GNU tools, not Visual Studio ?

Thanks a lot,

Olivier Cessenat.

---

[markcmiller86]

Date: Wed, 02 Dec 2020 13:56:15 -0800
From: miller86 at llnl.gov (Miller, Mark C.)
This post was imported from the [email protected] email archive

---

Good catch Kathleen. Yes, specify path to *dir* containining the shared lib not the shared lib
itself.

Though I guess the coding could support either.

Mark

'Biagas, Kathleen via visit-developers' wrote:

Have you tried setting VISIT_FFP_STRIPACK_PATH environment var to only include the path, (without
the libstripack.dll)?

URL: <https://elist.ornl.gov/mailman/private/visit-
developers/attachments/20201202/8182f83e/attachment.htm>

---

[markcmiller86]

Date: Wed, 02 Dec 2020 18:26:32 -0800
From: miller86 at llnl.gov (Miller, Mark C.)
This post was imported from the [email protected] email archive

---

Well, once again I am wrong about this.

That env. variable is NOT the same as something like LD_LIBRARY_PATH where it is the *dirs*
containing the libraries to load.

VISIT_FFP_STRIPACK_PATH is supposed to be the path to the actual file, not the directory containing
it.

So, I believe Olivier was using it correctly.

That said, Kathleen do you know of an env. variable on Windows that plays the same role as
LD_LIBRARY_PATH does on Linux? If so, another thing Olivier could try is to set that variable with
the path to the *dir* containing the lib and see if he gets correct behavior?

The logic in the plugin trys a few things. VISIT_FFP_STRIPACK_PATH env. var is only the first.

A final thought...I notice we?re init?ing libstripack on both engine and mdserver. Or, basically any
component that loads the plugin because it happens as part of an initialization of a file scope
static variable. I can?t tell from examining the code but its possible we could get by with doing it
*only* on the engine. That would make things more robust.

Mark

'Miller, Mark C.' wrote:

Good catch Kathleen. Yes, specify path to *dir* containining the shared lib not the shared lib
itself.

Though I guess the coding could support either.

Mark

'Biagas, Kathleen via visit-developers' wrote:

Have you tried setting VISIT_FFP_STRIPACK_PATH environment var to only include the path, (without
the libstripack.dll)?

URL: <https://elist.ornl.gov/mailman/private/visit-
developers/attachments/20201203/80b490f6/attachment.htm>

---

[markcmiller86]

Date: Wed, 02 Dec 2020 23:19:20 -0800
From: cessenat at free.fr (Olivier Cessenat)
This post was imported from the [email protected] email archive

---

Good morning everybody,

Kathleen, I do not have access to VisIt directories, I do not have admin
rights.

Is there a private mechanism such as on Linux or Mac with a .visit dir ?

I ran 'visit -xml2cmake -private -clobber unv.xml' smoothly but,

well unfortunately, cmake is not installed on this PC and I was asked
for admin rights to install it, so I failed to install it and thus
failed to go any further.

[I could install gfortran without admin rights]

Now, just for the FFP plugin, Mark, you're right, the mdserver assumes
the engine shall be able to do it's job ; only the engine needs the
libstripack.

Well, if I cannot load a single lib, I'm afraid I shall not ever be able
to load a complete plugin ; being the first to do something is often
worrying...

Thanks for your help, sorry to have a flawed OS.

Olivier

Le 03/12/2020 ? 03:26, Miller, Mark C. a ?crit?:
>
> Well, once again I am wrong about this.
>
> That env. variable is NOT the same as something like LD_LIBRARY_PATH
> where it is the **dirs** containing the libraries to load.
>
> VISIT_FFP_STRIPACK_PATH is supposed to be the path to the actual file,
> not the directory containing it.
>
> So, I believe Olivier was using it correctly.
>
> That said, Kathleen do you know of an env. variable on Windows that
> plays the same role as LD_LIBRARY_PATH does on Linux? If so, another
> thing Olivier could try is to set that variable with the path to the
> **dir** containing the lib and see if he gets correct behavior?
>
> The logic in the plugin trys a few things. VISIT_FFP_STRIPACK_PATH
> env. var is only the first.
>
> A final thought...I notice we?re init?ing libstripack on both engine
> and mdserver. Or, basically any component that loads the plugin
> because it happens as part of an initialization of a file scope static
> variable. I can?t tell from examining the code but its possible we
> could get by with doing it **only** on the engine. That would make
> things more robust.
>
> Mark
>
> 'Miller, Mark C.' wrote:
>
> Good catch Kathleen. Yes, specify path to **dir** containining the
> shared lib not the shared lib itself.
>
> Though I guess the coding could support either.
>
> Mark
>
> 'Biagas, Kathleen via visit-developers' wrote:
>
> Have you tried setting VISIT_FFP_STRIPACK_PATH environment var to only
> include the path, (without the libstripack.dll)?

URL: <https://elist.ornl.gov/mailman/private/visit-
developers/attachments/20201203/f63e82ea/attachment.htm>

---

[markcmiller86]

Date: Thu, 03 Dec 2020 07:34:01 -0800
From: biagas2 at llnl.gov (Biagas, Kathleen)
This post was imported from the [email protected] email archive

---

Olivier, did you install/could you install VisIt yourself? There is the option to install it for
single-user, without admin privilieges, and it will then be installed in user-space where you have
full write access.

If you have access to UNV plugin source, you could copy the files to user-space and build it there.
If it compiles, VisIt will treat it as a private plugin and use it instead of the public one.

As for cmake, you might try building it from source and using it from the build directory.
(latest version is 3.19.1, but I?m only using 3.12.2 on Windows, and I know that works with VisIt,
so you might want to use that version, too.).

https://cmake.org/files/v3.12/cmake-3.12.2.zip

Kathleen

From: Olivier Cessenat <cessenat at free.fr>
Sent: Wednesday, December 2, 2020 11:19 PM
To: Miller, Mark C. <miller86 at llnl.gov>; VisIt Developers <visit-developers at elist.ornl.gov>
Cc: Biagas, Kathleen <biagas2 at llnl.gov>
Subject: Re: [visit-developers] [EXTERNAL] Compiling stripack.f90

Good morning everybody,

Kathleen, I do not have access to VisIt directories, I do not have admin rights.

Is there a private mechanism such as on Linux or Mac with a .visit dir ?

I ran 'visit -xml2cmake -private -clobber unv.xml' smoothly but,

well unfortunately, cmake is not installed on this PC and I was asked for admin rights to install
it, so I failed to install it and thus failed to go any further.

[I could install gfortran without admin rights]

Now, just for the FFP plugin, Mark, you're right, the mdserver assumes the engine shall be able to
do it's job ; only the engine needs the libstripack.

Well, if I cannot load a single lib, I'm afraid I shall not ever be able to load a complete plugin ;
being the first to do something is often worrying...

Thanks for your help, sorry to have a flawed OS.

Olivier

Le 03/12/2020 ? 03:26, Miller, Mark C. a ?crit :
Well, once again I am wrong about this.

That env. variable is NOT the same as something like LD_LIBRARY_PATH where it is the *dirs*
containing the libraries to load.

VISIT_FFP_STRIPACK_PATH is supposed to be the path to the actual file, not the directory containing
it.

So, I believe Olivier was using it correctly.

That said, Kathleen do you know of an env. variable on Windows that plays the same role as
LD_LIBRARY_PATH does on Linux? If so, another thing Olivier could try is to set that variable with
the path to the *dir* containing the lib and see if he gets correct behavior?

The logic in the plugin trys a few things. VISIT_FFP_STRIPACK_PATH env. var is only the first.

A final thought...I notice we?re init?ing libstripack on both engine and mdserver. Or, basically any
component that loads the plugin because it happens as part of an initialization of a file scope
static variable. I can?t tell from examining the code but its possible we could get by with doing it
*only* on the engine. That would make things more robust.

Mark

'Miller, Mark C.' wrote:

Good catch Kathleen. Yes, specify path to *dir* containining the shared lib not the shared lib
itself.

Though I guess the coding could support either.

Mark

'Biagas, Kathleen via visit-developers' wrote:

Have you tried setting VISIT_FFP_STRIPACK_PATH environment var to only include the path, (without
the libstripack.dll)?

URL: <https://elist.ornl.gov/mailman/private/visit-
developers/attachments/20201203/a1dd7c38/attachment.htm>

---

[markcmiller86]

Date: Thu, 03 Dec 2020 07:44:16 -0800
From: biagas2 at llnl.gov (Biagas, Kathleen)
This post was imported from the [email protected] email archive

---

Mark, since LoadLibrary wants the full path to the DLL, and it isn?t working, using LD_LIBRARY_PATH-
like env var won?t help. Something went wrong with the loading.
We should retrieve the generated error message when LoadLibrary fails and print it to the debug
logs.

Kathleen

From: Miller, Mark C. <miller86 at llnl.gov>
Sent: Wednesday, December 2, 2020 6:27 PM
To: VisIt Developers <visit-developers at elist.ornl.gov>
Cc: Biagas, Kathleen <biagas2 at llnl.gov>; Olivier Cessenat <cessenat at free.fr>
Subject: Re: [visit-developers] [EXTERNAL] Compiling stripack.f90

Well, once again I am wrong about this.

That env. variable is NOT the same as something like LD_LIBRARY_PATH where it is the *dirs*
containing the libraries to load.

VISIT_FFP_STRIPACK_PATH is supposed to be the path to the actual file, not the directory containing
it.

So, I believe Olivier was using it correctly.

That said, Kathleen do you know of an env. variable on Windows that plays the same role as
LD_LIBRARY_PATH does on Linux? If so, another thing Olivier could try is to set that variable with
the path to the *dir* containing the lib and see if he gets correct behavior?

The logic in the plugin trys a few things. VISIT_FFP_STRIPACK_PATH env. var is only the first.

A final thought...I notice we?re init?ing libstripack on both engine and mdserver. Or, basically any
component that loads the plugin because it happens as part of an initialization of a file scope
static variable. I can?t tell from examining the code but its possible we could get by with doing it
*only* on the engine. That would make things more robust.

Mark

'Miller, Mark C.' wrote:

Good catch Kathleen. Yes, specify path to *dir* containining the shared lib not the shared lib
itself.

Though I guess the coding could support either.

Mark

'Biagas, Kathleen via visit-developers' wrote:

Have you tried setting VISIT_FFP_STRIPACK_PATH environment var to only include the path, (without
the libstripack.dll)?

URL: <https://elist.ornl.gov/mailman/private/visit-
developers/attachments/20201203/093b1512/attachment.htm>

---

[markcmiller86]

Date: Thu, 03 Dec 2020 09:16:40 -0800
From: cessenat at free.fr (Olivier Cessenat)
This post was imported from the [email protected] email archive

---

Hi Kaathleen,

I failed to install VisIt myself with some windows popups telling me
they shall delete my visit3.1.4_x64.exe [what a wonderful world]...

For cmake I have two problems.

First one is : cmake complains about some files, but it continues, so is
this simply a warning ?

Second one is : it complains not to find the compiler - I have gcc and
g++ installed from MinGW for Win64 and not Visual Studio.

Here is the output:

<<

C: Users myname Downloads unv>cmake .

CMake Error at CMakeLists.txt:4 (INCLUDE):

? INCLUDE could not find load file:

? ? C:/Program Files/LLNL/VisIt 3.1.2/include/PluginVsInstall.cmake

CMake Error at CMakeLists.txt:5 (INCLUDE):

? INCLUDE could not find load file:

? ? C:/Program Files/LLNL/VisIt
3.1.2/include/VisItLibraryDependencies.cmake

-- The C compiler identification is unknown

-- The CXX compiler identification is unknown

CMake Error at CMakeLists.txt:7 (PROJECT):

? The CMAKE_C_COMPILER:

? ? cl

? is not a full path and was not found in the PATH.

? To use the NMake generator with Visual C++, cmake must be run from a
shell

? that can use the compiler cl from the command line.? This environment is

? unable to invoke the cl compiler.? To fix this problem, run cmake
from the

? Visual Studio Command Prompt (vcvarsall.bat).

? Tell CMake where to find the compiler by setting either the environment

? variable 'CC' or the CMake cache entry CMAKE_C_COMPILER to the full
path to

? the compiler, or to the compiler name if it is in the PATH.

... and bla bla bla ...

?>>

Le 03/12/2020 ? 16:34, Biagas, Kathleen a ?crit?:
>
> Olivier, did you install/could you install VisIt yourself? There is
> the option to install it for single-user, without admin privilieges,
> and it will then be installed in user-space where you have full write
> access.
>
> If you have access to UNV plugin source, you could copy the files to
> user-space and build it there. If it compiles, VisIt will treat it as
> a private plugin and use it instead of the public one.
>
> As for cmake, you might try building it from source and using it from
> the build directory.
>
> (latest version is 3.19.1, but I?m only using 3.12.2 on Windows, and I
> know that works with VisIt, so you might want to use that version, too.).
>
> https://cmake.org/files/v3.12/cmake-3.12.2.zip
>
> Kathleen
>
> *From:* Olivier Cessenat <cessenat at free.fr>
> *Sent:* Wednesday, December 2, 2020 11:19 PM
> *To:* Miller, Mark C. <miller86 at llnl.gov>; VisIt Developers
> <visit-developers at elist.ornl.gov>
> *Cc:* Biagas, Kathleen <biagas2 at llnl.gov>
> *Subject:* Re: [visit-developers] [EXTERNAL] Compiling stripack.f90
>
> Good morning everybody,
>
> Kathleen, I do not have access to VisIt directories, I do not have
> admin rights.
>
> Is there a private mechanism such as on Linux or Mac with a .visit dir ?
>
> I ran 'visit -xml2cmake -private -clobber unv.xml' smoothly but,
>
> well unfortunately, cmake is not installed on this PC and I was asked
> for admin rights to install it, so I failed to install it and thus
> failed to go any further.
>
> [I could install gfortran without admin rights]
>
> Now, just for the FFP plugin, Mark, you're right, the mdserver assumes
> the engine shall be able to do it's job ; only the engine needs the
> libstripack.
>
> Well, if I cannot load a single lib, I'm afraid I shall not ever be
> able to load a complete plugin ; being the first to do something is
> often worrying...
>
> Thanks for your help, sorry to have a flawed OS.
>
> Olivier
>
> Le 03/12/2020 ? 03:26, Miller, Mark C. a ?crit?:
>
>     Well, once again I am wrong about this.
>
>     That env. variable is NOT the same as something like
>     LD_LIBRARY_PATH where it is the **dirs** containing the libraries
>     to load.
>
>     VISIT_FFP_STRIPACK_PATH is supposed to be the path to the actual
>     file, not the directory containing it.
>
>     So, I believe Olivier was using it correctly.
>
>     That said, Kathleen do you know of an env. variable on Windows
>     that plays the same role as LD_LIBRARY_PATH does on Linux? If so,
>     another thing Olivier could try is to set that variable with the
>     path to the **dir** containing the lib and see if he gets correct
>     behavior?
>
>     The logic in the plugin trys a few things. VISIT_FFP_STRIPACK_PATH
>     env. var is only the first.
>
>     A final thought...I notice we?re init?ing libstripack on both
>     engine and mdserver. Or, basically any component that loads the
>     plugin because it happens as part of an initialization of a file
>     scope static variable. I can?t tell from examining the code but
>     its possible we could get by with doing it **only** on the engine.
>     That would make things more robust.
>
>     Mark
>
>     'Miller, Mark C.' wrote:
>
>     Good catch Kathleen. Yes, specify path to **dir** containining the
>     shared lib not the shared lib itself.
>
>     Though I guess the coding could support either.
>
>     Mark
>
>     'Biagas, Kathleen via visit-developers' wrote:
>
>     Have you tried setting VISIT_FFP_STRIPACK_PATH environment var to
>     only include the path, (without the libstripack.dll)?

URL: <https://elist.ornl.gov/mailman/private/visit-
developers/attachments/20201203/673dc1a8/attachment.htm>

---

[markcmiller86]

Date: Thu, 03 Dec 2020 09:16:47 -0800
From: cessenat at free.fr (Olivier Cessenat)
This post was imported from the [email protected] email archive

---

I ran visit -debug 5 -o mksn10.ffp but did not finc the vlog files.

Le 03/12/2020 ? 16:44, Biagas, Kathleen a ?crit?:
>
> Mark, since LoadLibrary wants the full path to the DLL, and it isn?t
> working, using LD_LIBRARY_PATH-like env var won?t help. Something went
> wrong with the loading.
>
> We should retrieve the generated error message when LoadLibrary fails
> and print it to the debug logs.
>
> Kathleen
>
> *From:* Miller, Mark C. <miller86 at llnl.gov>
> *Sent:* Wednesday, December 2, 2020 6:27 PM
> *To:* VisIt Developers <visit-developers at elist.ornl.gov>
> *Cc:* Biagas, Kathleen <biagas2 at llnl.gov>; Olivier Cessenat
> <cessenat at free.fr>
> *Subject:* Re: [visit-developers] [EXTERNAL] Compiling stripack.f90
>
> Well, once again I am wrong about this.
>
> That env. variable is NOT the same as something like LD_LIBRARY_PATH
> where it is the **dirs** containing the libraries to load.
>
> VISIT_FFP_STRIPACK_PATH is supposed to be the path to the actual file,
> not the directory containing it.
>
> So, I believe Olivier was using it correctly.
>
> That said, Kathleen do you know of an env. variable on Windows that
> plays the same role as LD_LIBRARY_PATH does on Linux? If so, another
> thing Olivier could try is to set that variable with the path to the
> **dir** containing the lib and see if he gets correct behavior?
>
> The logic in the plugin trys a few things. VISIT_FFP_STRIPACK_PATH
> env. var is only the first.
>
> A final thought...I notice we?re init?ing libstripack on both engine
> and mdserver. Or, basically any component that loads the plugin
> because it happens as part of an initialization of a file scope static
> variable. I can?t tell from examining the code but its possible we
> could get by with doing it **only** on the engine. That would make
> things more robust.
>
> Mark
>
> 'Miller, Mark C.' wrote:
>
> Good catch Kathleen. Yes, specify path to **dir** containining the
> shared lib not the shared lib itself.
>
> Though I guess the coding could support either.
>
> Mark
>
> 'Biagas, Kathleen via visit-developers' wrote:
>
> Have you tried setting VISIT_FFP_STRIPACK_PATH environment var to only
> include the path, (without the libstripack.dll)?

URL: <https://elist.ornl.gov/mailman/private/visit-
developers/attachments/20201203/0c166511/attachment.htm>

---