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
