Hi Omar -- On 1/25/2022 5:36 AM, Omar Polo wrote: > Hello, > > algol68g saw some further developments recently with a major version > released some time ago. Among various things, it also includes the fix > for the usleep issue we found :) >
I took at quick look at this. It looks like upstream still gets the check wrong though. IIRC, it checks to see if the return value for usleep is EINTR instead of the return value being -1 and errno being set to EINTR. > https://jmvdveer.home.xs4all.nl/en.download.algol-68-genie-current.html > > The build system changed slightly. Now there's a Makefile.bsd which > should allows us to avoid using autotools, but it builds only a > stripped-down version of the interpreter and has some further issues of > its own, so I'm not sticking with the autotools. > > The configure script does some things wrong, like checking for compiler > features that are not actually used (and fails) or failing to picking up > ncurses. > > The dependency on GSL has been dropped because a68g needs a newer > version that we have. To avoid surprises when devel/gsl will be > eventually updated, I'm explicitly disabling gsl support for now. > > Tests are all passing on amd64 and i386 with the only exception of > 19-quicksort-parallel.a68 that fails because it spawns more threads than > allowed to. > > Compiling algol68 code however doesn't work: > > % echo 'print (("hello world", new line))' > hello.a68 > % a68g --compile hello.a68 > % ./hello > a68g:./.a68g.tmp.hello.so: undefined symbol 'common' > a68g:./.a68g.tmp.hello.so: undefined symbol 'single_step' > a68g: exiting: ./src/a68g/a68g.c: 506: cannot resolve symbol, Cannot load > specified object > > The compiler works in a peculiar way. It translates (part?) of the > source code into C which is then compiled into a shared library. The > produced executable just spawns a68g with the correct flags so it > dlopen(3)s the shared library and executes the code. > > The issue is that the produced shared object has references (`common' > and `single_step') to symbols that should be provided by the binary but > are not actually exported: > > % nm .a68g.tmp.hello.so > 00002618 c _DYNAMIC > 00001580 t __llvm_retpoline_r11 > 00002610 r __retguard_507 > U common > 000013d0 T genie_closed_55 > 00000000 F hello.c > U pthread_self > U single_step > % nm /usr/local/bin/a68g | grep single_step > % nm /usr/local/bin/a68g | grep common > > and I have zero idea of how to avoid this. > > In the hope something stands out, here's the two chunk of code from > a68g.c where the executable is produced > > 442 ASSERT (snprintf (options, SNPRINTF_SIZE, > "%s -g -I${TRUEPREFIX}/include", optimisation_option ()) >= 0); > 443 #if defined (HAVE_PIC) > 444 bufcat (options, " ", BUFFER_SIZE); > 445 bufcat (options, HAVE_PIC, BUFFER_SIZE); > 446 #endif > 447 ASSERT (snprintf (cmd, SNPRINTF_SIZE, "cc %s -c -o \"%s\" \"%s\"", > options, FILE_BINARY_NAME (&A68_JOB), > FILE_OBJECT_NAME (&A68_JOB)) >= 0); > 448 ABEND (system (cmd) != 0, ERROR_ACTION, cmd); > 449 ASSERT (snprintf (cmd, SNPRINTF_SIZE, > "ld -export-dynamic -shared -o \"%s\" \"%s\"", > FILE_LIBRARY_NAME (&A68_JOB), > FILE_BINARY_NAME (&A68_JOB)) >= 0); > 450 ABEND (system (cmd) != 0, ERROR_ACTION, cmd); > 451 a68_rm (FILE_BINARY_NAME (&A68_JOB)); > > and loaded > > 501 // First load a68g itself so compiler code can resolve a68g symbols. > 502 a68_lib = dlopen (NULL, RTLD_NOW | RTLD_GLOBAL); > 503 ABEND (a68_lib == NULL, ERROR_RESOLVE, dlerror ()); > 504 // Then load compiler code. > 505 compile_lib = dlopen (libname, RTLD_NOW | RTLD_GLOBAL); > 506 ABEND (compile_lib == NULL, ERROR_RESOLVE, dlerror ()); > > > Cheers, > > Omar Polo > I had a half-finished diff that was a little different than yours. I'll triangulate and see if I can't figure out this shared object issue in the test over the new few days. Thanks! ~Brian
