Correct path for X11 in ldoptions

[crepes]

Hi,

I am using ubuntu 18.04 and gfortran 7.5 and I am not sure which path I have to choose for LDOPTIONS in makefile.in. I installed libx11-dev.

In the makefile.in, there are "some common cases", i.e.

Code: [Select]

# GNU
# LDOPTIONS = -L/opt/local/lib -lX11 -lm
# LDOPTIONS = -L/opt/local/lib -lX11 -lblas -llapack -lm
# LDOPTIONS = -L/usr/X11R6/lib -lX11 -lblas -llapack -ljpeg -lm

I do not have a folder /usr/X11R6 and I do not have a folder /opt/local/lib. I have a folder /usr/lib/X11 and so I tried using

Code: [Select]

LDOPTIONS = -L/usr/lib/X11 -lX11 -lblas -llapack -ljpeg -lm
and

Code: [Select]

LDOPTIONS = -L/usr/lib/ -lX11 -lblas -llapack -ljpeg -lm
Both these variants do not work. Addiitionally, the 3 variants above do not work. By saying "do not work", I mean that there is an error which indicited a problem in LDOPTIONS.

Before I try to do some experiments on ljpeg and so on, I first want to check if the path is correct.

Kind regards

EDIT: libjpeg-dev is installed, too

[Prof. S. Govindjee]

On my Ubuntu 18.04 I have the following

Code: [Select]

CINCLUDE = /usr/X11R6/include -I$(FEAPHOME8_6)/include

Code: [Select]

LDOPTIONS = -L/usr/X11R6/lib -lX11 -lblas -llapack -lm
The X11 load is looking for libX11.so and quite likely also libXau.so.

On my Ubuntu (Windows 10 linux subsystem) these are actually located in /usr/lib/x86_64-linux-gnu.  So as I look at it more carefully (as well as the include directive) it seems that Ubuntu knows where to find the files and is ignoring the directives since I do not actually have a /usr/X11R6 folder.

[Prof. S. Govindjee]

Have a look at the output of

Code: [Select]

ld --verbose | grep SEARCH_DIRto see what is in the default search path.

Also post the actual error you are seeing.

[Prof. S. Govindjee]

I just tried a clean install on Ubuntu; here is what I used

Code: [Select]

  CINCLUDE =

Code: [Select]

LDOPTIONS =  -lX11 -lm -ljpeg -lblas -llapack
Seems that the compiler and the loader know what to look for.  Here is the output on the load and the loader.

Code: [Select]

sg@SG-DELL-XPS13:~/Feap/main$ ldd feap
        linux-vdso.so.1 (0x00007fffd6f7e000)
        libX11.so.6 => /usr/lib/x86_64-linux-gnu/libX11.so.6 (0x00007f6be73d0000)
        libgfortran.so.4 => /usr/lib/x86_64-linux-gnu/libgfortran.so.4 (0x00007f6be6ff0000)
        libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f6be6c50000)
        libjpeg.so.8 => /usr/lib/x86_64-linux-gnu/libjpeg.so.8 (0x00007f6be69e0000)
        libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f6be67c0000)
        libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f6be63c0000)
        libxcb.so.1 => /usr/lib/x86_64-linux-gnu/libxcb.so.1 (0x00007f6be6180000)
        libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f6be5f70000)
        libquadmath.so.0 => /usr/lib/x86_64-linux-gnu/libquadmath.so.0 (0x00007f6be5d30000)
        /lib64/ld-linux-x86-64.so.2 (0x00007f6be8400000)
        libXau.so.6 => /usr/lib/x86_64-linux-gnu/libXau.so.6 (0x00007f6be5b20000)
        libXdmcp.so.6 => /usr/lib/x86_64-linux-gnu/libXdmcp.so.6 (0x00007f6be5910000)
        libbsd.so.0 => /lib/x86_64-linux-gnu/libbsd.so.0 (0x00007f6be56e0000)
        librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007f6be54d0000)
        libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f6be52b0000)

Code: [Select]

sg@SG-DELL-XPS13:~/Feap/main$ ld --verbose | grep SEARCH
SEARCH_DIR("=/usr/local/lib/x86_64-linux-gnu"); SEARCH_DIR("=/lib/x86_64-linux-gnu"); SEARCH_DIR("=/usr/lib/x86_64-linux-gnu"); SEARCH_DIR("=/usr/lib/x86_64-linux-gnu64"); SEARCH_DIR("=/usr/local/lib64"); SEARCH_DIR("=/lib64"); SEARCH_DIR("=/usr/lib64"); SEARCH_DIR("=/usr/local/lib"); SEARCH_DIR("=/lib"); SEARCH_DIR("=/usr/lib"); SEARCH_DIR("=/usr/x86_64-linux-gnu/lib64"); SEARCH_DIR("=/usr/x86_64-linux-gnu/lib");

[crepes]

Just a second ago, a colleague helped me and he managed to make the installation work...

I have not expected an answer this fast, especially when I think of the US time zones.

But it is really nice to know, that the path seems not to be that important. Thank you very much

PS: the problem in my case was related to a change in the feap code when compared to an untouched version