[niklas]

Hey all,

I've started to work on a windows/cygwin port and thought I'd share my progress.
I do not know if I will succeed or not, but one of the main obstacles so far have been to even unpack the files in a case-insensitive environment.

I've solved this with a simple python program that I've attached below.
The python tar function retains the case-sensitive filenames and it's thus possible to check for conflicts before extracting the files.
This code will put any conflicting file in a separate directory, called 'conflicts'.
The documention is also ignored.

So, at least I now have all the files there, now I just need to write a script to rename them, put them back, go through the include-statements and Make/files and correct them for the new filenames.
This problem seems easier though.

If I run into problems with pre/post-processing or LAM/MPI I will ignore them.

ctar
N

[louis]

Hi Niklas

Regarding the uncompressing of files - as far as I know there are only files connected to vector and tensor that are case sensitive? I have renamed Vector to VectorUp and Tensor to TensorUp and change the include files to reflect this.

With what compiler do you intend to compile OpenFoam? I'm using VC7 (.NET).
I'm making slowly but steadily progress busy in unraffling unresolved external symbols...

Louis

[niklas]

Hey,
wrong, run ctar to get a complete list, but here's the more important ones related to the src directory, there are some for the applications and tutorials as well,

PatchToPatchInterpolation.H
PointPatchField.C
PointPatchField.H
PrimitivePatchInterpolation.H
ProcessorTopology.H
Random.C
Vector.H
dictionary.C
dictionary.H
fvcDDt.C
fvcDDt.H
primitivePatch.H
tensor.H

gcc of course
gcc 4.0.1 compiled very nicely too.
still dont know if I shall compile paraview in cygwin or use the windows version.

N

[niklas]

...updates from the dark side.

First I want to say that
10 whoever designed windows deserves a good punch in the face.
20 goto 10

I finally got icoFoam and blockMesh up and running, so it is doable.
I have written a couple of scripts to fix all the problems, which mainly are related to the case insensitiv filenames.
I dont know if these are necessary for a non-gcc/wmake compiler, but its a must
if you want to use wmake/gcc.

I ended up renaming every .H file in FOAM after hitting a new obstacle for every new app..
For instance the files
string.H, Time.H and features.H
must be renamed since the compiler otherwise
will pickup the ones in /usr/include string.h, time.h and features.h

The cloud.H or Cloud.H must be renamed for the lagrangian stuff to build.

The [dD]ictionary.[HC] and [pP]ointPatchField.C must be renamed for wmakeLninclude to work in OpenFOAM.

using a c library (zlib) in a c++ library somehow mangles the names and I cannot get rid of the underscore problem. I solved this temporarily by adding the zlib files to the OpenFOAM library.

wmake libso does not work, since building shared libraries with undefined functions is
forbidden in cygwin/windows, hence all 'libso' is replaced with 'lib' and hence -lPstream must be added to all EXE_LIBS or simpler add the Pstream/dymmy files to OpenFOAM.

However... When running blockMesh on the cavity tuorial I get the error-message below.
I dont know why and was hoping for some feedback.

--------------------------------------------------

Default patch type set to empty


--> FOAM FATAL ERROR : Unknown polyPatch type wall

Valid polyPatch types are :

3
(
empty
cyclic
patch
)


Function: polyPatch::New(const word&, const word&, const label, const label, const label, const polyBoundaryMesh&)
in file: meshes/polyMesh/polyPatches/polyPatch/newPolyPatch.C at line: 66.

FOAM exiting


N

[hjasak]

You are indeed the Dark Lord. :-)

What happened there is that the wall patch did not register onto the run-time selection table and it cannot get picked up. The registration happens while executing static initialisation when dynamic libraries are loaded so you really are in a difficult spot.

Keep us posted,

Hrv

[henry]

That's a linkage failure, not all the patch types have been added to the lookup table. I had the same problem on OSF1 and I think my solution to the problem was either to use the GNU linker or wait for DEC to fix their linker I can't remember which it was a long time ago. I guess your problem is that you have chosen to statically link rather than dynamically link everything and the static linker does not handle all the global constuction and ordering etc. as well as the run-time linker.

[roncresswell]

How are people going with this?

I've got a suggestion to add, and a fly to throw into the ointment.

First of all, it makes more sense to take care of the case-sensitivity issues under Linux then repackage the distribution up. cygwin can be very slow compared to running the scripting tools natively (*very* slow).

On linux, go to the installation directory and type the following:

find . | sort -f | uniq -Di

This will give you a list of (in my case) 114 files or directories that only differ in case. It's quite a simple job to write a script that will rename everything and you can even use "sed" to change all occurances inside the source code to reflect the name changes.

HOWEVER,

In doing this I have the following observation: Variable names in C++ are case sensitive, and the way OpenFOAM is organized, results files are written out as a text file which is given the same name as the variable. Problem.

So when I look at my directory tree which includes the tutorial directory I notice the following case-sensitive files:-

./OpenFOAM-1.2/tutorials/Xoodles/pitzDaily/0/B
./OpenFOAM-1.2/tutorials/Xoodles/pitzDaily/0/b
./OpenFOAM-1.2/tutorials/Xoodles/pitzDaily3D/0/B
./OpenFOAM-1.2/tutorials/Xoodles/pitzDaily3D/0/b

Also, in the FoamX stuff I found lot's of things like this:-

./OpenFOAM-1.2/.OpenFOAM-1.2/apps/FoamX/dictionaries/fvSchemes/laplacian/muEffFt .cfg
./OpenFOAM-1.2/.OpenFOAM-1.2/apps/FoamX/dictionaries/fvSchemes/laplacian/muEffft .cfg
./OpenFOAM-1.2/.OpenFOAM-1.2/apps/FoamX/dictionaries/fvSolution/solvers/Alpha.cf g
./OpenFOAM-1.2/.OpenFOAM-1.2/apps/FoamX/dictionaries/fvSolution/solvers/alpha.cf g
./OpenFOAM-1.2/.OpenFOAM-1.2/apps/FoamX/dictionaries/fvSolution/solvers/B.cfg
./OpenFOAM-1.2/.OpenFOAM-1.2/apps/FoamX/dictionaries/fvSolution/solvers/b.cfg

So the whole philosophy of using directory trees as a pseudo-database might be the most challenging problem to face porting to windows

Thoughts anyone?

Ron

[niklas]

Yes,

Windows sucks, anyone telling you otherwise has been misled by the dark side.

The case insensitivity is the least of our problem.
The real problem is the compiling of dynamically shared libraries (or DLL's in Windows), and I
dont mean pseudo DLL's like they have in windows, but true .so's as used on *nix-systems.
You cannot create a DLL with an 'undefined symbol', so you have a problem compling A because it depends on B, which depends on A.

This problem is present for the the IBM/AIX as well, but there you can add a flag to linker that will fix your problem -Wl,--allow-shlib-undefined, this flag does not work under cygwin.

I've given up on this.

N

[roncresswell]

I just found the following on the MinGW web site (link is http://www.mingw.org/MinGWiki/index.php/sample%20DLL)

"if you pass the -no-undefined and --enable-runtime-pseudo-reloc options to the linker, you don't have to add dllimport or dllexport attributes to the source code that the DLL is made with ; all functions are imported/exported automatically by default, just like in unices."

Does this help get around the cyclic dependancy or just the issue with having to insert dll import and export statements?

Anybody know?

Ron

[niklas]

from:
http://sources.redhat.com/ml/cygwin/.../msg00142.html

quoting:

Windows simply doesn't allow for undefined symbols in shlibs, and there is nothing ld can do about it.

N

[niklas]

Here's a little piece of code so you see the problem.

------- myFunc.C ---------

double funky();

double myFunc()
{
return funky();
}

------- end ---------

compile it with:
g++ -c myFunc.C
and now try to build the library

g++ -shared -o libmyFunc.so myFunc.o -Wl,--out-implib,libmyFunc.a (+whatever extra flags)

to test that it works you can try to add
the lib to the executable

---- myMain.C -----
#include "iostream.h"

double myFunc();
double funky()
{
return 2.0;
}

int main()
{
double a = myFunc();
cout << "myFunc() = " << a << endl;

return 0;
}
------ end ----

compile with: g++ -c myMain.C

and link the executable and dynamic library

g++ -o myTest myMain.o -lmyFunc -L.

once you can do this you have solved the problem.

Note that it's possible to get it to work
if you make a static lib with ar.
i.e. : ar cr libmyFunc.a myFunc.o
but this will not work with foam

the -l flag in windows is also different, since
-lmyFunc will pick up the libmyFunc.a file
which just contains the symbols of the shared library.

You could also try dlltool, but I cant get it to work.
dlltool -e libmyFunc.so -l libmyFunc.a myFunc.o -D libmyFunc.so --export-all-symbols


N

[pvita]

Do not give up Niklas!

There is always a way around. Have a look at Windows vs. Unix: Linking dynamic load modules. I would like to cite just quickly from this document:

Suppose you're building two dynamic-load modules, B and C, which should share another block of code A. In Unix, you would *not* pass A.a to the linker for B.so and C.so; that would cause it to be included twice, so that B and C would each have their own copy. In Windows, building A.dll will also build A.lib. You *do* pass A.lib to the linker for B and C. A.lib does not contain code; it just contains information which will be used at runtime to access A's code.

The second possibility is just search through open projects where I found, but not reviewed, Enhanced DLL, that should address this problem.

There is just one way if I can remember. A Crystal Space 3D-engine has used its own light-weight implementation of DCOM/Cobra that is known as SCF. It is little bit overkill but who knows if it is not what OpenFOAM is looking for...

Sincerely Yours,

PV

[roncresswell]

Thanks for the code snippets Niklas. It helps to have a nice simple example to play with!

Also thanks to Petr who provided the little clue I needed to get this to work!

I have installed cross-compilers on my linux machine and can now compile win32 executables and test them using wine. I can copy over to an XP machine for "true" testing and this works. See the article http://www.linuxjournal.com/article/7128 for a summary of running a cross-compiler under linux. (I think that running mingw under cygwyn should work the same way, but I happen to have done it this way)

So, taking your files myFunc.C and myMain.C I use the following series of commands:

g++ -c myMain.C
g++ -c myFunc.C
g++ -shared -o tst.dll -Wl,--out-implib,libtstdll.a -Wl,-no-undefined -Wl,--enable-runtime-pseudo-reloc myFunc.o myMain.o
g++ -o myTest.exe myMain.o -L./ -ltstdll

testing:-

$ ./myTest.exe
myFunc() = 2
$ rm *.dll
$ ./myTest.exe
err:module:import_dll Library tst.dll (which is needed by L"Z:\home\ronc\development\dll_testing\newtest\tmp \myTest.exe") not found
err:module:LdrInitializeThunk Main exe initialization for L"Z:\home\ronc\development\dll_testing\newtest\tmp \myTest.exe" failed, status c0000135

So it works and it's definitely loading the dll at runtime! And it behaves the same when copied to an XP machine too. No import/export statements added to the code or anything.

By the way - an added bonus - if this is compiled under Linux using a cross-compiler we shouldn't even have to change the naming convention, although a renaming of .C --> .cpp and .H --> .hh would just seem sensible

Ron

[niklas]

Hi,

I dont want to rain on your parade
but try to solve it without using Linux.

I dont have any access to a linux machine atm and
need a 'pure' windows solution.

Although this will allow people to run it in windows, it will still not let them develop/compile in windows.

If you want you can have my scripts.
Here's the order in which to run them.

1. ctar - extracts the files and places conflicting names in a separate dir 'conflict' and
write the conflicts to the file conflictingNames
ctar

2. renameAndFilter - move back conflicts to the OpenFOAM-dir and prepends win to the filename and
change the include's
renameAndFilter

3. ofrenam2 - solves the cloud.H/Cloud.H conflict.
ofrename2

4. rename all .H files and prepends OF to the filenames and changes the include's
allHRename

A bit (a lot) dirty, but it works.

N
N

[roncresswell]

Niklas,

the solution works fine without Linux - mingw behaves the same whether it's run as a cross-compiler or on a windows machine under cygwin. I've just done it on my (Windows XP) laptop under cygwin and it works.

So that's how to build the dll's but that's the only issue I've addressed so far. The file renaming should be an easy one - although made much easier if you can do it on Linux first of course - you've had to do it the hard way! I've no idea whether the dll-building will address the cyclic dependancy issue that people have been talking about.

Ron

[niklas]

Hmmm, my version of mingw does not work that way,
which version are you using?

[roncresswell]

I'm using 3.4.4 - at least if i issue a "gcc --version" or a "g++ --version" command they both return something like "3.4.4 (cygming special)"

What version are you running?

Oh and my linker is 2.16.91 too.

Cheers

Ron

[pvita]

Greetings Niklas!

I have taken a look on your example with myFunc.cpp and myMain.cpp as you wanted a pure Windows solution. I used MSVC++ .NET, my main compiler at this moment, to get it to work. Based on my small test I strongly suggest you to adopt some gcc or g++ port for Windows or cross-compiling, as these are no risk to ones mental-health.

To get your example to run I had to modify it slightly to conform with Microsoft language extension, that is, surprise surprise, Microsoft specific.

myFunc.cpp:

__declspec(dllimport) double funky();

__declspec(dllexport) double myFunc()
{
**return funky();
}


myMain.cpp:

#include <iostream>

using namespace std;

__declspec(dllimport) double myFunc();

__declspec(dllexport) double funky()
{
**return 2.0;
}

int main()
{
**cout << "myFunc() = " << myFunc() << endl;
**return 0;
}


As you see, you have to inform compiler that some code is going to be exported/imported through a dll-mechanism. I find a fact, that myMain.cpp should be an executable and not a dll-file little bit piquant, but it doesn't matter. Having this modification we can start with a compilation. The compilation of this code is not trivial as it have to proceed in a three steps:

Step 1: First of all we have to compile myFunc.cpp to an import library. To do this, create a static library project. This project contains just the file myFunc.cpp. Add a custom command line option /DEF to librarian in project properties. Using this we will force librarian to produce output files myFunc.lib and myFunc.exp. Important is to note that myFunc.lib is an import library what differs from a static library!

Step 2: Now comes compilation and linkage of a myMain.cpp to get our application. Create an standard console project that have to be dependent on the project from step 1 and add the file myMain.cpp. This will be already enough to get myMain.exe. Unfortunately we need to get somehow myFunc.dll yet and therefore we need to construct an import library of our executable as well. To accomplish it, one has to force linker to produce our wished myMain.lib import library. Go into project properties and set value $(OutDir)/$(TargetName).lib to a key Linker\Advanced\Import Library. Build project and you should get files myMain.exe, myMain.lib and myMain.exp.

Step 3: Finally we are comming to a creation of myFunc.dll. Create a standard dll-project that depends on the project from the step 2 and add the file myFunc.cpp. Add an additional dependency on myMain.lib under Linker\Input\Additional Dependencies. Compile and cheer! We have a myMain.exe and myFunc.dll. You can copy them to some test directory and launch them to see they are working. You can delete dll-file to check that myMain.exe is really loading it...

You can have a look inside an attached file linkage.zip with a MSVC++ .NET solution, projects and sources so you can play with already working version.

linkage.zip

For further information about Microsoft world you should take a look on the MSDN and look up these topics:

Mutual Imports in DLLs
DLL Import and Export Functions
Linking implicitly
Determining Which Exporting Method to Use

And moral? Using MSVC++ you have to wrap all methods with some DLLEXPORT/DLLEXPORT macros that are empty under Linux and filled with a Microsoft code under Windows and to set up fake projects for every dll-file to get OpenFOAM working.

Sincerely Yours,

PV

[pvita]

Hi Ron!

I have tried the way you have mentioned in your posting from December 1st, 2005 at 03:36 pm in my old Cygwin installation with g++/gcc version 3.2 200220927 (prerelease) yet. No problems at all, everything works without any changes. I suppose that nobody should have problems with compilation under Windows now.

Sincerely Yours,

PV

[roncresswell]

Hi Petr,

Glad to see it worked for you too. It was your clue about the difference between .so libraries and .dll libraries that made the difference. You'll notice that I included MyMain.o in the line that creates the dll, which seems a bit strange but seems to work.

Now we just have to figure out how to change the FOAM wmake files to build dll's instead of .so's

Any takers?

Ron