Strange build error

[Miro Kropáček]

Hi,

when trying to compile latest aranym (after plain ./configure), I get:

[mikro@pc build]$ make V=1
generating version_date.h
make  all-recursive
make[1]: Entering directory '/home/mikro/Projects/aranym.git/build'
Making all in src
make[2]: Entering directory '/home/mikro/Projects/aranym.git/build/src'
Making all in uae_cpu
make[3]: Entering directory '/home/mikro/Projects/aranym.git/build/src/uae_cpu'
depbase=`echo build68k.o | sed 's|[^/]*$|.deps/&|;s|\.o$||'`;\
gcc -DHAVE_CONFIG_H -I. -I../../../src/uae_cpu -I../..  -DOS_linux -DCPU_x86_64 -D_GNU_SOURCE -DDIRECT_ADDRESSING -DUNALIGNED_PROFITABLE -DX86_64_ASSEMBLY -DOPTIMIZED_FLAGS -DFPU_IEEE -DENABLE_EXCLUSIVE_SPCFLAGS "-I../../../src/uae_cpu/../include" "-I../../../src/uae_cpu/../Unix" "-I./.." "-I." "-I../../../src/uae_cpu"  -g -Wextra -Wall -Wundef -g -O2 -MT build68k.o -MD -MP -MF $depbase.Tpo -c -o build68k.o ../../../src/uae_cpu/build68k.c &&\
mv -f $depbase.Tpo $depbase.Po
gcc -g -Wextra -Wall -Wundef -g -O2   -o build68k build68k.o  -lm
./build68k <../../../src/uae_cpu/table68k > cpudefs.cpp
depbase=`echo gencpu.o | sed 's|[^/]*$|.deps/&|;s|\.o$||'`;\
gcc -DHAVE_CONFIG_H -I. -I../../../src/uae_cpu -I../..  -DOS_linux -DCPU_x86_64 -D_GNU_SOURCE -DDIRECT_ADDRESSING -DUNALIGNED_PROFITABLE -DX86_64_ASSEMBLY -DOPTIMIZED_FLAGS -DFPU_IEEE -DENABLE_EXCLUSIVE_SPCFLAGS "-I../../../src/uae_cpu/../include" "-I../../../src/uae_cpu/../Unix" "-I./.." "-I." "-I../../../src/uae_cpu"  -g -Wextra -Wall -Wundef -g -O2 -MT gencpu.o -MD -MP -MF $depbase.Tpo -c -o gencpu.o ../../../src/uae_cpu/gencpu.c &&\
mv -f $depbase.Tpo $depbase.Po
depbase=`echo readcpu.o | sed 's|[^/]*$|.deps/&|;s|\.o$||'`;\
g++ -DHAVE_CONFIG_H -I. -I../../../src/uae_cpu -I../..  -DOS_linux -DCPU_x86_64 -D_GNU_SOURCE -DDIRECT_ADDRESSING -DUNALIGNED_PROFITABLE -DX86_64_ASSEMBLY -DOPTIMIZED_FLAGS -DFPU_IEEE -DENABLE_EXCLUSIVE_SPCFLAGS "-I../../../src/uae_cpu/../include" "-I../../../src/uae_cpu/../Unix" "-I./.." "-I." "-I../../../src/uae_cpu"  -g -Wextra -Wall -Wundef -g -O2 -MT readcpu.o -MD -MP -MF $depbase.Tpo -c -o readcpu.o ../../../src/uae_cpu/readcpu.cpp &&\
mv -f $depbase.Tpo $depbase.Po
depbase=`echo cpudefs.o | sed 's|[^/]*$|.deps/&|;s|\.o$||'`;\
g++ -DHAVE_CONFIG_H -I. -I../../../src/uae_cpu -I../..  -DOS_linux -DCPU_x86_64 -D_GNU_SOURCE -DDIRECT_ADDRESSING -DUNALIGNED_PROFITABLE -DX86_64_ASSEMBLY -DOPTIMIZED_FLAGS -DFPU_IEEE -DENABLE_EXCLUSIVE_SPCFLAGS "-I../../../src/uae_cpu/../include" "-I../../../src/uae_cpu/../Unix" "-I./.." "-I." "-I../../../src/uae_cpu"  -g -Wextra -Wall -Wundef -g -O2 -MT cpudefs.o -MD -MP -MF $depbase.Tpo -c -o cpudefs.o cpudefs.cpp &&\
mv -f $depbase.Tpo $depbase.Po
g++ -g -Wextra -Wall -Wundef -g -O2   -o gencpu gencpu.o readcpu.o cpudefs.o  -lm
/usr/bin/ld: gencpu.o: in function `read_counts':
/home/mikro/Projects/aranym.git/build/src/uae_cpu/../../../src/uae_cpu/gencpu.c:105:(.text.startup+0xd4): undefined reference to `__isoc23_fscanf@GLIBC_DONT_USE_THIS_VERSION_2.38'
/usr/bin/ld: /home/mikro/Projects/aranym.git/build/src/uae_cpu/../../../src/uae_cpu/gencpu.c:107:(.text.startup+0x15c): undefined reference to `__isoc23_fscanf@GLIBC_DONT_USE_THIS_VERSION_2.38'
collect2: error: ld returned 1 exit status
make[3]: *** [Makefile:461: gencpu] Error 1
make[3]: Leaving directory '/home/mikro/Projects/aranym.git/build/src/uae_cpu'
make[2]: *** [Makefile:2318: all-recursive] Error 1
make[2]: Leaving directory '/home/mikro/Projects/aranym.git/build/src'
make[1]: *** [Makefile:488: all-recursive] Error 1
make[1]: Leaving directory '/home/mikro/Projects/aranym.git/build'
make: *** [Makefile:428: all] Error 2

I think it is related to this: https://codebrowser.dev/glibc/glibc/include/features.h.html#459 but this must have been introduced to glibc quite recently, the code would compile just fine a month ago.

I have no idea how to fix it.

--

http://mikro.atari.org

[Thorsten Otto]

On Freitag, 16. August 2024 13:51:28 CEST Miro Kropáček wrote:
> this must have been introduced to glibc quite recently, the code would
> compile just fine a month ago.

glibc 2.38 was released about a year ago (but i have that running on my
system, too). The error messages come from the attempt to redirect certain
glibc symbols to older version, so the resulting binary can be run on older
systems. However gencpu is a tool only used during building, and should not be
affected by this.

Did you run autogen.sh after you last updated your repo? Re-creating of
configure etc. is not automatically done when configure.ac and/or Makefile.am
changes.

[Miro Kropáček]

On Fri, 16 Aug 2024 at 14:23, Thorsten Otto <ad...@tho-otto.de> wrote:

Did you run autogen.sh after you last updated your repo? Re-creating of
configure etc. is not automatically done when configure.ac and/or Makefile.am
changes.

I did, it's a completely fresh copy.

--

http://mikro.atari.org

[Chris Ridd]

Is there some sort of extra “compat” type library that contains the non-standard versions of these functions?

Chris

--
You received this message because you are subscribed to the Google Groups "ARAnyM" group.
To unsubscribe from this group and stop receiving emails from it, send an email to aranym+un...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/aranym/CAN5rfbTgbJDJ7VM_ADuMR3DJHNQp1206NcofOFnfEKRM2QCbpA%40mail.gmail.com.

[Thorsten Otto]

On Freitag, 16. August 2024 15:31:32 CEST Chris Ridd wrote:
> Is there some sort of extra “compat” type library that contains the
> non-standard versions of these functions?

No, it is done by redirecting the symbols: https://github.com/aranym/aranym/
blob/master/src/include/linux/libcwrap.h

[Miro Kropáček]

On Fri, 16 Aug 2024 at 15:36, Thorsten Otto <ad...@tho-otto.de> wrote:

No, it is done by redirecting the symbols: https://github.com/aranym/aranym/
blob/master/src/include/linux/libcwrap.h

Ah OK, so there is something aranym-specific (I couldn't reproduce it with just a simple fscanf() test).

Could it be caused by the fact that my distro has glibc 2.40-1 installed?

--

http://mikro.atari.org

[Thorsten Otto]

On Freitag, 16. August 2024 15:38:55 CEST Miro Kropáček wrote:
> Could it be caused by the fact that my distro has glibc 2.40-1 installed?

That is possible. Last update of that header file was for glibc 2.38. You can
try running

./LibcWrapGenerator.pl --libdir /lib/x86_64-linux-gnu --target 2.14

in the tools directory, then check the generated libcwrap.h in that directory
for any new symbols. However for the ISOC23 functions, there is also some
trickery done in the system headers, hence the

/*
* avoid references to __isoc23_strtol*,
* which are only available in glibc >= 2.38
*/
#undef __GLIBC_USE_C2X_STRTOL
#define __GLIBC_USE_C2X_STRTOL 0

[Miro Kropáček]

On Fri, 16 Aug 2024 at 15:59, Thorsten Otto <ad...@tho-otto.de> wrote:

That is possible. Last update of that header file was for glibc 2.38. You can
try running

./LibcWrapGenerator.pl --libdir /lib/x86_64-linux-gnu --target 2.14

in the tools directory, then check the generated libcwrap.h in that directory
for any new symbols.

As I don't have library files in that path, I used /lib. Output attached. If I interpret it correctly, only a few exp() and log() variants were added.

However for the ISOC23 functions, there is also some trickery done in the system headers

Yes, there's a lot of weird stuff surrounding scanf functions as well so I'm attaching my stdio.h, too.

As a blind experiment I tried:

diff --git a/src/include/linux/libcwrap.h b/src/include/linux/libcwrap.h
index bf5d2496..5a36384e 100644
--- a/src/include/linux/libcwrap.h
+++ b/src/include/linux/libcwrap.h
@@ -25,6 +25,9 @@ extern "C" {

 #undef __GLIBC_USE_C2X_STRTOL
 #define __GLIBC_USE_C2X_STRTOL 0
 

+#undef __GLIBC_USE_DEPRECATED_SCANF
+#define __GLIBC_USE_DEPRECATED_SCANF 1
+
 #if defined(__i386__) || defined(__x86_64__)

and to my surprise, it seemed to help. But I have no clue whether this is the right fix.

--

http://mikro.atari.org

[Miro Kropáček]

On Fri, 16 Aug 2024 at 16:30, Miro Kropáček <miro.k...@gmail.com> wrote:

and to my surprise, it seemed to help. But I have no clue whether this is the right fix.

I spoke too soon. I was stopped by 

 

 /usr/include/stdlib.h:483:(.text.startup+0xe8): undefined reference to `__isoc23_strtol@GLIBC_DONT_USE_THIS_VERSION_2.38'

when linking aranym/aratapif. So it seems like the __GLIBC_USE_C2X_STRTOL hack has no effect anymore?

--

http://mikro.atari.org

[Miro Kropáček]

On Fri, 16 Aug 2024 at 16:36, Miro Kropáček <miro.k...@gmail.com> wrote:

So it seems like the __GLIBC_USE_C2X_STRTOL hack has no effect anymore?

Yes, because now it is __GLIBC_USE_C23_STRTOL. After this, linking succeeded. Phew.

--

http://mikro.atari.org

[Thorsten Otto]

On Freitag, 16. August 2024 16:37:30 CEST Miro Kropáček wrote:
> Yes, because now it is __GLIBC_USE_C23_STRTOL. After this, linking
> succeeded. Phew.

Yes, seems they have changed the symbol to check. I have the redirection to
isoc23_scanf already in glibc 2.38, but protected by

#if __GLIBC_USE (C2X_STRTOL)

Damn.

Since that hackery is a bit unstable, and seems to break with each new version
of glibc, i've also added an option now, which is disabled by default. That
means the resulting binary will run only on glibc versions atleast as new as
the system you build it on, but for local builds that is probably what you
want.

I also wonder how we should ever support such hacks in mintlib, when we don't
have such versioned symbols.