I tried building apl-1.7.tar.gz, but running
./configure gave me:
svn: E155007:
'/home/moller/Downloads/apl-1.7/src/Archive.cc' is not a
working copy
and then build gives me:
g++ -DHAVE_CONFIG_H -I. -I.. -Werror -Wall -I
sql -rdynamic -g -O2 -MT apl-Avec.o -MD -MP -MF
.deps/apl-Avec.Tpo -c -o apl-Avec.o `test -f 'Avec.cc' || echo
'./'`Avec.cc
In file included from Svar_DB.hh:32,
from Symbol.hh:30,
from SystemVariable.hh:26,
from Quad_RL.hh:24,
from Workspace.hh:31,
from Assert.cc:28:
Svar_record.hh: In member function 'void
Svar_record::clear()':
Svar_record.hh:183:50: error: 'void* memset(void*,
int, size_t)' clearing an object of non-trivial type 'struct
Svar_record'; use assignment or value-initialization instead
[-Werror=class-memaccess]
void clear() { memset(this, 0,
sizeof(*this)); }
^
Svar_record.hh:174:8: note: 'struct Svar_record'
declared here
struct Svar_record
^~~~~~~~~~~
cc1plus: all warnings being treated as errors
make[3]: *** [Makefile:1838: apl-Assert.o] Error 1
make[3]: *** Waiting for unfinished jobs....
In file included from Svar_DB.hh:32,
from Symbol.hh:30,
from UserFunction.hh:29,
from Macro.hh:24,
from main.cc:38:
Svar_record.hh: In member function 'void
Svar_record::clear()':
Svar_record.hh:183:50: error: 'void* memset(void*,
int, size_t)' clearing an object of non-trivial type 'struct
Svar_record'; use assignment or value-initialization instead
[-Werror=class-memaccess]
void clear() { memset(this, 0,
sizeof(*this)); }
^
Svar_record.hh:174:8: note: 'struct Svar_record'
declared here
struct Svar_record
^~~~~~~~~~~
cc1plus: all warnings being treated as errors
make[3]: *** [Makefile:1796: apl-main.o] Error 1
mv -f .deps/apl-Avec.Tpo .deps/apl-Avec.Po
In file included from Svar_DB.hh:32,
from Symbol.hh:30,
from SystemVariable.hh:26,
from Quad_RL.hh:24,
from Workspace.hh:31,
from Archive.hh:28,
from Archive.cc:29:
Svar_record.hh: In member function 'void
Svar_record::clear()':
Svar_record.hh:183:50: error: 'void* memset(void*,
int, size_t)' clearing an object of non-trivial type 'struct
Svar_record'; use assignment or value-initialization instead
[-Werror=class-memaccess]
void clear() { memset(this, 0,
sizeof(*this)); }
^
Svar_record.hh:174:8: note: 'struct Svar_record'
declared here
struct Svar_record
^~~~~~~~~~~
cc1plus: all warnings being treated as errors
make[3]: *** [Makefile:1810: apl-Archive.o] Error
1
make[3]: Leaving directory
'/home/moller/Downloads/apl-1.7/src'
make[2]: *** [Makefile:3174: all-recursive] Error
1
make[2]: Leaving directory
'/home/moller/Downloads/apl-1.7/src'
make[1]: *** [Makefile:509: all-recursive] Error 1
make[1]: Leaving directory
'/home/moller/Downloads/apl-1.7'
make: *** [Makefile:396: all] Error 2
All this on Fedora release 28 (Twenty Eight)
[0] ~/Downloads/apl-1.7 >g++
--version
12:08:58
g++ (GCC) 8.1.1 20180502 (Red Hat 8.1.1-1)
Copyright (C) 2018 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.
There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A
PARTICULAR PURPOSE.
[0] ~/Downloads/apl-1.7 >uname
-a
12:09:42
Linux hpbox.mollernet.net 4.16.13-300.fc28.x86_64 #1 SMP Wed May
30 14:31:00 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux
[0] ~/Downloads/apl-1.7 >
I'm no C++ guy, but I was going to look more
closely into this when I got time. I've had other recent
problems with GCC 8.1, so I tend to suspect that, but that's
just a guess.
Chris
On 25/06/18 11:54, Juergen Sauermann
wrote:
Hi Chris,
even after a close look at the GNU APL code I can't see anything
wrong with how realpath() is being called.
To me it looks more like a bug in glibc 2.3, although the
valgrind message suggests that this bug causes no harm
(a memory area is copied to itself, which is an overlap but one
that causes no harm).
It also looks to me as if you are using an older GNU APL
version because I cannot
find the line in Libpath.cc that you quote below in the current
GNU APL code.
Thank you nevertheless for reporting this.
/// Jürgen
On 06/24/2018 02:29 PM, Chris Moller
wrote:
Doing some other stuff involving libapl.so, I
was running valgrind against my own code when this popped
up:
==14122== Source and destination overlap in
mempcpy(0x778a9e1, 0x778a9e1, 4)
==14122== at 0x4C34FF0: mempcpy (vg_replace_strmem.c:1524)
==14122== by 0x7E06634: realpath@@GLIBC_2.3
(in /usr/lib64/libc-2.27.so)
==14122== by 0x7441092: LibPaths::search_APL_lib_root()
(LibPaths.cc:186)
==14122== by 0x7441173: LibPaths::init(char const*, bool)
(LibPaths.cc:53)
==14122== by 0x7422B96: init_1(char const*, bool)
(Common.cc:77)
==14122== by 0x7509C09: init_libapl (libapl.cc:435)
==14122== by 0x4048F9: main (gapl.c:685)
The line in LibPaths.cc is:
unused = realpath(APL_lib_root, APL_lib_root);
which could obviously cause a collision.
I don't know if this is a real problem or not, but I thought
I ought to mention it to someone.
Chris Moller