Subject: [FEniCS-dev] FEniCS 0.1.0-pre2

From: Anders Logg <[email-masked]>
Date: Mon, 18 Sep 2006 18:18:38 +0200

Please try the new package:

    http://www.fenics.org/pub/software/fenics/v0.1/

Unpack the file, run ./install and type 'source fenics.setup'.

Then go to demo/dolfin/pde/poisson and type 'make'.

If this works, then run the program by './dolfin-poisson' and plot
the solution with 'python plot.py'.

This new version has been built with apg++ from autopackage which
could solve some problems. It has not been double compiled with
support for old g++ versions so you need a reasonably fresh g++
install.

Does it work for anyone?

/Anders

md5sum: 66d7b40f9dc8f5ed626019e7bbb4cb04

---

From: "tomtzigt" <[email-masked]>
Date: Mon, 18 Sep 2006 14:02:56 -0400

Still the same problem with respect to the format of the binaries. Is there
a command line tool that we can use to quantify the .so format on these
different machines and compiler sets?

Ignoring the old RedHat box, here is the SuSE log for the new pre2 release:

tomtzigt@tomtzigt-ws1:~/fenics/fenics-0.1.0-pre2/demo/dolfin/pde/poisson>
make
`dolfin-config --compiler` `dolfin-config --cflags` -c main.cpp
`dolfin-config --linker` -o dolfin-poisson main.o `dolfin-config --cflags`
`dolfin-config --libs`
libtool: link: warning: library
`/home/tomtzigt/fenics/fenics-0.1.0-pre2/lib/libdolfin.la' was moved.
libtool: link: warning: library
`/home/tomtzigt/fenics/fenics-0.1.0-pre2/lib/libxml2.la' was moved.
libtool: link: warning: library
`/home/tomtzigt/fenics/fenics-0.1.0-pre2/lib/libdolfin.la' was moved.
libtool: link: warning: library
`/home/tomtzigt/fenics/fenics-0.1.0-pre2/lib/libxml2.la' was moved.
/home/tomtzigt/fenics/fenics-0.1.0-pre2/lib//libdolfin.so.0: could not read
symbols: File in wrong format
collect2: ld returned 1 exit status
make: *** [dolfin-poisson] Error 1

tomtzigt@tomtzigt-ws1:~/fenics/fenics-0.1.0-pre2/demo/dolfin/pde/poisson>
gcc --version
gcc (GCC) 4.0.2 20050901 (prerelease) (SUSE Linux)

Theo

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Anders Logg
Sent: Monday, September 18, 2006 12:19 PM
To: Discussion of FEniCS development; Discussion of DOLFIN development
Subject: [FEniCS-dev] FEniCS 0.1.0-pre2

Does it work for anyone?

/Anders

md5sum: 66d7b40f9dc8f5ed626019e7bbb4cb04
_______________________________________________
FEniCS-dev mailing list
[email-masked]
http://www.fenics.org/mailman/listinfo/fenics-dev

---

From: 'Anders Logg' <[email-masked]>
Date: Mon, 18 Sep 2006 20:06:14 +0200

Is this a 686 Linux machine?

This really looks like a problem you would get if you compile on a
different architecture.

/Anders

---

From: "tomtzigt" <[email-masked]>
Date: Mon, 18 Sep 2006 14:17:08 -0400

SuSE 10 is an x86_64 target. That would explain why all the binary
distributions have a 32bit and a 64bit distribution. Ok, do you or your IT
support staff have an idea if we can fake a 32bit target on SuSE? I have to
believe you can, but I can't find anything on the either the help system or
even google for the moment (tried "running 32bit code on 64bit linux").

Theo

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of 'Anders Logg'
Sent: Monday, September 18, 2006 2:06 PM
To: [email-masked]; 'Discussion of DOLFIN development'
Subject: Re: [FEniCS-dev] FEniCS 0.1.0-pre2

/Anders

---

From: 'Anders Logg' <[email-masked]>
Date: Mon, 18 Sep 2006 20:23:54 +0200

ok, no wonder.

I'm pretty sure it has be a different build for 64bit systems. No need
to make it even more complicated since we're not even sure it works as
expected on standard 686 Linux 32bit systems.

/Anders

---

From: Mandus <[email-masked]>
Date: Mon, 18 Sep 2006 21:48:50 +0200

Hi,

you can usually fake things such that a 32bit binary can run on 64bit
linux - for instance I do that with acrobat.

It is however not so easy to build programs on a 64bit linux, either
for 64bit linux or 32bit linux, using a mixture of 32bit libs (the
fenics/dolfin libs) and 64bit libs.

I tried to install the binary fenics on my 64bit ubuntu right now. If
-m32 is added to the cflags and ldflags in the Makefile you can use
for instance the supplied libdolfin.so.0, only to get another problem
around the next corner. For instance, ncurses is usually required for
dolfin stuff, and the dev-version on your 64bit linux is probably
64bit. Hence, you end up mixing stuff, which is not good.

I think a better approach will be to create a 64bit binary version of
fenics. I guess we can replicate your scripts on my computer, Anders,
to get this.

Let's talk about it tomorrow :)

-- 
Mandus
The only dr. Mandus around.

---

From: 'Anders Logg' <[email-masked]>
Date: Tue, 19 Sep 2006 09:12:05 +0200

I don't think there is a problem building DOLFIN on 64-bit
systems. The problem here is that this is a binary distribution that I
have built on a 32-bit system and then it would be a surprise if it
worked on a 64-bit system without special tricks.

/Anders

On Mon, Sep 18, 2006 at 02:18:17PM -0500, Robert C. Kirby wrote:
> I haven't gotten into building DOLFIN on my new machine, but it is
> 64-bit Ubuntu.  I was able to build Trilinos and Sundance fairly simply
> by adding -fPIC to the C++, C, and FFLAGS in both libraries.  This was
> only required for the Python bindings to each one.  The C++ versions
> would build fine without and used about the same build scripts I used on
> a 32-bit machine (up to library & mpi locations).
> 
> This is intended as a suggestion to look at building 64-bit things in
> ubuntu if that is an option rather than suggesting some superiority of
> competitive projects.  There have been some headaches getting those
> libraries built on 64-bit red hat.
> 
> Rob Kirby
> 
> 
> On Mon, 2006-09-18 at 20:23 +0200, 'Anders Logg' wrote:
> > ok, no wonder.
> >

---

From: Anders Logg <[email-masked]>
Date: Tue, 19 Sep 2006 09:14:48 +0200

> 64bit. Hence, you end up mixing stuff, which is not good.

The distribution is built without support for curses (--disble-curses)
so that shouldn't be a problem. All other non-standard dependencies
should be included in the distribution. Currently included libraries
are Apbuild, libxml2, UMFPACK and Boost.

> Let's talk about it tomorrow :)

Yep. The build-script is available by

    hg clone http://www.fenics.org/hg/fenics

This contains the script that builds the binary distribution.

/Anders

---

From: "tomtzigt" <[email-masked]>
Date: Tue, 19 Sep 2006 08:17:14 -0400

I have been building a 64bit version of fenics for a while although with our
own environment. And for the foreseeable future I'll have to build both
versions since our workstations are all 64bit, but our cluster is 32bit and
not at the end of its life yet. Let me try that build script on SuSE and see
what happens.

Theo

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Anders Logg
Sent: Tuesday, September 19, 2006 3:15 AM
To: [email-masked]
Subject: Re: [FEniCS-dev] FEniCS 0.1.0-pre2

/Anders

---

From: Anders Logg <[email-masked]>
Date: Mon, 25 Sep 2006 18:58:20 +0200

I've updated the package: Python .pyc files are now recompiled upon
install with correct path, FFC demos are included and the install
script asks for an alternative installation directory.

/Anders

---

From: "Robert C. Kirby" <[email-masked]>
Date: Mon, 18 Sep 2006 19:17:29 -0000

Rob Kirby

-- 
Robert C. Kirby
Associate Professor
Department of Mathematics and Statistics
Texas Tech University
http://www.math.ttu.edu/~kirby

"Mathematical software should be mathematical"

---

From: "Theodore Omtzigt" <[email-masked]>
Date: Sun, 12 Nov 2006 19:24:08 -0500

With the discussion about experiments to selecting a cross-platform build
system, this whole problem of binary releases might get rolled into one and
the same effort. If there is a cross-platform build process than we'll also
need a cross-platform naming convention and QA process. I have been manually
constructing DevStudio build projects because I like native win32 processes
on Windows and if the FEniCS source management was slightly different the
build processes would simplify for all platforms (basically avoid the moving
of header files after component builds so that you can take advantage of a
single include path for compilation). However, this makes no statement about
configuration for which I know nothing but see lots of complexity in the
dolfin-config scripts. 

I still believe that there might be some use in using BuildSystem as the
configuration system for scons, or maybe the other way around, integrate the
Env functionality of scons into BuildSystem. Unfortunately, to take
advantage of the code browsing functionality of DevStudio it needs a
solution file. If this is not included in the requirements of the build
system then we'll always have a non-QAable situation in the sense that the
build descriptions to build the system might not be in sync with the build
description that would be used by some developers and vice versa. The
DevStudio IDE is amazingly productive for code comprehension: providing you
the functionality to look up definition/declaration of any symbol and macro.

In the mean time I'll continue to work on a native DevStudio project
description for FEniCS since I seem to be the only one that develops on
Windows. 

Theo

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Robert C. Kirby
Sent: Monday, September 18, 2006 3:18 PM
To: 'Anders Logg'
Cc: 'Discussion of DOLFIN development'; [email-masked]
Subject: Re: [FEniCS-dev] FEniCS 0.1.0-pre2

Rob Kirby

---

From: 'Anders Logg' <[email-masked]>
Date: Mon, 13 Nov 2006 21:48:05 +0100

> libraries built on 64-bit red hat.

Maybe you could try out the build script and see how far it takes you
on your Ubuntu-machine?

  cd fenics
  ./build-fenics

Any feedback is appreciated. In particular, the following would be
useful:

 1. How well does the pre-built package work? The latest prebuilt
 package is at http://www.fenics.org/pub/software/fenics/v0.1/

 2. How well does the script generating the build work? The build
 is generated by the build-fenics script.

Note that the build-fenics script is not supposed to be smart. It just
downloads and builds the individual packages and assumes that the
build system of each individual package is smart (which is not true).

/Anders