Problem of parsing string option in config file makes basic installing procedure fail

[Wachs, Anthony]

Hi everyone,

We have ported and installed Basilisk straightforwardly on multiple machines (including supercomputers) but have been incapable of installing it on the environnement of the new federal supercomputers here in Canada.

The problem looks pretty simple though: it seems that the option CC99 is not processed/parsed properly when that option contains more than 1 string. 

Below are some examples of unsuccessful and successful installations.

If I set CC99 = $(CC) -std=c99 -pedantic -D_GNU_SOURCE=1 -Wno-unused-result, I get the following error:

 

If I only pass one option as CC99 = $(CC) -std=c99, I get:

And I eventually realized that the option does not matter, I can actually pass the option titi as CC99 = $(CC) -titi, and get:

The commonality between the above examples is that the option CC99 is not correctly parsed on the Canadian federal supercomputers’ environment and there is always an additional “ attached to the last option that should not be there.

I have spent hours trying to understand how the Makefile and the different compiling stages work in Basilisk but failed to patch this. The CC99 string is exported in Makefile.defs and shows up in 3 lines only at the top of the main in qcc.c (itself a result of qcc.lex).

It is not entirely clear why the compilation of qcc fails, as the option -DCC99=xxx simply replaces any instance of CC99 with its definition.

Anyhow, for now, the only way I managed to install Basilisk on the Canadian federal supercomputers is to pass the options to CC instead of CC99 as follows:

CC = $(BASILISK_C) -std=c99 -pedantic -D_GNU_SOURCE=1 -Wno-unused-result

CC99 = $(BASILISK_C)

where BASILISK_C is a basic exported variable of the form xxx/yyy/bin/gcc. Doing this CC99 is defined as a single string.

Consequently, it does work well, but I am now passing options to any call to CC that I may not want to pass. And this is certainly not what the config file has been designed for.

No bid deal though I suspect as the options -std=c99 -pedantic -D_GNU_SOURCE=1 -Wno-unused-result are relatively harmless.

Once again, this issue to install Basilisk is specific to the environment of the Canadian federal supercomputers

If anyone has any idea how to fix this option parsing problem ?

Thank you in advance,

Anthony

-- 
Anthony Wachs, Associate Professor
Departments of Mathematics and Chemical & Biological Engineering
University of British Columbia
Vancouver, BC, Canada

e-mail: wa...@math.ubc.ca / wa...@mail.ubc.ca 

Tel: +1-604-822-4346

Personal webpage: http://www.math.ubc.ca/~wachs/

[Stephane Popinet]

Hi Anthony,

This looks a bit strange but I must admit I have not really looked into
the details of your problem.

Generally speaking, as you know, supercomputers are often strangely
configured and this can cause a lot of boring and highly specific
debugging when trying to install stuff.

What I would generally recommend is _not_ trying to install Basilisk
directly on these systems but rather to generate a portable C source on
a local machine (where Basilisk is installed) and only compile this on
the supercomputer. The recipe is described here:

http://basilisk.fr/src/Tips#running-on-supercomputers

This will circumvent most of the problems. It also has the added
advantage that the same code (as fully encapsulated in the C source
file) can easily be run on several different supercomputers with minimal
configuration headaches (and added confusion of maintaining several
versions of Basilisk on different machines).

cheers,

Stephane

[Junbo Jia]

Hi  Stephane,

As you said, I generated a portable C source on the local machine 

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

and  compiled this on the supercomputer.

 mpicc -Wall -std=c99 -O2 -D_MPI=1 _atomisation.c -o atomisation -lm 

then got:

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

But I checked that framebuffer.h is indeed in the gl folder of the local computer，and unencapsulated C files on the local computer can be successfully compiled

Is there an error in the way of encapsulation? Or do I need to install some modules on the supercomputer?

In addition, compiling encapsulated C on the local computer gives the same error，

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

I tried to add the absolute path:

Then compile： mpicc -Wall -std=c99 -O2 _atomisation.c -o atomisation -lm

got error:

undefined reference to 'gl_***' ......

Regards,

Junbo

在 2019年8月19日星期一 UTC+8下午4:39:16，Stephane Popinet写道：