LINUX distros are changing the location of libc.so.6. Linking LAC can be affected

[bbosen]

Recently we've heard reports from users having trouble linking LAC after successful compilation. The specific error tends to look like this:

"Cannot find -lGL".

We began seeing this in mid-2020 when we used the Makefile from that era, especially on Ubuntu systems. We found that the problem could be overcome by using "Codeblocks" instead of "make", as described here:

https://sourceforge.net/p/linuxaircombat/discussion/ubuntuandlac/thread/bdabd60d2d/

However, by the end of 2022 we learned that even Codeblocks was no longer linking the "-lGL" component correclty for some Ubuntu users.

That "-lGL" symbolic reference is intended to help the linker link to the well-known "libc.so.6" library.

Background for the changes causing this problem can be found here::

https://9to5answer.com/why-is-lib-libc-so-6-missing

According to that article, the filesystem location of libc.so.6 has been changed in order to accommodate TWO versions of this library: one for 32-bit X86 executables and the other for 64-bit X86 executables. By storing two distinct copies of this library, the kernel can dynamically choose the appropriate version as needed.

This means that LAC's Makefile must be updated in order to compensate for the changed location of libc.so.6 in the filesystem. (Those using "CodeBlocks" instead of "make" will also need a Codeblocks update for their distro.)

We are working on appropriate changes to our Makefile. When we find a workable solution, we'll publish it here.

[bbosen]

My main LAC development system does not suffer from this problem, so I need help from somebody that cannot link LAC with our published Makefile.

Here's a copy of the published Makefile as of 06Jan2022, which has trouble linking "-lGL" on some distros:

OBJS=3ds.o aiobject.o audio.o cockpit.o common.o conf.o dirs.o effects.o fileloader.o FlightModel.o gl.o glland.o land.o loader_tga.o main.o mathtab.o menu.o mission.o model.o NetworkApi.o object.o objload.o pilots.o vertexarray.o

CXX=g++ -Ofast -g0 -fPIE

LIBS= -lglut -lGL -lGLU -lSDL -lSDL_mixer

Lac08p95: $(OBJS)
    mkdir -p ~/.LAC
    cp DefaultHeightMap.LAC ~/.LAC/DefaultHeightMap.LAC 
    g++ -o Lac08p95 $(LIBS) $(OBJS)
    cp Lac08p95 bin/Release/Lac08p95
    chmod +x bin/Release/Lac08p95
clean:
    @rm -f *.o
    @rm -f Lac08p95

As you can see, the "-lGL" reference is found in the middle of the "LIBS" statement. I confirmed that the "LIBS" statement can be re-arranged to place that "-lGL" reference at the end of the line, like this:

LIBS= -lglut -lGLU -lSDL -lSDL_mixer -lGL 

Testing that change on my development system reveals that it causes no problems (for me, at least).

Now I need help testing the following little change, which I cannot test on my current development system (because I never see this problem so I won't know if I've fixed it). I want to change that "LIBS" line. After the change, it should look like this:

LIBS= -lglut -lGLU -lSDL -lSDL_mixer -L/lib64 -lGL

As you can see, the only change was to insert "-L/lib64" in front of "-lGL". That instructs the linker to search the directory at /lib64 for subsequent libraries, in addition to any other directories it is already searching.

We need to talk about that "-L/lib64" insertion., because I believe it may be necessary to adjust it on different LINUX distros. On my development system, when I searched for the "libc.so.6" library file that some people have found problematic recently, I found two different filesystem locations for that file. One was within /lib, and the other was within /lib64. (Both of those were actually soft links to two specific library files which, on my distro, were found as /lib/libc-2.33.so and as /lib64/libc-2.33.so. Those two files had different lengths, so I knew they were truly different.)

Based on the difference between the directory locations /lib and /lib64, I assumed that the former should be used for 32-bit software, and the latter should be use for 64-bit software.

The aforementioned "-L/lib64" insertion results from finding the 64-bit version of "libc.so.6" at /lib64 within the filesystem.

For those needing help finding the actual location of all copies of libc.so.6 within your filesystem, I recommend running the following command line, as root, from the root directory:

find . -name libc.so.6 -print

Based on the location of libc.so.6 on your distro, you may need to adjust that "-L/lib64" insertion in the LIBS statement of your Makefile so it references the appropriate copy of libc.so.6 for your distro.

Please let me know if you are able to solve this "-lGL" linker error with this method.

Thanks!

[bbosen]

Update from Mar2024:

We adjusted and simplified our Makefile and this problem seems to have gone away. Here is the text of the adjusted Makefile:

OBJS=3ds.o aiobject.o audio.o cockpit.o common.o conf.o dirs.o effects.o fileloader.o FlightModel.o gl.o glland.o land.o loader_tga.o main.o mathtab.o menu.o mission.o model.o NetworkApi.o object.o objload.o pilots.o vertexarray.o

CXX=g++ -Ofast -g0 -fPIE

LIBS= -lglut -lGLU -lSDL -lSDL_mixer -L/lib64 -lGL

Lac09p61: $(OBJS)
    mkdir -p ~/.LAC
    cp DefaultHeightMap.LAC ~/.LAC/DefaultHeightMap.LAC 
    g++ -o Lac09p61 $(OBJS) $(LIBS)
    cp Lac09p61 bin/Release/Lac09p61
    chmod +x bin/Release/Lac09p61
clean:
    @rm -f *.o
    @rm -f Lac09p61

For our purposes in this discussion, the relevant change is that when we invoke g++ we now reverse the order of the two command line arguments. Instead of passing $(LIBS) first followed by $(OBS), now we pass $(OBS) first, followed by $(LIBS).