Compiling required libraries for OSMesa

[Zhou Zhang]

Hello everyone,

I'm new to Basilisk. Now I have followed the instructions on http://basilisk.fr/src/gl/INSTALL and tried to compile the required libraries with

cd $BASILISK/gl
make libglutils.a libfb_osmesa.a

Then I got the following error message:

make: `libglutils.a' is up to date.
cc -g -Wall -pipe -D_FORTIFY_SOURCE=2 -O2   -c -o fb_osmesa.o fb_osmesa.c
fb_osmesa.c:1:23: fatal error: GL/osmesa.h: No such file or directory
 #include <GL/osmesa.h>
                       ^
compilation terminated.
make: *** [fb_osmesa.o] Error 1


Since I have installed Basilisk on a cluster, I can't use

sudo apt-get install libglu1-mesa-dev libosmesa6-dev

to install the required libraries. Does anybody have solutions to this issue? Thanks for your help!

Best,

Zhou

[Alexis Berny]

All you need to do is to follow the following instruction: http://basilisk.fr/src/gl/INSTALL#installing-osmesaglu-from-source

You will then have OSMesa directly installed in your home folder, and then you can compile libfb_osmesa.a

[Zhou Zhang]

Hey Alexis,

Thanks a lot! It worked.

Now I have met another problem. When I tried to run an example case in the sandbox (http://basilisk.fr/sandbox/popinet/wave.c), I used the following commands for compiling:

qcc -source -D_MPI=1 -grid=multigrid3D wave.c

mpicc -O2 -Wall _wave.c -o wave -L$BASILISK/gl -lglutils -lfb_osmesa -lOSMesa -lGLU -lm

Then it gave this error message:

fatal error: gl/framebuffer.h: No such file or directory
 #include <gl/framebuffer.h>
          ^~~~~~~~~~~~~~~~~~
compilation terminated.

I'm confused because I can find the framebuffer.h file in the gl directory. Do you know what is going on here? Thanks again for your time!

Zhou

[xiaowei zhu]

Dear Zhou,

Have you solved the problem of running Basilisk on supercomputer?

regards,

Xiaowei

[Zhou Zhang]

Hi Xiaowei,

My problem was actually not running on supercomputers but the installation of the gl libraries. If you have trouble running on supercomputers, this site might be helpful: http://basilisk.fr/src/Tips (which worked for me).

Best,

Zhou

[xiaowei zhu]

Hi Zhou,

Thank you for the reply. Actually I was refering to your second posted problem. I got the same error when I compling the code on a supercluster. 

fatal error: gl/framebuffer.h: No such file or directory
 #include <gl/framebuffer.h>
          ^~~~~~~~~~~~~~~~~~
compilation terminated.

I checked that gl library on my local computer has been successfully installed. 

So I want to know how you sloved this problem?

Best regards, Xiaowei

[Junbo Jia]

Hi Xiaowei,

I have the same problem as you.

Have you solved the problem of running Basilisk on supercomputer?

Regards,

Junbo

在 2019年11月16日星期六 UTC+8上午6:12:46，xiaowei zhu写道：

[xiaowei zhu]

Hi Junbo,

Try to indicate the directory of the gl library in the code, like this:

#include </nfs/home/gl/framebuffer.h>. 

Replace the /nfs/home by your own directory. Then you shall work around this problem.

[Stephane Popinet]

> Try to indicate the directory of the gl library in the code, like this:> #include <*/nfs/home*/gl/framebuffer.h>.

> Replace the /nfs/home by your own directory. Then you shall work around
> this problem.

Don't edit the code. Just use the -I and -L flags of the compiler, and
read up on how to use libraries when compiling codes. For example:

https://www.rapidtables.com/code/linux/gcc/gcc-l.html

cheers,

Stephane

[Richard LIU]

Hi Stephane, 

I encountered the same problem.

I compile and run the atomisation example on my pc, and it worked well. 

CC99='mpicc -std=c99' qcc -autolink -O2 -Wal

l -D_MPI=1 -o $NAME $NAME.c -lm -L$BASILISK/gl -lfb_glx -lGLU -lGLEW -lGL -lX11      

And then on the same computer, I compile atomisation.c to _atomisation.c, then the following compile failed:

liu@liu-Precision-3630-Tower:~/basilisktst/atomization2$ mpicc -Wall -O2 -std=c99 _atomisation.c -o atomisation -

L~/basilisk/src/gl -lfb_glx -lGLU -lGLEW -lGL -lX11 -lm                                              

/home/liu/basilisk/src/view.h:68:10: fatal error: gl/framebuffer.h: No such file or directory

 #include <gl/framebuffer.h>

          ^~~~~~~~~~~~~~~~~~

compilation terminated.

I just do the two compilations in the same computer, one succeed and another failed, could you give me some suggestions? thanks a lot!

Richard LIU

在 2020年4月2日星期四 UTC+8下午4:07:07，Stephane Popinet写道：

[Nelson Joubert]

Hello Basilisk users,

I tried to compile a code with visualisation (with view.h) on a supercomputer (Occigen) with the last basilisk version and so the last /src/gl/, following this http://basilisk.fr/sandbox/joubert/INSTALL_mesa_supercomputer#osmesaglu-on-occigen
During compilation I got this error:

joubert@login3:/scratch/cnt0021/ija7325/joubert/run_directory/injection/prod/normal/0.486L/0.6L/lvl8/tracer/tracer$ sh run.sh
remove module llvm/3.9.1 (tool llvm)
remove module mkl/compilers_and_libraries_2017.0.098/linux (Intel MKL)
remove module idb/compilers_and_libraries_2017.0.098/linux (Intel Debugger)
remove module intel/17.0 (Intel Compiler Suite)
  /opt/mpi/openmpi-icc/2.0.4.12 openmpi-icc
 everything is fine : /opt/mpi/openmpi-icc/2.0.4.12 openmpi-icc
remove module openmpi-icc/2.0.4.12 (openmpi)
  /opt/mpi/openmpi-icc/2.0.4.12 openmpi-icc
 everything is fine : /opt/mpi/openmpi-icc/2.0.4.12 openmpi-icc
load module openmpi-icc/2.0.4.12 (openmpi)
load module mkl/compilers_and_libraries_2017.0.098/linux (Intel MKL)
load module idb/compilers_and_libraries_2017.0.098/linux (Intel Debugger)
load module intel/17.0 (Intel Compiler Suite)
load module llvm/3.9.1 (tool llvm)
/home/joubert/basilisk/src/draw.h(392): error: identifier "Node" is undefined
  static double evaluate_expression (Point point, Node * n)
                                                  ^

/home/joubert/basilisk/src/draw.h(447): error: identifier "Node" is undefined
  static bool assemble_node (Node * n)
                             ^

/home/joubert/basilisk/src/draw.h(457): warning #266: function "reset_node_type" declared implicitly
   reset_node_type (n, 'D');
   ^

/home/joubert/basilisk/src/draw.h(459): warning #266: function "reset_node_type" declared implicitly
   reset_node_type (n, 'x');
   ^

/home/joubert/basilisk/src/draw.h(461): warning #266: function "reset_node_type" declared implicitly
   reset_node_type (n, 'y');
   ^

/home/joubert/basilisk/src/draw.h(463): warning #266: function "reset_node_type" declared implicitly
   reset_node_type (n, 'z');
   ^

/home/joubert/basilisk/src/draw.h(475): warning #266: function "reset_node_type" declared implicitly
       reset_node_type (n, '1');
       ^

/home/joubert/basilisk/src/draw.h(502): error: identifier "Node" is undefined
    Node * node = parse_node (expr);
    ^

/home/joubert/basilisk/src/draw.h(502): error: identifier "node" is undefined
    Node * node = parse_node (expr);
           ^

/home/joubert/basilisk/src/draw.h(502): warning #266: function "parse_node" declared implicitly
    Node * node = parse_node (expr);
                  ^

/home/joubert/basilisk/src/draw.h(508): warning #266: function "free_node" declared implicitly
      free_node (node);
      ^

/home/joubert/basilisk/src/draw.h(513): warning #266: function "free_node" declared implicitly
      free_node (node);
      ^

/home/joubert/basilisk/src/draw.h(523): warning #266: function "free_node" declared implicitly
    free_node (node);
    ^

compilation aborted for _injection_0.486L_0.6L_tracer.c (code 2)

Does anyone had this issue since recent update or know a fix ?

Cheers

Nelson

[Stephane Popinet]

Hi Nelson,

You need to update your occigen installation of the gl/ libraries.

Or you can use my installation, see:

http://basilisk.fr/src/gl/INSTALL#osmesaglu-on-occigen

cheers,

Stephane

[Nelson Joubert]

Hello Stéphane,

I forgot to mention that the error I obtained was after the update and recompilation without problem of the gl/ libraries.
Nevertheless,I tried the code view.c wiith your library http://basilisk.fr/src/gl/INSTALL#osmesaglu-on-occigen  .
The code compile and run.
But a more problematic thing happen, it can't generates a readable 3D dump file. It generates a file dump~ of zero octet size and that naturally can't be read with bview on my machine:

-rw-r--r-- 1 nels0n1 nels0n1    0 mai   19 15:40 dump~
nels0n1@nels0n-N56VB:~/2$ bview3D dump~
restore(): error: expecting header

I experienced this problem of generating dump file on Occigen with other codes when using something like:

dump (file = "dump");

Cheers 

Nelson

[HUI WANG]

Hi everyone,

I have the same problem on a cluster, have you solved this problem ? 

mpicc -O2 -Wall _drop.c -o drop -L$BASILISK/gl -lglutils -lfb_osmesa -lOSMesa -lGLU -lm

fatal error: gl/framebuffer.h: No such file or

directory
compilation terminated.

I can find the framebuffer.h in /home/hui/basilisk/src/gl directory. As Stephane suggested, I used the flag -I to add the directory of head files, but it did not work.

mpicc -O2 -Wall _drop.c -o drop -I/home/hui/basilisk/src/gl -L$BASILISK/gl -lglutils -lfb_osmesa -lOSMesa -lGLU -lm

/home/hui/basilisk/src/view.h:68:28: fatal error: gl/framebuffer.h: No such file or directory
compilation terminated.

Did I miss something? Could someone give me an idea of how to fix this problem.  Thanks a lot 

Best!

Hui

在 2019年10月22日星期二 UTC+2下午5:08:15，Zhou Zhang写道：

[Antoon van Hooft]

Hallo Hui,

Note that "gl/framebuffer.h" is not in "$BASILISK/gl/".

So you could try,

-I$BASILISK

instead.

Antoon

[alessandr...@gmail.com]

Dear Basilisk users,

I am trying to install BASILISK on GALILEO supercomputer, and I found this post.

I followed the instructions reported at http://basilisk.fr/src/gl/INSTALL#installing-osmesaglu-from-source, and now my "local" folder contains 3 folders (basilisk, mesa-17.2.4, glu-9.0.0) in which (I suppose) there should be all the files required for the installation of the program.

Anyway, I am experiencing a problem with Basilisk View Servers installation.

In particular, when I write in terminal:

cd $BASILISK/gl

make

I obtain the following error:

In file included from OffscreenContextGLX.c:53:0:

system-gl.h:2:21: fatal error: GL/glew.h: File o directory non esistente

 #include <GL/glew.h>

                     ^

compilation terminated.

make: *** [OffscreenContextGLX.o] Errore 1

and when I write:

cd $BASILISK

make biew-servers

I obtain the following error:

qcc -O2 -g -Wall -pipe -D_FORTIFY_SOURCE=2 bview-server.c -o bview-server2D -Lgl -lglutils -lfb_osmesa -lGLU -lOSMesa -lm

/usr/bin/ld: impossibile trovare -lOSMesa

collect2: error: ld returned 1 exit status

These errors mean (sorry for the Italian language in the errors) that the "glew.h" and "lOSMesa" files are not found in /usr/bin/ld. The problem now is that "glew.h" and "lOSMesa" are not present neither in folder "mesa-17.2.4" nor in folder "glu-9.0.0", in which I supposed there should be.

I do not understand if something went wrong during the download of the files from  http://basilisk.fr/src/gl/INSTALL#installing-osmesaglu-from-source, or if these files should be located in some other folders of the cluster.

Thanks for your attention.

Kind Regards,

Alessandro Della Pia

[Nelson Joubert]

Hello Alessandro,

It is generally not a good idea to install Basilisk on a supercomputer, and you don't have to install it to run a code.
If you look at http://www.basilisk.fr/src/examples/atomisation.c#running-in-parallel you can see that first a source code
is genereted (_atomisation.c) on the local machine then this code is copied and run on the supercomputer without installing Basilisk on the supercomputer.
If you want to run your code with visualisation generated with view.h you can follow this page http://www.basilisk.fr/sandbox/joubert/INSTALL_mesa_supercomputer.

Cheers

Nelson

[alessandr...@gmail.com]

Dear Nelson,

Thank you very much for your quick answer.

I followed your advice, and now I think I discovered where the problem is.

After:

wget http://basilisk.fr/src/gl/mesa-17.2.4.tar.gz wget http://basilisk.fr/src/gl/glu-9.0.0.tar.gz scp mesa-17.2.4.tar.gz lo...@supercomputer.org: scp glu-9.0.0....@supercomputer.org:

and, on the supercomputer:

tar -zxvf mesa-17.2.4.tar.gz cd mesa-17.2.4 ./configure --prefix=/home/login/local --enable-osmesa \ --with-gallium-drivers=swrast \ --disable-driglx-direct --disable-dri --disable-gbm --disable-egl

I obtain the following error (highlighted in red):

checking build system type... x86_64-pc-linux-gnu

checking host system type... x86_64-pc-linux-gnu

……….

……….

checking for WAYLAND_SCANNER... no

checking for wayland-scanner... :

checking for XCB_DRI2... yes

configure: error: Platform surfaceless requires libdrm >= 2.4.75

And the “Makefile” is not generated. Indeed, if I try in terminal:

make

I obtain the following error:

make: *** Nessun obiettivo specificato e nessun makefile trovato.  Stop.

Which means “no objective specified and no makefile found” (sorry for the Italian language).

Therefore, also the last part of the procedure exhibits errors: when I write in terminal

cd gl CFLAGS+='-I/home/login/local/include' make libglutils.a libfb_osmesa.a

I obtain:

fb_osmesa.c:2:56: fatal error: ./../../home/aledp/local/include/GL/osmesa.h: File o directory non esistente

 #include <./../../home/aledp/local/include/GL/osmesa.h>

                                                        ^

compilation terminated.

make: *** [fb_osmesa.o] Errore 1

Which means that “osmesa.h” is not found in the specified directory.

Do you think that the original error "configure: error: Platform surfaceless requires libdrm >= 2.4.75"

could be a cluster-related error, so independent from the files at the links 

http://basilisk.fr/src/gl/mesa-17.2.4.tar.gz

http://basilisk.fr/src/gl/glu-9.0.0.tar.gz

?

Thanks again for your help.

Best Regards,

Alessandro

[Alessandro Della Pia]

Dear all,

I investigated more in deep this question, and I found out that the problem is the required version of libdrm:

configure: error: Platform surfaceless requires libdrm >= 2.4.75

The libdrm version installed on the supercomputer that I am using is 2.4.74.

So, it seems to me that there is no chance to install the required graphical libraries.

Do you have any suggestion?

Is there an older version of mesa that requires libdrm < 2.4.75 still working for Basilisk?

Thanks in advance for your attention.

Best Regards,

Alessandro Della Pia

--
You received this message because you are subscribed to the Google Groups "basilisk-fr" group.
To unsubscribe from this group and stop receiving emails from it, send an email to basilisk-fr...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/basilisk-fr/a0a586dd-0177-4316-bd99-4e0071208a88n%40googlegroups.com.

[HUI WANG]

Hello Alessandro,

I had the same problem before. I installed a new version of libdrm in my home folder in the supercomputer.

you can download the source code here https://dri.freedesktop.org/libdrm/, then use something like  ./configure --prefix=///   to install it. 

Then export the path export LD_LIBRARY_PATH=../../../lib/:$LD_LIBRARY_PATH

Hope it helps

Hui

[Alessandro Della Pia]

Dear Hui,

really thanks for your answer and help.

Following your suggestion, I downloaded https://dri.freedesktop.org/libdrm/libdrm-2.4.75.tar.gz

in my home folder ($HOME), and then installed it after doing  ./configure --prefix=$HOME/local inside the folder "libdrm-2.4.75".

Then, I exported the path: export LD_LIBRARY_PATH=$HOME/local/lib/:$LD_LIBRARY_PATH

Unfortunately, when I try to generate the Makefile of mesa libraries doing:

tar -zxvf mesa-17.2.4.tar.gz
cd mesa-17.2.4
./configure --prefix=/home/login/local --enable-osmesa \
            --with-gallium-drivers=swrast                \
            --disable-driglx-direct --disable-dri --disable-gbm --disable-egl

I obtain again the following error message:

configure: error: Platform surfaceless requires libdrm >= 2.4.75.

What do you think went wrong doing the installation/exportation of the path of libdrm-2.4.75?

Again, thanks a lot for your help

Alessandro

[Jacob Leff]

Dear all,

I'm replying here cause I've had similar issues and am confused. 

I'm also trying to install mesa on a supercomputer and I can't get past the error detailed here related to the openGL libraries needed for view.h. This occurs after compiling the distance.c example using the following command:

> qcc -O2 -Wall distance.c -o distance -lm

Likewise, running > make distance.tst generates the folder, but the executable won't work and the pictures spit out are blank. 

I've gone through the documentation for gl/INSTALL and installing mesa on a supercomputer. In my basilisk folder I have the folders: src, mesa-17.2.4, glu-9.0.0 . I've configured and made these, which produced lib and include folders in /share/.../local/ (rather than  $HOME/local). In $BASILISK/config I commented out the dummy lines and uncommented the line for OSmesa and then ran make again. This worked without issue.

In $BASILISK/gl, running:

> make libglutils.a libfb_osmesa.a 

also works fine. However, running just > make produces an error that glew.h can't be found.

In my .bashrc I also have:

# Mesa

MESA_HOME=/share/.../basilisk/mesa-17.2.4

export LIBRARY_PATH=$LIBRARY_PATH:$MESA_HOME/lib

export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:$MESA_HOME/lib

export C_INCLUDE_PATH=$C_INCLUDE_PATH:$MESA_HOME/include/

export CPLUS_INCLUDE_PATH=$CPLUS_INCLUDE_PATH:$MESA_HOME/include/

# GLU?

export LIBRARY_PATH=$LIBRARY_PATH:/share/.../local/lib

I think I'm missing a step, maybe related to linking OSmesa to the makefiles or maybe something is in the wrong folder, but I'm not sure what/where to edit. 

Thanks

[Jacob Leff]

Just including a brief update here:

I tried compiling with 

qcc -Wall -O2 program.c -o program \ -L$BASILISK/gl -lglutils -lfb_osmesa -lGLU -lOSMesa -lm

instead, and that worked without error, but when I try to run the new program, it just prints Segmentation fault (core dumped), and stops.

[Jacob Leff]

I found a solution for this.  In my bashrc I have:

MESA_HOME=/share/.../local

export LIBRARY_PATH=$LIBRARY_PATH:$MESA_HOME/lib

export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:$MESA_HOME/lib

And only when making the gl files did I set "export C_INCLUDE_PATH=$C_INCLUDE_PATH:$MESA_HOME/include/". I also made sure to copy the gl file into .../local/ every time rather than linking it.

[Harsh Agarwal]

Hello, 

I have installed basilisk in WSL environment in "/home/gopu" directory my windows PC also on college HPC cluster. Their I prepare the code file "atomisation.c" in "/home/gopu/myfiles" directory as reccomended in example. 

 

1)- Approach first:

 

 Then I produce the source code on my local PC as recommended in the example using:

qcc -source -grid=octree -D_MPI=1 atomisation.c

Then I copy the source code "_atomisation.c" from my local PC to my college HPC cluster using:

scp _atomisation.c javedm@clustername:/home/javedm/myfiles 

Their I prepare the run script which I am attaching as "run.sh" to upload the job script on the cluster, but I am getting the error file and output file containing error, which are named respectively as "log_compilation" and "atomout_compilation_error".

From analysing the errors, I am suggesting that the compilation using mpicc is not being done, as it might be searching the files in "/home/gopu/basilisk.." instead of "/home/javedm/basilisk..". Therefore, not producing the executable file.

Please suggest me something to solve this error.

 

2)- Approach second:

 

As in first approach I produced the source code on local PC, but this time I compile the source code on the login node of the HPC by loading the required module:

module load compiler/openmpi/gcc/4.0.2

module load compiler/intel/2020.2.254

compiling using:

mpicc -Wall -std=c99 -D_XOPEN_SOURCE=700 -O2 _atomisation.c -o atomisation -L/home/javedm/basilisk/src/gl -lglutils -lfb_tiny -lm

This produce executable file naming “atomisation”, then I submit the run script with run command only naming “run1.sh”

This produce an error file and a output file respectively naming as “log_run2” and “basilisk2.output”

 

3)- Approach third:

 

Instead of producing the source code on the local PC, I tried to produce the source code on the HPC using the same:

qcc -source -grid=octree -D_MPI=1 atomisation.c

with some parsing errors it produces source code "_atomisation.c". The errors file naming “comp_onlog.docx”.

Then I upload the same "run.sh" script hoping successful compilation and execution, but now also the compilation doesn’t work. Therefore, no point of execution also.

I am attaching the error file as "log_hpc" and also the output file as "basilisk3.output"

Please suggest me something to solve this error.

4)- Approach fourth:

 

As in third approach produce source code on HPC and this time doing the compilation on the login node as well by loading the required module:

module load compiler/openmpi/gcc/4.0.2

module load compiler/intel/2020.2.254

then doing the compilation using:

mpicc -Wall -std=c99 -D_XOPEN_SOURCE=700 -O2 _atomisation.c -o atomisation -L/home/javedm/basilisk/src/gl -lglutils -lfb_tiny -lm

which produce an executable file “atomisation”.

Then for executing the code I upload the job script naming “run4.sh”, which in return produces error and output file as “log_run4” and “basilisk4.output” respaectively.

 

5)- Approach fifth:

 

Produced the source code on local PC, compiled on login node and running on HPC using run script but containing the run command for single environment i.e.

./atomisation

Which produces the files but they are not as I want them to be.

If anyone one of you can suggest a proper procedure then please suggest me, or if I am doing some silly mistake in my procedure then please also suggest.