Issues with installing OCTANT on Linux x64

Discussion about analysis, visualization, and collaboration tools and techniques

Moderators: arango, robertson

Post Reply
Message
Author
donglai
Posts: 13
Joined: Fri Apr 15, 2005 2:58 pm
Location: Virginia Institute of Marine Science

Issues with installing OCTANT on Linux x64

#1 Unread post by donglai »

So I decided to take a different approach after my OS X installation of OCTANT wasn't going anywhere. I installed Ubuntu 9.04 x64 on VMware Fusion and tried the Linux approach. I got through almost everything for gridgen except the last step of making the shared library. I receive the following error:

linux:~/ROMS/octant/external/gridgen$ make shlib
gcc -c -DTRILIBRARY -g -O2 -Wall -w -ffloat-store -fPIC -I. triangle.c -o triangle.t
gcc -g -O2 -Wall -fPIC -c broyden.c -o broyden.t
gcc -g -O2 -Wall -fPIC -c delaunay.c -o delaunay.t
gcc -g -O2 -Wall -fPIC -c geom.c -o geom.t
gcc -g -O2 -Wall -fPIC -c gridgen.c -o gridgen.t
gcc -g -O2 -Wall -fPIC -c hash.c -o hash.t
gcc -g -O2 -Wall -fPIC -c issimplepoly.c -o issimplepoly.t
gcc -g -O2 -Wall -fPIC -c istack.c -o istack.t
gcc -g -O2 -Wall -fPIC -c ode.c -o ode.t
gcc -g -O2 -Wall -fPIC -c swcr.c -o swcr.t
gcc -g -O2 -Wall -fPIC -c vertlist.c -o vertlist.t
gcc -g -O2 -Wall -fPIC -c zode.c -o zode.t
rm -f libgridgen.so
gcc -shared -o libgridgen.so broyden.t delaunay.t geom.t gridgen.t hash.t issimplepoly.t istack.t ode.t swcr.t vertlist.t zode.t triangle.t -lgu -lm
/usr/bin/ld: /usr/local/lib/libgu.a(gridnodes.o): relocation R_X86_64_32 against `a local symbol' can not be used when making a shared object; recompile with -fPIC
/usr/local/lib/libgu.a: could not read symbols: Bad value
collect2: ld returned 1 exit status
make: *** [libgridgen.so] Error 1

Any ideas?

Thanks,
Donglai

sak007

Re: Issues with installing OCTANT on Linux x64

#2 Unread post by sak007 »

donglai wrote:So I decided to take a different approach after my OS X installation of OCTANT wasn't going anywhere. I installed Ubuntu 9.04 x64 on VMware Fusion and tried the Linux approach. I got through almost everything for gridgen except the last step of making the shared library. I receive the following error:

linux:~/ROMS/octant/external/gridgen$ make shlib
gcc -c -DTRILIBRARY -g -O2 -Wall -w -ffloat-store -fPIC -I. triangle.c -o triangle.t
gcc -g -O2 -Wall -fPIC -c broyden.c -o broyden.t
gcc -g -O2 -Wall -fPIC -c delaunay.c -o delaunay.t
gcc -g -O2 -Wall -fPIC -c geom.c -o geom.t
gcc -g -O2 -Wall -fPIC -c gridgen.c -o gridgen.t
gcc -g -O2 -Wall -fPIC -c hash.c -o hash.t
gcc -g -O2 -Wall -fPIC -c issimplepoly.c -o issimplepoly.t
gcc -g -O2 -Wall -fPIC -c istack.c -o istack.t
gcc -g -O2 -Wall -fPIC -c ode.c -o ode.t
gcc -g -O2 -Wall -fPIC -c swcr.c -o swcr.t
gcc -g -O2 -Wall -fPIC -c vertlist.c -o vertlist.t
gcc -g -O2 -Wall -fPIC -c zode.c -o zode.t
rm -f libgridgen.so
gcc -shared -o libgridgen.so broyden.t delaunay.t geom.t gridgen.t hash.t issimplepoly.t istack.t ode.t swcr.t vertlist.t zode.t triangle.t -lgu -lm
/usr/bin/ld: /usr/local/lib/libgu.a(gridnodes.o): relocation R_X86_64_32 against `a local symbol' can not be used when making a shared object; recompile with -fPIC
/usr/local/lib/libgu.a: could not read symbols: Bad value
collect2: ld returned 1 exit status
make: *** [libgridgen.so] Error 1

Any ideas?

Thanks,
Donglai
You need to run "make shlib" and "make install" for the gridutils package before you try to compile the shared libraries for gridgen.

-Pavel

donglai
Posts: 13
Joined: Fri Apr 15, 2005 2:58 pm
Location: Virginia Institute of Marine Science

Re: Issues with installing OCTANT on Linux x64

#3 Unread post by donglai »

Hi Pavel,

When I tried to make shlib the code complains that it doesn't know how:

linux:~/ROMS/octant/external/gridutils$ make shlib
make: *** No rule to make target `shlib'. Stop.

I did make and make install gridutils. Also both regular make and make lib worked fine for gridgen.

Thanks,
Donglai
sak007 wrote:
donglai wrote:So I decided to take a different approach after my OS X installation of OCTANT wasn't going anywhere. I installed Ubuntu 9.04 x64 on VMware Fusion and tried the Linux approach. I got through almost everything for gridgen except the last step of making the shared library. I receive the following error:

linux:~/ROMS/octant/external/gridgen$ make shlib
gcc -c -DTRILIBRARY -g -O2 -Wall -w -ffloat-store -fPIC -I. triangle.c -o triangle.t
gcc -g -O2 -Wall -fPIC -c broyden.c -o broyden.t
gcc -g -O2 -Wall -fPIC -c delaunay.c -o delaunay.t
gcc -g -O2 -Wall -fPIC -c geom.c -o geom.t
gcc -g -O2 -Wall -fPIC -c gridgen.c -o gridgen.t
gcc -g -O2 -Wall -fPIC -c hash.c -o hash.t
gcc -g -O2 -Wall -fPIC -c issimplepoly.c -o issimplepoly.t
gcc -g -O2 -Wall -fPIC -c istack.c -o istack.t
gcc -g -O2 -Wall -fPIC -c ode.c -o ode.t
gcc -g -O2 -Wall -fPIC -c swcr.c -o swcr.t
gcc -g -O2 -Wall -fPIC -c vertlist.c -o vertlist.t
gcc -g -O2 -Wall -fPIC -c zode.c -o zode.t
rm -f libgridgen.so
gcc -shared -o libgridgen.so broyden.t delaunay.t geom.t gridgen.t hash.t issimplepoly.t istack.t ode.t swcr.t vertlist.t zode.t triangle.t -lgu -lm
/usr/bin/ld: /usr/local/lib/libgu.a(gridnodes.o): relocation R_X86_64_32 against `a local symbol' can not be used when making a shared object; recompile with -fPIC
/usr/local/lib/libgu.a: could not read symbols: Bad value
collect2: ld returned 1 exit status
make: *** [libgridgen.so] Error 1

Any ideas?

Thanks,
Donglai
You need to run "make shlib" and "make install" for the gridutils package before you try to compile the shared libraries for gridgen.

-Pavel

sak007

Re: Issues with installing OCTANT on Linux x64

#4 Unread post by sak007 »

donglai wrote:Hi Pavel,

When I tried to make shlib the code complains that it doesn't know how:

linux:~/ROMS/octant/external/gridutils$ make shlib
make: *** No rule to make target `shlib'. Stop.
Oops - true. Actually, "make" builds both the normal and shared libraries for gridutils, and "make install" copies both to /usr/local/lib. After that, "make shlib" for `gridgen' finds /usr/local/lib/libgu.so with no problem - for me.

If /usr/local/lib/libgu.so is in place, and with correct permissions, you may try to replace "-lgu" by "/usr/local/lib/libgu.so".

-Pavel

-Pavel

donglai
Posts: 13
Joined: Fri Apr 15, 2005 2:58 pm
Location: Virginia Institute of Marine Science

Re: Issues with installing OCTANT on Linux x64

#5 Unread post by donglai »

Pavel, I do not see libgu.so being made in gridutils. I did a make clean and re-run make, only libgu.a is made.

Donglai
sak007 wrote:
donglai wrote:Hi Pavel,

When I tried to make shlib the code complains that it doesn't know how:

linux:~/ROMS/octant/external/gridutils$ make shlib
make: *** No rule to make target `shlib'. Stop.
Oops - true. Actually, "make" builds both the normal and shared libraries for gridutils, and "make install" copies both to /usr/local/lib. After that, "make shlib" for `gridgen' finds /usr/local/lib/libgu.so with no problem - for me.

If /usr/local/lib/libgu.so is in place, and with correct permissions, you may try to replace "-lgu" by "/usr/local/lib/libgu.so".

-Pavel

-Pavel

sak007

Re: Issues with installing OCTANT on Linux x64

#6 Unread post by sak007 »

donglai wrote:Pavel, I do not see libgu.so being made in gridutils. I did a make clean and re-run make, only libgu.a is made.
Donglai, could you do the following steps:

1. svn checkout http://gridutils-c.googlecode.com/svn/gridutils
2. cd gridutils
3. ./configure
4. make

Now check that libgu.so is in place:

5. ls -l libgu.so

6. <login as root>
7. make install

If this does not work, I suggest you to e-mail me the details to pavel.sakov<at>nersc.no

Cheers
Pavel

ce107
Posts: 10
Joined: Tue Jul 01, 2003 10:31 am
Location: MIT,EAPS

Re: Issues with installing OCTANT on Linux x64

#7 Unread post by ce107 »

More generally speaking this error is due to a mixing of PIC and non-PIC objects when the target executable is expected to have more than 2GB of address space extent. It is a "feature" of AMD64/EM64T that AMD introduced by employing 4 different 64bit addressing models (kernel, small (default), medium, large) instead of a flat address space like that in IA64. The main advantage of the default (small) model is speed (something of the order of a few %) - while many (most) compilers don't even provide for the large model. Position independent (PIC) code generation (like that for shared libraries) accomplishes the same as the medium model and is a more general solution.

So if the auto generation of Makefiles does not seem to fix this problem another solution is to add a -fPIC flag to the compiler flags in the makefiles.

Post Reply