Here's a problem. You can't have circular dependency through shared object linking. This would be impossible to build. When I check my version, src/triSurface/Make/options does not call for linking to meshTools. Why does yours?

I don't know. Here is my file:

Looks like you downloaded a broken version. I've emailed Hrv to let him know. All the changes listed here are suspect:

http://openfoam-extend.git.sourcefor...a38695618ae72a

At the very least, you could remove the -lmeshTools from that file. If that doesn't work, go back to an older version:

git checkout b68eb75c1b4f86a5d6de1402cf81962d0ebbd766

Then make those wmake rules changes mentioned by Bruno, and the scotch changes mentioned be me... then try again.

Ok David, thank you for your kind help. I removed that line, and restarted compilation. If it is ready, I'll post the results.

Best Regards,
Attila

Hi,

I compiled the modified code, but again with errors. Now it's better because I can run simulations, but I got a lot error messages. Hereby I attach the log file again. Did you receive answer from Hrv?

Attachment 9976

Regards

The first error in your log is your problem. In this case it's:

Find out why it can't find this file. If the file exists, the lnInclude directory may have been created improperly, in which case you can delete the lnInclude directories and try again. I'd sooner burn everything, go back to the version we know works, make those two changes, and compile again.

Hi,

Sorry but I don't know how to use this. Is it a branch? How can I download it, or after switching to this branch a git pull is enough?

I will start over the whole compilation.

Thank you,
Attila

Finally, I used

Is it Okay?

Regards,
Attila

I'm not sure. I'm not very strong with git. The thing you want to happen is: you want your OpenFOAM files to match those that were on 1.6-extend's repository at the commit with the number: b68eb75c1b4f86a5d6de1402cf81962d0ebbd766.

I think your clone command copied the *latest* version into a *directory* with the name b68eb... etc..

How about you start with a fresh clone of the latest version. Use the standard git clone command. Go to the directory you want it in and do this:

Now, if you type "git branch", it will tell you there's only one branch: "master". What you need to do is create a second branch... say "myCustomBranch", and make it the "older" version. This branch you will modify to work on your platform. To do this, use this command:

This was the one I was trying to articulate earlier, but got it wrong. Now if you type "git branch", it will tell you there are two branches: "master" and "myCustomBranch", and it will show that you are on "myCustomBranch".

You can switch back and forth between branches with:

We will leave master alone. This branch will be the "pristine" copy of OF. This way, if the OF-extend team comes out with some changes you really like, you can always switch to master and update it:


Anyways, back to your myCustomBranch (git checkout myCustomBranch). This one should now be the "old" version. Check that wmake/options file we were talking about... was it triSurface? See if it links to meshTools... or the other way around. I forget. If it is, then you confirmed you do have the older version. Now you can make those changes to wmake/rules, and scotch. Try to compile. If it works, you want to "save" the changes to your "myCustomBranch". Use this:

Don't worry about doing anything that might impact the actual repository - you don't have write access, so nothing you do on your end is going to affect the version everyone else sees.

Hope that helps!

I thought I'd add a comment to this thread summarizing my experiences building 1.6-ext on Ubuntu 11.10

1) Try as I might I couldn't get mesquite to build with gcc 4.6. I had to revert to gcc 4.5. Alternate versions of gcc are usually installed on Ubuntu and if not they are there. You can use the 'update-alternatives' command to switch to a different version. Here's an article explaining how: http://www.infohit.net/blog/post/alt...nd-jaunty.html

2) When I used the scotch from the ThirdParty directory (which compiled OK), the OF compilation complained about an undefined reference to 'clock_gettime'. I used the Ubuntu provided scotch, libscotch-5.1 and libscotch-dev packages to get it to build.

3) I made a symbolic link to /usr/bin/make called /usr/bin/gmake because ParMGridgen Makefile looks for gmake and not make.

4) I made the changes to the wmake rules per Dave Gaden's advice. See the diff from the 2.0.x repo: https://github.com/OpenFOAM/OpenFOAM...3e8d0e85b889d9

5) I tried once to get Paraview to compile and it complained about not finding the OpenGL libraries. I was lazy and installed the pre-built one from Kitware and told OpenFOAM to use the system installed version.

Of course, it goes without saying that even within 11.10, YMMV.

A general comment regarding the use of ThirdParty provided packages, I think you can use the Ubuntu (i.e. system) provided packages for all but mesquite and libccmio - all the rest are in the Ubuntu repos. As the Ubuntu repos tends to be a little newer and comprehensive than, say, RedHat and its derivatives, I might be inclined to use the system provided packages where possible.

Yes, the third party packages are a nightmare with GCC 4.6. I forget the details, but getting them to build required me to edit some of the source files... it was inelegant. I never did more than add a #include at the top of some of the files, mind you.

The problem you describe in #2 is solved by adding -lrt to one of the Make/options in OpenFOAM... I forget which one, I describe it earlier in this thread. Your solution to #3 is far more elegant than mine... I like it! I usually edit the make file to force it to call make.

The guys at fedora were looking into packaging OpenFOAM, but the third party library was deemed totally unacceptable. We would have to package each one seperately, and then call them prerequisites.

Yes, I started down that path and gave up after modifying the first few.

I missed the scotch solution, thx.

I was actually more surprised that Ubuntu didn't have a gmake link by default.

I can understand their position. ThirdParty dependencies have always been a pain in either the vanilla OF or the extend version.

With Martin already going to the effort of using RPM to install and manage the ThirdParty stuff, I wonder if it would be better to just work with the distro devs (e.g. Fedora, Ubuntu) and have the ThirdParty RPMs that aren't already included with the distros repo. Some of them are a bit obscure and would likely never make it in a distros repo without someone from the OF community doing so. This way the distros would likely be more willing to provide OpenFOAM in their repos and it would make maintenance of the OF simpler as the third party stuff wouldn't need to be in the source code repos.

Thank you all! I modified everything as you suggested and switched back to gcc 4.5. Now it's compiling, I will post the results if it's ready.

I think I would write a manual to compile it. I'm working on it sine 2 weeks without any step in the real project, it's a bit annoying.

Regards,
Attila

Hi,

I'm getting errors again. I attach the log file, and also quote the lines:

Attachment 10034

The term "/usr/bin/ld: cannot find" repeats before any Error1 message.

Did you experienced the same problem?

Regards,
Attila

An other two questions:

1. should I compile first the ThirdParty package before OF16ext? Because the compiler is always looking for those files...
2. should I switch to older gcc than 4.5?

Hi, actually I don't have the InInclude directory either. Is it created by compiling the ThirdParty package?

Thanks,
Attila

You should have the lnInclude (that's lower-case L, lower-case N, upper-case i, nclude)... the directories are in the root of each library. Look at src/OpenFOAM/lnInclude; src/finiteVolume/lnInclude, etc..

As for the errors you're seeing, yeah, you need to have the third party stuff compiled. I found this the worst part of the process... and my solution was very, very ugly. But I got it to work. I'll try and remember what I did.

Go to ThirdParty directory, run ./AllMake
It will fail, but it will have downloaded all the necessary .tar.gz files to ThirdParty/rpmBuild/SOURCES. Now, when AllMake runs, it unpacks these .tar.gz files into source directories in ThirdParty/rpmBuild/BUILD. Here's the ugliest part: when something fails, you will not be editing the unpacked directory... you will be editing the tar.gz archive itself. I used the default ArchiveManager or whatever, and opened the necessary files, made the changes, saved them, then it asked if I wanted to save the archive. It was pretty easy.

I did a diff on the archives, and here's what I changed, apparently:

LIBCCMIO
I remember this package could not identify my computer platform, and its custom-written platform guesser config/config.guess, config/config.system and config/config.gnu.to.star ultimately called it "unknown". All the platforms have their own subdirectory under config/, so the script would look for config/unknown, and fail. So I chose an existing directory that sounded close enough and copied it to config/unknown.

MESQUITE
This one was easier than I thought. I edited include/Mesquite.hpp and added:

#include <stdlib.h>

to line 64.

PARMGRIDGEN
I edited /Makefile.in and changed:

# Which make to use
make = gmake

To:

# Which make to use
make = make

The rest of them compiled first try.

Hopefully this works for you!

Hello David,

thank you for your help! Now the compilation of ThirParty goes better, except paraview as we discussed before:

The first 3 stage of the compilation of ThirdParty goes perfectly, thank you very much!

I start to compile OF.

Best Regards,
Attila

Right... forgot to mention - I never did get Paraview to compile. I don't use it. I read somewhere in the forums that the fix was adding a simple include in one of the files. I think you include stddef, but I can't remember.