utils/python/ufc_utils/build.py looks in /usr/lib but not in /usr/lib64 when seraching for libboost_math

[Marco Morandini]

at line 145

[Johan Hake (johan-hake)]

Thanks for reporting. Our intention is to come up with a more robust way of
finding these libraries.

Can you confirm that changing the mentioned line to:

    for lib_dir in ["", "lib64", "lib"]:

fix the problem?

Johan

On Tuesday December 6 2011 14:56:26 Marco Morandini wrote:
> Public bug reported:
>
> at line 145
>
> ** Affects: ufc
> Importance: Undecided
> Status: New

[Marco Morandini (morandini)]

Yes, it fixes the problem _for me_, and I think it is definitely an improvement. But I'm not sure it will fix the problem for everyone: I don't know what could happen if someone, with lib64/libboost installed, will try to build a 32 bit version of Fenics; the same for an installed 32 bit version of libboost and a 64 bit version of Fenics. The dynamic linker will likely refuse to link, but perhaps with a somewhat cryptic message...

[Johan Hake (johan-hake)]

On Tuesday December 6 2011 15:44:02 Marco Morandini wrote:
> Yes, it fixes the problem _for me_, and I think it is definitely an
> improvement.

Ok! Will push the "fix".

> But I'm not sure it will fix the problem for everyone: I
> don't know what could happen if someone, with lib64/libboost installed,
> will try to build a 32 bit version of Fenics; the same for an installed
> 32 bit version of libboost and a 64 bit version of Fenics. The dynamic
> linker will likely refuse to link, but perhaps with a somewhat cryptic
> message...

Sure. Corner cases are always difficult to cover. But as I mention the whole
configure process is essentially a hack, which covers most cases. We have
plans hooking the configure process up to CMake. But up until now that has not
been straighforward, neither have we had the need to do it untill recently.

Johan