Problems compiling the alt-abiv0 branch of the deadw00d/contrib repo.

[ascendant]

I did a git clone of the contrib repo in my AROS directory, then switched it to the alt-abiv0 branch. I had a problem building it (option 6, alt-abiv0-contrib-i386 in rebuild.sh) regarding not finding libglut. I noticed that I did not have the 32-bit libraries for freeglut installed, and so I installed them. But still no success. I ended up rebuilding everything (option 1, toolchain-alt-abiv0-i386, then option 3, alt-abiv0-linux-i386 (DEBUG), then option 6 again), but still a problem:

Code: [Select]

Linking    AROS/Extras/Demos/EGL/eglgears...
Link failed: /home/jlm/code/AROS_build/toolchain-alt-abiv0-i386/i386-aros-gcc --sysroot /home/jlm/code/AROS_build/alt-abiv0-contrib-i386/bin/linux-i386/AROS/Development /home/jlm/code/AROS_build/alt-abiv0-contrib-i386/bin/linux-i386/gen/contrib/Demo/MesaEGL/eglgears.o -o /home/jlm/code/AROS_build/alt-abiv0-contrib-i386/bin/linux-i386/AROS/Extras/Demos/EGL/eglgears -m32 -march=i686 -mno-ms-bitfields -newclib -lglut -leglut -lGL -lGLU -lEGL
/home/jlm/code/AROS_build/toolchain-alt-abiv0-i386/i386-aros-ld: cannot find -lglut
libglut.so is in /usr/lib32. I tried adding -L/usr/lib32, still didn't work. Eventually, I found this to work:

Code: [Select]

jlm@mcp:~/code/AROS_build 91> /home/jlm/code/AROS_build/toolchain-alt-abiv0-i386/i386-aros-gcc --sysroot /home/jlm/code/AROS_build/alt-abiv0-contrib-i386/bin/linux-i386/AROS/Development /home/jlm/code/AROS_build/alt-abiv0-contrib-i386/bin/linux-i386/gen/contrib/Demo/MesaEGL/eglgears.o -o /home/jlm/code/AROS_build/alt-abiv0-contrib-i386/bin/linux-i386/AROS/Extras/Demos/EGL/eglgears -m32 -march=i686 -mno-ms-bitfields -newclib -leglut -lGL -lGLU -lEGL
I just removed -lglut and it worked. I can't explain it, because I do not have a /usr/lib32/libeglut.so file anywhere. Actually, I can't even find a 64 bit version of such a file, so I don't know where it is finding things.

Update:
Okay, so I am guessing with the --sysroot I should be looking in the alt-abiv3-contrib-i386 directory, and I see this:

./bin/linux-i386/AROS/Development/lib/libglut.a
./bin/linux-i386/AROS/Development/lib/libeglut.a

But I see that libglut.a is much more recent than libeglut.a. I think libglut.a wasn't built at the time I was getting the error. It is now built because I entered the alt-abiv0-contrib-i386 directory and did a make contrib .

[ascendant]

I think glut can be removed from contrib/Demo/MesaEGL/mmakefile.src . I'm doing a full rebuild to verify. I'm also building the contrib master branch to see if there is a difference.

[deadwood]

Indeed, whenever you get a problem with missing library the place to look is the Development directory of the build output, not your host system.

As for build problems, on some systems dependiencies does not resolve in same system and something these things happen. Generally you can then manually build the missing component via specific mmake target and the continue the contrib build.

One note on the contrib, you need to to copy the repository to AROS directory, so the structure should be:

AROS
AROS/contrib
rebuild.sh

[ascendant]

Thanks, I do have the correct directory structure. I was unsure at first, but then I read the build scripts to verify this before starting this topic.

I just want to say that I don't think unresolveable build dependencies are just something you have to live with. I've compiled many programs both by hand and through automation without problems. It is my understanding that Arch Linux tries to make minimal modifications to software packages in order to get them to work in harmony on the OS. So I think it ought to rank high on a compatibility list for getting software to run on it.

I was able to get the master branch of the contrib repo to build perfectly cleanly, but this may just be coincidental. I'll look to see if there is a way to get this build system to ensure glut is indeed built before eglgears. I don't think removal of glut from MesaEGL/mmakefile.src is the right way to go as it is in the master branch also.

But beyond that, I found another problem trying to build alt-abiv0 (master was fine):

Code: [Select]

  CC     libcairo_gobject_la-cairo-gobject-enums.lo
  CC     libcairo_gobject_la-cairo-gobject-structs.lo
i386-aros-gcc: error: unrecognized command line option '-pthread'
i386-aros-gcc: error: unrecognized command line option '-pthread'
make[6]: *** [Makefile:493: libcairo_gobject_la-cairo-gobject-enums.lo] Error 1
make[6]: *** Waiting for unfinished jobs....
make[6]: *** [Makefile:500: libcairo_gobject_la-cairo-gobject-structs.lo] Error 1

I'll continue investigating.

[deadwood]

What I mean is that those missed dependencies are visible only on some systems. They are not visible on my system so I can't detect and solve them In your case they are, so you should be able to add dependency where needed.

As for cairo - I saw that before. This happens when when you host (linux) has cairo dev packages (development headers) installed. It looks like the configure script somehow "leaks out AROS build system".

[ascendant]

I think the -pthread problem is an issue in Cairo. I tried two ways to get rid of it from the builds which didn't work:

Code: [Select]

jlm@mcp:~/code/AROS_build/AROS/contrib 54> git diff development/libs/cairo/cairo-1.12.14-aros.diff development/libs/cairo/mmakefile.src
diff --git a/development/libs/cairo/cairo-1.12.14-aros.diff b/development/libs/cairo/cairo-1.12.14-aros.diff
index 7e7090c65..2dbf15ad3 100644
--- a/development/libs/cairo/cairo-1.12.14-aros.diff
+++ b/development/libs/cairo/cairo-1.12.14-aros.diff
@@ -104,6 +104,17 @@ diff -ruN cairo-1.12.14/configure cairo-1.12.14.aros/configure
 
 
 
+@@ -33201,8 +33201,8 @@
+       fi
+
+       if test "x$cairo_cc_flag" = "xyes"; then
+-              real_pthread_CFLAGS="-pthread";
+-               real_pthread_LIBS="";
++              real_pthread_CFLAGS="";
++               real_pthread_LIBS="-lpthread";
+                have_real_pthread=yes
+       else
+               real_pthread_CFLAGS="";
 diff -ruN cairo-1.12.14/configure.ac cairo-1.12.14.aros/configure.ac
 --- cairo-1.12.14/configure.ac 2013-01-29 13:54:51.000000000 +0000
 +++ cairo-1.12.14.aros/configure.ac    2022-12-21 10:58:55.751160236 +0000
diff --git a/development/libs/cairo/mmakefile.src b/development/libs/cairo/mmakefile.src
index 5ae4f9979..9b84ae564 100644
--- a/development/libs/cairo/mmakefile.src
+++ b/development/libs/cairo/mmakefile.src
@@ -14,6 +14,7 @@ CAIRO_OPTIONS= \
     --disable-lto \
     --disable-shared \
     --disable-xlib \
+    --disable-pthread \
     --disable-xcb png_CFLAGS=' ' \
     --libdir=$(AROS_LIB) \
     png_LIBS='-lpng' \

I see that Cairo is being configured to disable pthreads, and I see that the .diff file is being applied to Cairo's configure file to get rid of the -pthread option and replace it with -lpthread, but still it is failing. So somewhere else in Cairo it has hard-coded -pthread, which kind of defeats the purpose of using Autotools in the first place.

Update:
I see what you mean by the OS environment leaking into the AROS build system. I think somehow the Cairo configure script is getting info regarding glib, poppler, and gtk from my OS and using that to set some variables, adding -pthread to them. I'm seeing if there is a way to work around this "feature."

[ascendant]

I managed to find a way around the -pthreads getting itself into Cairo by setting these environment variables:

Code: [Select]

export GOBJECT_CFLAGS='-I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/include/sysprof-4 '
export GOBJECT_LIBS='-lgobject-2.0 -lglib-2.0 '
export LIBRSVG_CFLAGS='-I/usr/include/librsvg-2.0 -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/include/sysprof-4 -I/usr/include/libmount -I/usr/include/blkid -I/usr/include/gdk-pixbuf-2.0 -I/usr/include/libpng16 -I/usr/include/cairo -I/usr/include/freetype2 -I/usr/include/harfbuzz -I/usr/include/pixman-1 -I/usr/include/gtk-2.0 -I/usr/lib/gtk-2.0/include -I/usr/include/pango-1.0 -I/usr/include/fribidi '
export LIBRSVG_LIBS='-lrsvg-2 -lm -lgio-2.0 -lgdk-x11-2.0 -lpangocairo-1.0 -lpango-1.0 -lharfbuzz -lcairo -lgdk_pixbuf-2.0 -lgobject-2.0 -lglib-2.0 '
export POPPLER_CFLAGS='-I/usr/include/poppler/glib -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/include/sysprof-4 -I/usr/include/cairo -I/usr/include/libpng16 -I/usr/include/freetype2 -I/usr/include/harfbuzz -I/usr/include/pixman-1 -I/usr/include/poppler '
export POPPLER_LIBS='-lpoppler-glib -lgobject-2.0 -lglib-2.0 -lcairo '
export glib_CFLAGS='-I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/include/sysprof-4 '
export glib_LIBS='-lglib-2.0 '
export gtk_CFLAGS='-I/usr/include/gtk-2.0 -I/usr/lib/gtk-2.0/include -I/usr/include/pango-1.0 -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/include/sysprof-4 -I/usr/include/harfbuzz -I/usr/include/freetype2 -I/usr/include/libpng16 -I/usr/include/libmount -I/usr/include/blkid -I/usr/include/fribidi -I/usr/include/cairo -I/usr/include/pixman-1 -I/usr/include/gdk-pixbuf-2.0 -I/usr/include/atk-1.0 '
export gtk_LIBS='-lgtk-x11-2.0 -lgdk-x11-2.0 -lpangocairo-1.0 -latk-1.0 -lcairo -lgdk_pixbuf-2.0 -lgio-2.0 -lpangoft2-1.0 -lpango-1.0 -lgobject-2.0 -lglib-2.0 -lharfbuzz -lfontconfig -lfreetype '

I found these set in the config.log, but the CFLAGS included -pthread. Somewhere else I found a note indicating that if these were set via environment variables, then those would be used instead of taking them from the particular package. Interestingly enough, I was able to do a full build after this.

I don't think this is something that can be put into the build scripts as-is. I think the proper way to fix this is to gather these values from the system however Cairo's configure does it, then strip out the -pthread, and finally create environment variables out of them.