[niklas]

OK,

Ron:
Now I see why you got it working. You included myMain.o in the dll....not good.
The purpose with the simple case was to illustrate the problem and in openfoam it cannot be solved in that way.
You must use ONLY myFunc.o to build the dll.
You could have cheated in another way also and skipped the build of the dll and used both object files to create the executable, but thats not a solution either.

Petr.
To re-write the code by including the declspec statements is just not feasible.
This is also not necessary if you use g++ for the
compilation/linker stages.

N

[roncresswell]

Niklas,

The reason for that is that you have defined a function inside Main that is referenced from the library! That's like producing a shared object library that has a dependancy on the program that will use it. I have a very hard time believing that this is what Foam does and if it is then it looks like very poor programming to me - and I doubt very much that the developers of Foam are poor programmers!

If you want to test out the cyclic dependancy thing then you need 3 files - an executable and two shared libraries. The two shared libraries can depend on each other but NOT on definitions inside the executable.

Ron

[niklas]

Please Ron, pleeeeease.
try this on linux.
g++ -shared -o libmyFunc.so myFunc.o
(without myMain.o, thats very important)
and make sure you use a native g++ compiler.

then try the same on windows/cygwin.

You will see that in linux it works, but not under cygwin,

Why?

It has nothing to do with bad programming, or that the function in the shared library is defined in main (that doesnt matter), it has to do with the way dll's, shared object, are working in windows.

N

[pvita]

Dear Niklas!

I would suggest you follow the whole discussion once more.

Windows is bad and Linux is not the best, but they are simply different and one have to accept it to continue.

I understood, that the cyclic dependency problem you posted here, should illustrate, what you see is as an actual end point for a successful OpenFOAM Windows compilation. However, Ron with me presented two possible solutions to it, simply stating it is not a problem at all.

Windows: If you call any function from another linker object, you have to create so called import library that will help to linker to create an output. This is no problem, one have to reflect it in his makefiles only.

Linux: Because of different binding mechanism between so-files you do not need to do such a compilation step.

Solution 1: New makefile for platform win32-cygwin will be written that produce import libraries for necessery dependencies and that reflect those special dll-cases. If anybody wish to compile with MSVC++, DLLEXPORT/DLLIMPORT macros will be applied. This is a standard solution in this case! You should take a look in any open source multiplatform library sources before saying it is not feasable solution... They are using ways more macros to allow smooth compilation between different platforms.

Solution 2: Somebody will drop those cyclic dependencies that are really a poor programming, they simply show a chaotic structure, and this problem will simply vanish.

Sincerely Yours,

Petr

[niklas]

cool, Im expecting a solution any day now then.

good luck.

N

[pvita]

Hi Niklas!

I hope you are more desperate to get that OpenFOAM to work under Windows as I am. Your last posting on my harh one looks like a resignation. Hehe. I know it is not nice from me, but that it is why I used in the part Solution a passive voice.

Q1: How urgently do wee need to get that Windows port? Do you have some milestone for it?

I have my main project on the table where I have to meet a beta-version deadline till end of this year. I am not willing porting OpenFOAM at this very moment as I will be not able to manage my project timeplan. But I am willing to help.

Q2: Which from those possible solutions is more feasable for you. I guess makefile-cygwin... Any other input?

Q3: What about naming of those problematic files with case-insensitive names? Do we got any answer from OpenFOAM project leaders? What are they thinking about it? I guess a script to rename they is just a hot fix, these files should be renamed directly in repository...

Sincerely Yours,

PV

[niklas]

Dont worry, i gave up on this long before this conversion started. Im using our ibms now so I dont need windows anymore.

The solution one must come up with has to work
on the official distribution 'as is', because
any code change relevant to windows-compatibility
will not make it into the official distribution.
Henry will not help you with windows issues.. period.

So when I said its not feasible its because
i think i have some more 'behind the scenes' info than you.
I dont mean it cant be done, just that it
probably means forking and that is out of the question to me.

cyclic dependencies are extremely difficult to avoid when designing a project like openfoam, it is virtually impossibly without knowing all of the details before you start...Hence to solve this will require
code reorganization (just relevant to windows and we are back to the above issue)
and I do not agree that it is a result of poor programming, its a result of a complex problem.

Basically your solutions require aid from the core developers and you can rule that out.

The one who will solve this should know both openfoam and windows well, and I admit I
do not know windows. So it should be a fairly
advanced windows user with detailed foam knowledge and the motivation, i.e. no one I know.

The case-insensitive problem is solved, for me anyways, my scripts will work althouth it might require some fiddling, but nothing serious.

...so have I given up - yes,

at least until windows can compile shared libraries with unresolved symbols.

for me the problem is not writing macros or reorganizing the code, if i only had to do this once i could, but im thinking of future releases also. For me the problem is simply that in windows this doesnt work
'g++ -shared -o libmyFunc.so myFunc.o'

N

[pvita]

As you said, I have no that behind scene knowledge. That's pitty to hear about this. Could you or Henry say why Windows won't be supported?

But I guess if we can solve it with a special Windows platform oriented makefile, without touching the code as it is quite complex now, we can force that makefile into the distribution.

My colleague have gave me a tip to get around that naming issues without some scripts I want test it in following days. I will try to make OpenFOAM compilation through the windows-cygwin makefile though... Hope I can ask you for help if I get into some problems in OpenFOAM code...

Sincerely Yours

PV

[pvita]

That tip is a Ext2 Installable File System For Windows...

[niklas]

Henry will not support windows beacuse he dont have to - a healthy attitude I wish I could adopt myself

There's also the option to use managed mounts, but I already tested it and it doesnt work.

i.e.

'mount -o managed ...'

However, it is/was under development so it might work soon.

N

[pvita]

Hi folks!

I started to tackle compilation of the holy OpenFOAM under Windows targeting platform windows-cygwin... First try to get it unzipped without help of some script is a total defeat.

I have tried two different ext2 drivers for Windows to mount my second harddisk with ext2 filesystem hoping Cygwin can work with it without problems. Not really, touch touch.ME and touch touch.me are resulting in just one file touch.ME.

I have observed that Samba shares are reporting files in the case-sensitive manner so I tried to mount a Samba share under the Cygwin. Works, but it is, unfortunately, case-insensitive as well.

Based on my experiment I guess, Cygwin is using some Windows layer to access file system and this layer brings case-insensitivity into the game. Cygwin is simply not able to get around...

I will use that renaming scripts from Niklas for time now hoping that core developers could get rid of those filenames in comming releases.

PV

[pvita]

Ha!

Citing my

Cygwin is simply not able to get around...

I have to take my words back. I installed the latest stable Cygwin version (1.5.18) in my last outcry to test the state of managed mounts and that damn thing works. Using an example from Cygwin FAQ I got those case-sensitive filenames to work in one directory so far without any of supporting scripts.

Output of ls /managed-dir/OpenFOAM-1.2/src/OpenFOAM/lnInclude/fvc* returns:

fvc.H fvcDDt.H fvcGrad.H fvcReconstruct.H
fvcAverage.C <font color="ff0000">fvcDdt.C fvcLaplacian.C fvcSnGrad.C
fvcAverage.H fvcDdt.H fvcLaplacian.H fvcSnGrad.H
fvcCurl.C fvcDiv.C fvcMagSqrGradGrad.C fvcSurfaceIntegrate.C
fvcCurl.H fvcDiv.H fvcMagSqrGradGrad.H fvcSurfaceIntegrate.H
fvcD2dt2.C fvcFlux.C fvcMeshPhi.C fvcVolumeIntegrate.C
fvcD2dt2.H fvcFlux.H fvcMeshPhi.H fvcVolumeIntegrate.H
fvcDDt.C fvcGrad.C fvcReconstruct.C</font>

I will suppose it works and I will concentrate on wmake and OpenFOAM makefiles now.

Nice weekend!

PV

[niklas]

Yes, the unpacking works.
But just you wait, if the managed mount bugs are still there you are in for a real treat

Be warned, the can of worms has been opened.
Errors of unbelievable weirdness will hit you.

N

[niklas]

Hey Petr...
How is it coming along?

Have you reached the same place as me now, i.e. hit the wall

Would be interesting to hear what happened
when you used managed mounts.

N

[pvita]

Greetings Niklas!

Just came from ski-holidays. So far I have modified wmake to be able to process dependencies on external sources without breaking compilation for other platforms. At this moment the problem I am dealing with is a looking up all code fragments and definitions that are hidden in another libraries. Oh God it takes a time. Concerning managed mounts there is no problem at all. All the weird stuff that I come across is only OpenFOAM connected as an inclusion of C-files (#include "something.C") that are not compilable itself and such things. Hope I will finish compilation this week and issue a patch for you all.

Sincerely Yours,

PV

[niklas]

Hey,

Nice, managed mounts works alot better now I see.
No more crazyness...so far

I tried it myself and all I had to do was to modify MakefileFiles, the lines with
@wmakeDerivedFiles to @$(WM_DIR)/wmakeDerivedFiles

Still doesnt work, but atleast I dont have to rename my files

for those of you who also want to try it you can create a special dir and mount it with case-sensitivity, here's what I did.

mkdir /whatever
mount -o managed c:/cygwin/whatever /whatever

go to /whatever and tar zxfv OpenFOAM....


N

[pvita]

I will say managed mounts are the smallest pain in ass now. Troubles emerge in a case you need to compile some sources who are part of another library and they have the same name... In order to get libPstream.dll you need to compile under Cygwin sources from src/OpenFOAM/db/IOstreams/Pstreams who are going to produce the object files of the same name in one directory... Now trying to figure out how to cheat it...

PV

[pvita]

Greetings All!

Fighting over a week with OpenFOAM compilation I guess it is time for the last news from this battle. I have finished compilation of all libraries yesterday and compiled three application to be sure that executables are linking against them. Ok, I have to admit I didn't compiled library libGstream.dll yet as this one needs X server in Cygwin that I have not install yet but main point is that the whole compilation is done exclusively using extended wmake.

And now to the actual problems. I guess there are still some bugs and I would say even nasty bugs in Cygwin's managed mounts implementation that pop-up from time to time and make one's life frustrating.

1. wmakeLnInclude hangs on src/OpenFOAM/lnInclude directory
2. make is not able to find out implicit rules for thermophysicalModels/thermophysicalFunctions/NSRDSfunctions/NSRDSfunc*/*.C files
3. system names on managed mounts

ad 1. wmakeLnInclude: I have found that this scripts collaps in find while linking all headers and sources. This error can be removed through find ../* ... instead of find .. ... but only at one phase of compilation. I guess but cannot confirm that till I have a compilation patch ready that it will be not such a tragedy as this step is skiped in the absolutely first compilation of the OpenFOAM when are all symbolic links are already on their place unzipped from a source distribution.

ad 2. make and NSRDS functions: make under Cygwin is not able to find implicit rules .C.dep for some of functions. I guess it will have something to do with managed mounts. I placed in directory thermophysicalModels/thermophysicalFunctions/NSRDSfunctions symbolic links to all sources and compilation went through without problems.

ad 3. names on managed mounts: Managed mounts are working quite simple. If a filename is made of lowercases it is same, if there is any upper-case letter it is exchanged with a sequence of some sort of escape characters. The problem is that dll loading mechanism is bound to Windows system itself. Cygwin executable is simple Windows executable that needs cygwin1.dll and other application dependent to run. The loading mechanism is not case sensitive and do not works with filenames of managed mounts as those have meaning for Windows system. It means, after the compilation is done, one have to move/copy/link all OpenFOAM applications and dlls in a non-managed mount. The same applies for tutorials and anything that has something to do with running of OpenFOAM applications.

My plans for future? Compilation of all applications, a patch for you with all extensions and changes in code and files structure and test that all compiled stuff works.

Sincerely Yours,

PV

[rakue]

Concerning problems with the case-insensitive windows system:

During installation of the Windows 'Services for Unix' you get the option:
activate case sensitive file names
(or something like this)

After installation (and reboot:-) the system will handle all file names case sensitive.
You can download the SFU 3.5 from download.microsoft.com (free for registered users; approx 120 MB).

Perhaps this may help a little bit...

[eugene]

Did you activate it? What I want to know, is what will it do to your windows install? Does look promising though.

All you need to download it is a hotmail or msn account.