Subject: [Dorsal-dev] Dorsal problem building ufc: unknown python option: -j

From: Douglas N Arnold <[email-masked]>
Date: Mon, 03 Aug 2009 09:33:13 -0500

[resent because I got a nasty message that I probably sent the message 
with the wrong address]

Hi Harish:

I am using the latest development version of dorsal to build the unstable
version of FEniCS in Ubuntu jaunty.  Build of ufc failed with:

   Building ufc
   Unknown option: -j
   usage: python [option] ... [-c cmd | -m mod | file | -] [arg] ...
   Try `python -h' for more information.
   Failure with exit status: 2
   Exit message: There was a problem building ufc.

What's the cure to this one?

A simple related question.  To speed things up, when I restart dorsal, I
can remove all the packages above ufc in the package list in
jaunty.platform, correct?

Finally, in case you are interested, these are the troubles I ran into
(nothing serious):

To build SLEPc I needed git installed.  "sudo apt-get install git-core"

The build for ginac-1.5.3 failed with "No package 'cln' found".  I added
"cln" to the package list in jaunty.platform

To build cln I needed automake 1.10 installed.  The version of automake
which I had installed (1.9.6 I think) did not work.
"sudo apt-get install automake1.10"

Needed to manually accept a certificate to install mtl4 (unfortunate,
since it means one cannot run  dorsal completely unattended).

Thanks -- Doug

P.S. After this is finished I plan to try building on Fedora 10.  I'll let
you know if anything interesting comes up.

---

From: Douglas N Arnold <[email-masked]>
Date: Mon, 03 Aug 2009 09:48:01 -0500

I just noticed the list of packages I was supposed to have installed 
before running dorsal, and I installed them.  This fixed the problem below
(and undoubtedly would have fixed most of the other problems below), so 
consider this closed.  Sorry for the interuption. -- Doug

Douglas N Arnold wrote:
> _______________________________________________
> Dorsal-dev mailing list
> [email-masked]
> http://fenics.org/mailman/listinfo/dorsal-dev
>

---

From: Harish Narayanan <[email-masked]>
Date: Mon, 03 Aug 2009 16:49:24 +0200

> [resent because I got a nasty message that I probably sent the message 

(Since we last spoke about this, I have been manually monitoring all
messages the list server over zealously bounces. Your original message
was not lost to the ether this time.)

> What's the cure to this one?

To people on the list: Does anyone else see this? I have not yet seen
troubles with ufc scons being passed a -j. I am not able to reproduce it
either. Perhaps the scons version is too old (or not there).

> jaunty.platform, correct?

You can. Except, you need to replace most of the packages you remove
with variables that tell dorsal where to look for them. See
platforms/fenics.platform to see how this done. (In fact, it is easiest
just to modify the variables there for your own use.) You then call
dorsal with ./dorsal platforms/fenics.platform to build only those
specific packages, not all of them.

> To build SLEPc I needed git installed.  "sudo apt-get install git-core"

Hmm. I don't see why.
> "sudo apt-get install automake1.10"

I will change this.

> since it means one cannot run  dorsal completely unattended).

I am unsure how to work around this, though I will look into it. It
bothers me too when I forget to hit 'OK' and it gives up trying to fetch
mtl4.

> you know if anything interesting comes up.

Before you do, look at the following thread:
http://fenics.org/pipermail/dorsal-dev/2009-July/000266.html

I have not worked in all the changes that were brought during that
discussion since Max hasn't gotten back to the list as to whether he was
ultimately successful.

Harish

---

From: Harish Narayanan <[email-masked]>
Date: Mon, 03 Aug 2009 16:50:46 +0200

> consider this closed.  Sorry for the interuption. -- Doug

Oops. I replied before I saw this. Take from my response only what is
pertinent, then.

Harish

---

From: Douglas N Arnold <[email-masked]>
Date: Mon, 03 Aug 2009 11:38:21 -0500

When building FEniCS on Fedora 10 using dorsal the petsc build failed with 
the message below.  The cure was to install mpich2
with "yum install mpich2".  mpich2 should probably be added to the list of 
required packages in the comments to fedora10.platform.

>>
>>> Building petsc-3.0.0-p5
>>> =================================================================================
>>>
>>>              Configuring PETSc to compile on your
>>> system                        
>>> =================================================================================
>>>
>>> ================================================================================
>>>
>>>                 WARNING! Compiling PETSc with no debugging, this should
>>>                                only be done for timing and production
>>> runs. All developme                      be done when configured using
>>> --with-debugging=1         
>>> ==========================================================
>>> ======================
>>> TESTING: configureMPIEXEC from
>>> config.packages.MPI(config/BuildSystem/config/pac
>>> *********************************************************************************
>>>
>>>          UNABLE to CONFIGURE with GIVEN OPTIONS    (see configure.log
>>> for details):
>>> ---------------------------------------------------------------------------------------
>>>
>>> Could not locate MPIEXEC - please specify --with-mpiexec option
>>> *********************************************************************************
>>>
>>>
>>> Failure with exit status:
>>> 1                                                     Exit message:
>>> There was a problem in build setup for petsc-3.0.0-p5.

---

From: Douglas N Arnold <[email-masked]>
Date: Mon, 03 Aug 2009 11:52:02 -0500

I'm working my way through the build of FEniCS using dorsal-4b2dcbb0ef44
STABLE_BUILD=false and swiginac compile failed.  Any suggestions?

Fetching swiginac-1.5.1
Unpacking swiginac-1.5.1
Building swiginac-1.5.1
running build_ext
building '_swiginac' extension
swigging swiginac.i to swiginac_wrap.cpp
swig -python -c++ -o swiginac_wrap.cpp swiginac.i
archive.i:59: Warning(503): Can't wrap 'operator <<' unless renamed to a 
valid identifier.
archive.i:60: Warning(503): Can't wrap 'operator >>' unless renamed to a 
valid identifier.
gcc -pthread -fno-strict-aliasing -DNDEBUG -O2 -g -pipe -Wall 
-Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector 
--param=ssp-buffer-size=4 -m32 -march=i386 -mtune=generic 
-fasynchronous-unwind-tables -D_GNU_SOURCE -fPIC -fPIC 
-I/usr/include/python2.5 -c swiginac_wrap.cpp -o 
build/temp.linux-i686-2.5/swiginac_wrap.o
swiginac_wrap.cpp: In function ‘PyObject* 
_wrap_new_registered_class_options(PyObject*, PyObject*)’:
swiginac_wrap.cpp:24482: error: no matching function for call to 
‘GiNaC::registered_class_options::registered_class_options(const char*, 
const char*, const std::type_info&)’
/usr/include/ginac/registrar.h:52: note: candidates are: 
GiNaC::registered_class_options::registered_class_options(const char*, 
const char*, const void*, GiNaC::ex (*)(const GiNaC::archive_node&, 
GiNaC::lst&))
/usr/include/ginac/registrar.h:50: note: 
GiNaC::registered_class_options::registered_class_options(const 
GiNaC::registered_class_options&)
swiginac_wrap.cpp: In function ‘PyObject* _wrap_basic_match(PyObject*, 
PyObject*)’:
swiginac_wrap.cpp:26108: error: no matching function for call to 
‘GiNaC::basic::match(const GiNaC::ex&, std::map<GiNaC::ex, GiNaC::ex, 
GiNaC::ex_is_less, std::allocator<std::pair<const GiNaC::ex, GiNaC::ex> > 
 >&) const’
/usr/include/ginac/basic.h:166: note: candidates are: virtual bool 
GiNaC::basic::match(const GiNaC::ex&, GiNaC::lst&) const
swiginac_wrap.cpp: In function ‘PyObject* 
_wrap_basic_return_type_tinfo(PyObject*, PyObject*)’:
swiginac_wrap.cpp:27870: error: ‘return_type_t’ is not a member of ‘GiNaC’
swiginac_wrap.cpp:27870: error: expected `;' before ‘result’
swiginac_wrap.cpp:27883: error: ‘result’ was not declared in this scope
swiginac_wrap.cpp:27901: error: expected type-specifier
swiginac_wrap.cpp:27901: error: expected `)'
swiginac_wrap.cpp:27901: error: expected `)' before ‘;’ token
swiginac_wrap.cpp: In function ‘PyObject* 
_wrap_integral_return_type_tinfo(PyObject*, PyObject*)’:
swiginac_wrap.cpp:39514: error: ‘return_type_t’ is not a member of ‘GiNaC’
swiginac_wrap.cpp:39514: error: expected `;' before ‘result’
swiginac_wrap.cpp:39527: error: ‘result’ was not declared in this scope
swiginac_wrap.cpp:39545: error: expected type-specifier
swiginac_wrap.cpp:39545: error: expected `)'
swiginac_wrap.cpp:39545: error: expected `)' before ‘;’ token
swiginac_wrap.cpp: In function ‘PyObject* 
_wrap_function_options_set_return_type__SWIG_0(PyObject*, PyObject*)’:
swiginac_wrap.cpp:47660: error: ‘return_type_t’ is not a member of ‘GiNaC’
swiginac_wrap.cpp:47660: error: ‘arg3’ was not declared in this scope
swiginac_wrap.cpp:47660: error: ‘return_type_t’ is not a member of ‘GiNaC’
swiginac_wrap.cpp:47660: error: expected primary-expression before ‘)’ token
swiginac_wrap.cpp:47660: error: expected `;' before numeric constant
swiginac_wrap.cpp:47687: error: expected type-specifier
swiginac_wrap.cpp:47687: error: expected `>'
swiginac_wrap.cpp:47687: error: expected `('
swiginac_wrap.cpp:47687: error: ‘return_type_t’ is not a member of ‘GiNaC’
swiginac_wrap.cpp:47687: error: expected primary-expression before ‘>’ token
swiginac_wrap.cpp:47687: error: expected `)' before ‘;’ token
swiginac_wrap.cpp:47691: error: ‘return_type_t’ is not a member of ‘GiNaC’
swiginac_wrap.cpp:47691: error: expected `)' before ‘const’
swiginac_wrap.cpp: In function ‘PyObject* _wrap_find(PyObject*, PyObject*)’:
swiginac_wrap.cpp:49514: error: invalid initialization of reference of 
type ‘GiNaC::lst&’ from expression of type ‘std::set<GiNaC::ex, 
GiNaC::ex_is_less, std::allocator<GiNaC::ex> >’
/usr/include/ginac/ex.h:712: error: in passing argument 3 of ‘bool 
GiNaC::find(const GiNaC::ex&, const GiNaC::ex&, GiNaC::lst&)’
swiginac_wrap.cpp: In function ‘PyObject* _wrap_match(PyObject*, PyObject*)’:
swiginac_wrap.cpp:50859: error: invalid initialization of reference of 
type ‘GiNaC::lst&’ from expression of type ‘std::map<GiNaC::ex, GiNaC::ex, 
GiNaC::ex_is_less, std::allocator<std::pair<const GiNaC::ex, GiNaC::ex> > >’
/usr/include/ginac/ex.h:772: error: in passing argument 3 of ‘bool 
GiNaC::match(const GiNaC::ex&, const GiNaC::ex&, GiNaC::lst&)’
swiginac_wrap.cpp: In function ‘PyObject* 
_wrap_clifford_read_archive(PyObject*, PyObject*)’:
swiginac_wrap.cpp:79108: error: ‘class GiNaC::clifford’ has no member 
named ‘read_archive’
error: command 'gcc' failed with exit status 1
Failure with exit status: 1
Exit message: There was a problem in build setup for swiginac-1.5.1.

---

From: Anders Logg <[email-masked]>
Date: Mon, 3 Aug 2009 21:48:15 +0200

> either. Perhaps the scons version is too old (or not there).

I'm installing UFC with Dorsal and it works fine here. I'm using
scons version 1.2.0-2ubuntu1 on Ubuntu Karmic (also works with Jaunty).

-- 
Anders

---

From: Douglas Arnold <[email-masked]>
Date: Mon, 03 Aug 2009 15:55:10 -0500

I've got everything to work building the most recent unstable version 
of dolfin with the most recent development version of dorsal on three 
platforms: Jaunty 32 bit, Jaunty 64 bit, and Fedora 10 64 bit.  I had 
some troubles with ginac and swiginac on the Jaunty 64, but I just 
commented them out of the platform file and didn't build them, which 
doesn't seem to effect dolfin.

Thanks for the help.

---

From: Harish Narayanan <[email-masked]>
Date: Tue, 04 Aug 2009 12:40:01 +0200

> doesn't seem to effect dolfin.

(Swi)GiNaC is not necessary for DOLFIN.

Just to summarise, so I can make appropriate changes:

Jaunty    (32 bit): Worked out of the box
Jaunty    (64 bit): Worked without (Swi)GiNaC
Fedora 10 (64 bit): Worked with the addition of an MPI rpm package

Correct?

Harish

---

From: Joachim Berdal Haga <[email-masked]>
Date: Fri, 07 Aug 2009 13:53:45 +0200

> bothers me too when I forget to hit 'OK' and it gives up trying to fetch

There are some options for getting svn to accept certs automatically, 
but it may depend on new (or even unreleased) svn versions.

So the simplest way I think is just to run it as "echo p|svn co ..." to 
answer the question by "p" (permanent accept). Of course this would also 
reply "p" to any other question from svn, but I don't think that's a 
problem in practice (in what other cases would svn expect user input?).

Security implications? It would force the user to accept an untrusted 
cert, which may be bad. Maybe replace "p" with "t" (temporary), in that 
case it must also be used for the "svn up" command.

Possibly same issue with wget for tarballs over https; but wget accepts 
"--no-check-certificate" option.

-- 
-j.

---

From: Harish Narayanan <[email-masked]>
Date: Fri, 07 Aug 2009 14:30:53 +0200

> "--no-check-certificate" option.

I was thinking of something evil. What if one just made a copy of the
file this question generates (in ~/.subversion/auth/svn.ssl.server/) and
just uses that on subsequent installs?

Harish

---

From: Joachim Berdal Haga <[email-masked]>
Date: Wed, 12 Aug 2009 14:42:31 +0200

> just uses that on subsequent installs?

That actually sounds reasonable (and IMO not that evil either, although 
I guess it may affect other actions for the same user). Simplest just to 
distribute it in dorsal then?

For reference, the svn option is in svn 1.6 and up (too recent for 
jaunty): "--non-interactive --trust-server-cert"

-j.