AutoGen: The Automated Program Generator Activity
Brought to you by:
bkorb
Activity for AutoGen: The Automated Program Generator
-
Bruce Korb posted a comment on ticket #213
:) It's that bad for folks who like warnings as errors. A reasonable thing to do for project code. Probably, that shouldn't be done for configure probes. So, my project will be 4 bytes larger now. :-D
-
Florian Weimer posted a comment on ticket #213
It's not that bad, implicit ints are somewhat rare and easy to fix. The implicit function declarations are more work in my experience, but they also provide greater benefit to programmers (although I've seen bugs due to implicit ints as well).
-
config/ag_macros.m4 has a couple of bugs
-
Not defaulting to an "int" return type is a severe divergence from historical "C". Is that under the control of a cranked up warning level? That breaks the world. Anyway, I've applied your patch to my sources. If I can ever get "autoreconf" to work again, then I'll release it. :(
-
Pete Fordham posted a comment on ticket #213
Bug opened as part of this effort: https://fedoraproject.org/wiki/Toolchain/PortingToModernC
-
config/ag_macros.m4 has a couple of bugs
-
Thank you. I can't get it to build myself. The underlying infrastructure has been "improved" to the point where I have to adapt to the changes. Fixed now.
-
Martin Liška posted a comment on ticket #212
Thanks for the applied commit. I think it contains a small typo: diff --git a/agen5/defLoad.c b/agen5/defLoad.c index 99258cd6..c3f13254 100644 --- a/agen5/defLoad.c +++ b/agen5/defLoad.c @@ -470,7 +470,7 @@ read_defs(void) */ { size_t sz = data_sz + sizeof(long) + sizeof(*base_ctx); - base_ctx = (scan_ctx_t *)AGALOC(rsz, "file buf"); + base_ctx = (scan_ctx_t *)AGALOC(sz, "file buf"); memset(VOIDP(base_ctx), 0, sz); } base_ctx->scx_line = 1; as reported by: [ 15s] defLoad.c:468:41: error: 'rsz' undeclared...
-
If the putative undefined behavior actually becomes programmatically incorrect, then the compiler/OS implementation will be grossly incorrect. Meanwhile, this is only ever used if the defs are being read from a pipe or other source wherein you cannot determine its size. It should be pretty rare that it's ever used and when it's used, it will likely squander several microseconds. IOW, I'll make your suggested change. :) thank you.
-
Siddhesh Poyarekar posted a comment on ticket #212
Thanks to Martin's reduced reproducer in the gcc bug[1], I can now see what's going on. The trouble is that gcc is unable to associate the reallocation in: p = AGREALOC(VOIDP(base_ctx), dataSize + 4 + sizeof(*base_ctx), "expand f buf"); with pzData when p == base_ctx because the pointer is not explicitly updated. This happens to work with the glibc malloc implementation but strictly speaking, the comparison if (p != base_ctx) { is invoking undefined behaviour as the C standard states that the pointer...
-
P.S. the GCC bug's cause might be the temporary use of rem_sz for the allocation size. In the GIT sources, I've changed those 3 lines to 5, but I've not compiled or tested yet. { size_t sz = data_sz+sizeof(long)+sizeof(*base_ctx); base_ctx = (scan_ctx_t *)AGALOC(sz, "file buf"); memset(VOIDP(base_ctx), 0, sz); }
-
P.S. the GCC bug's cause might be the temporary use of rem_sz for the allocation size. In the GIT sources, I've changed those 3 lines to 5, but I've not compiled or tested yet. { size_t sz = data_sz+4+sizeof(*base_ctx); base_ctx = (scan_ctx_t *)AGALOC(sz, "file buf"); memset(VOIDP(base_ctx), 0, sz); }
-
P.S. the GCC bug's cause might be the temporary use of rem_sz for the allocation size. In the GIT sources, I've changed those 3 lines to 5, but I've not compiled or tested yet. { sz = data_sz+4+sizeof(*base_ctx); base_ctx = (scan_ctx_t *)AGALOC(sz, "file buf"); memset(VOIDP(base_ctx), 0, sz); }
-
autogen fails with -D_FORTIFY_SOURCE3
-
This exposes a GCC bug
-
Please close this issue.
-
It's GCC bug: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105217
-
Our analysis is not correct: rem_sz = data_sz+4+sizeof(*base_ctx); base_ctx = (scan_ctx_t *)AGALOC(rem_sz, "file buf"); memset(VOIDP(base_ctx), 0, rem_sz); base_ctx->scx_line = 1; rem_sz = data_sz; Note rem_sz is assigned data_sz, then data = (base_ctx + 1) means that data has room for rem_sz + 4. Thus fread(VOIDP(data), (size_t)1, rem_sz, fp); should be fine. Let me isolate a test-case.
-
That use definitely looks a bit odd; (char *)(base_ctx + 1) is actually not just 1 byte off, it's sizeof (scan_ctx_t) off, leading to fread going beyond bounds before sizeLeft is 0. As an aside, it seems like the code is looking to use scan_ctx_t with a flex array at the end, so it might make sense to simply add a char data[]; at the end of that struct.
-
That use definitely looks a bit odd; (char *)(base_ctx + 1) is actually not just 1 byte off, it's sizeof (scan_ctx_t) off, leading to fread going beyond bounds before sizeLeft is 0. As an aside, it seems like the code is looking to use scan_ctx_t with a flex array at the end, so it might make sense to simply add a char data[]; at the end of that struct.
-
autogen fails with -D_FORTIFY_SOURCE3
-
5.18.16: build fails with gcc 12.0.0.0
-
GCC bug
-
It's GCC bug: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104715
-
Tomasz Kłoczko created ticket #211
5.18.16: build fails with gcc 12.0.0.0
-
Hanspeter Niederstrasser created ticket #210
autogen-5.18.16 fails configure w/out autogen already installed
-
Sergei Trofimovich created ticket #209
guile-3 compatible release
-
Tomáš Korbař created ticket #208
Possible leaks in autogen 5.18.16
-
Andreas Metzler posted a comment on ticket #205
Andreas Metzler wrote Bruce Korb wrote [...] I cannot actually use that "--lgpl=2". If I do, then gnulib-tool errors out on incompatible modules. If I remove the modules, then the build errors out because needed packages are not present. The only failing module is timespec which is LGPLv3+ Looks like I was wrong here, I missed unlocked-io (GPLv3+).
-
Oops. I was turning on and off gnulib-tool options trying to figure out which were superfluous. It looks like I didn't put that one back. For x.96, I guess. :)
-
autogen 5.18.16 + git build error SPN_COMPACT_NAME_CHARS
-
The opts test failure I know about. I hit it and promise myself to fix it every time I bump the autogen version. :) See bug 207 :). I'll look into the directives thing, but it looks like versioning as well. Weirdly, I don't hit it, but with your failures tarball, I can likely see what caused it and fix it. Anyway, the specific issue raised here isn't happening, so I'm marking it as "pending" the next (5.20.0) release. Oh, there is an alpha.gnu.org version 5.19.95
-
opts.test fails when bootstrapping a new version of autogen
-
Hello Bruce, on current GIT ( tag v5.19.94 / 3a9b6e2f67bc09af74d6d184ea4d3ed77a11adce ) I get an almost successful build with env GNULIBDIR=/tmp/AUTOGEN/gnulib config/bootstrap && ./configure && make && make check. (Locally installed version of autogen on 5.8.16). Building suceeds, but there are two testsuite errors: FAIL: directives.test FAIL: opts.test agen5/test/test-suite.log FAIL: directives ================ creating directives.dir/subdir/directives.tpl creating directives.inc creating directives.def...
-
Good morning, thanks. License headers still say GPL3 since config/bootstrap.local was not updated with --lgpl=2.
-
I could use a hint here. I've not figured out how to build the stuff under OS/X and I'm not completely certain where the DYLD environment stuff gets dropped.
-
autogen 5.18.16 + git build error SPN_COMPACT_NAME_CHARS
-
Can this be reproduced with the pre-processing result? All of my {SPN,BRK}_*_CHARS macros return a pointer to a char. #define IS_COMPOUND_NAME_CHAR( _c) is_ag_char_map_char((char)(_c), 0x007B0460) #define SPN_COMPOUND_NAME_CHARS(_s) spn_ag_char_map_chars(_s, 30) #define BRK_COMPOUND_NAME_CHARS(_s) brk_ag_char_map_chars(_s, 30) #define SPN_COMPOUND_NAME_BACK(s,e) spn_ag_char_map_back(s, e, 30) #define BRK_COMPOUND_NAME_BACK(s,e) brk_ag_char_map_back(s, e, 30) #define IS_COMPACT_NAME_CHAR( _c) is_ag_char_map_char((char)(_c),...
-
configure uses mktemp --suffix, which is incompatible with non-GNU mktemp
-
fixed in alpha release 5.19.95
-
fixed for alpha release 5.19.95
-
AutoOpts includes non-dual-licensed code --> aggregated work GPLv3 (non BSD)
-
the unnecessary dependency on the vacuous timespec gnulib module has been removed. alpha release v5.19.95
-
alpha release 5.19.95
-
Back to the exec() problem. it seems to be in getdefs. That program invokes autogen as a server process. I think the right solution is to add code to ensure the DYLD stuff gets exported under a "#ifdef apple" guard.
-
5.19.90 tarball: ./configure has syntax errors (gl_FUNC_NANOSLEEP: command not found)
-
fixed in pre-release
-
../build-aux/run-ag.sh: 50: test: -o: unexpected operator'
-
Bash-ism. I use the idiom in the bootstrap code and have to remember to keep it away from build code.
-
../build-aux/run-ag.sh: 50: test: -o: unexpected operator'
-
Getting backslashes into the output is tricky. The text in the examples has to vary based on output type and then you have to futz with it long enough to figure out which works with which flavor. "Yummy", but thank you for raising the issue. I actually want to stay focused on getting criminals out of our government during the next 6 weeks, so I'll take a gander once I feel better about the state of our "leadership" (so to speak). I'm even putting photography aside. :-O
-
AutoOpts includes non-dual-licensed code --> aggregated work GPLv3 (non BSD)
-
Ah. One of many that I added. I'll ask the gnulib folks about it. It's a pretty trivial module.
-
Bruce Korb wrote [...] I cannot actually use that "--lgpl=2". If I do, then gnulib-tool errors out on incompatible modules. If I remove the modules, then the build errors out because needed packages are not present. The only failing module is timespec which is LGPLv3+
-
Bruce Korb wrote The acute accent diff is incorrect Ok, I thought I had doublechecked this dilgently. Pre-patch the manpage looked like this $ columns --first='#define TABLE' -c 2 -I4 --line=' ´ <<_EOF_ one two three four _EOF_ #define TABLE one two three four And with the patch like this: $ columns --first='#define TABLE' -c 2 -I4 --line=' \' <<_EOF_ one two three four _EOF_ #define TABLE \ one two \ three four The latter looks correct to me. And it is afaict exactly what can be found in the (html...
-
[patch] formatting/typo fixes
-
The acute accent diff is incorrect. In one case, I'm putting line splices at the end of each produced line (by the columns program), and I'm showing what that output looks like. The whole thing is enclosed in "@example" and "@end example" texi doc quotations. I've fixed the typos and those will be in the next release, thank you.
-
The lower bird is defending its source of sugar water. I cannot actually use that "--lgpl=2". If I do, then gnulib-tool errors out on incompatible modules. If I remove the modules, then the build errors out because needed packages are not present.
-
The lower bird is defending its source of sugar water. I cannot acutally use that "--lgpl=2". If I do, then gnulib-tool errors out on incompatible modules. If I remove the modules, then the build errors out because needed packages are not present.
-
Nice birds :-) This indeed seems to improve thing a lot: diff --git a/config/bootstrap.local b/config/bootstrap.local index 3aecd4b6..871e2029 100644 --- a/config/bootstrap.local +++ b/config/bootstrap.local @@ -171,6 +171,7 @@ run_gnulib_tool() { --import --lib=do_not_make_me --libtool + --lgpl=2 --local-dir=tmp --m4-base=config --makefile-name=gnulib.mk
-
[patch] formatting/typo fixes
-
Thank you!
-
I guess that's what I get for depending on gnulib. They change, I have to suck in a bunch more of that project and suddenly I'm screwed. I've actually been retired for 5 years and figured I'd spend a little time cleaning up hang-out items. I think I may be pulling at a thread in a knit sweater. (i.e. it's going to be endless.) I'll see if it's easy. If so, I'll fix it. If not, folks will just have to use a prior version. I have other things I do nowadays. (See attached.)
-
AutoOpts includes non-dual-licensed code --> aggregated work GPLv3 (non BSD)
-
[patch] formatting/typo fixes
-
Bruce Korb wrote: I've put up real tarballs now: 5.19.93. If they're okay, then the problem is with the construction of the source RPM. Good morning, Well I can verify that the new tarball seems to work. The rpm-included one had a literal gl_FUNC_NANOSLEEP in ./configure the new one does not. cu Andreas
-
5.19.90 tarball: ./configure has syntax errors (gl_FUNC_NANOSLEEP: command not found)
-
I surely do hate autotools, including the gnulib stuff. I don't see it because somehow or another the collection of gnulib m4 files show up in my tarball. autoconf (or something) expands those things into shell script code. Obviously, not for you. I've put up real tarballs now: 5.19.93. If they're okay, then the problem is with the construction of the source RPM.
-
5.19.90 - incorrect libopts soname (decreased)
-
I misunderstood the age thingy. It should remain 17.
-
5.19.90 tarball: ./configure has syntax errors (gl_FUNC_NANOSLEEP: command not found)
-
5.19.90 - incorrect libopts soname (decreased)
-
Thank you! I'm actually making a few updates to it, but it's not quite ready for prime time tho. So I've had X-Code installed since I first got my Mac and I've just installed MacPorts, but: Bruces-iMac:~ brucekorb$ sudo port install gnu-pw-mgr Password: sudo: port: command not found Obviously not installed correctly. How do I diagnose it? :) Thank you! On Thu, Sep 17, 2020 at 5:45 PM Ryan Schmidt ryandesign@users.sourceforge.net wrote: gnu-pw-mgr should be available in MacPorts https://www.macports.org/install.php...
-
Ryan Carsten Schmidt posted a comment on ticket #200
gnu-pw-mgr should be available in MacPorts within the hour: sudo port install gnu-pw-mgr
-
libintl.h is part of gettext, which Apple does not include in macOS; you would have to install gettext yourself, either by building it from source or installing it using a package manager like MacPorts or Homebrew. I assume the password manager you're referring to is gnu-pw-mgr? I could try adding it to MacPorts for easier installation.
-
It's too difficult to figure out when I cannot build GNU style source packages on my Mac. How do you do it? I tried to build my password manager, but it's insisting on a libintl.h header which is nowhere to be found. On 9/16/20 12:29 PM, Ryan Schmidt wrote: An alternative to messing with DYLD_LIBRARY_PATH, if it's too difficult to manually propagate it to everywhere it's needed, is to build the library with an install_name pointing to its location in the build tree. Then the tests should run just...
-
An alternative to messing with DYLD_LIBRARY_PATH, if it's too difficult to manually propagate it to everywhere it's needed, is to build the library with an install_name pointing to its location in the build tree. Then the tests should run just fine, since the library will be where its install_name says it is. Upon installation, relink the library with the install_name pointing to the final install location and relink all the programs that had been linked with the library during the build. The install_name...
-
DYLD environment variables are available to the autogen process, they're just not automatically propagated to subprocesses anymore. This is a new security measure introduced in OS X 10.11 as part of a feature Apple calls System Integrity Protection. Apple isn't trying to prevent programs from passing DYLD variables along manually, they just don't do so automatically anymore since that was a security vulnerability. Running the test suite on OS X 10.10 which does not have that protection, the test...
-
It all depends on when the DYLD stuff gets stripped out. I suspect it's the loader so that autogen the binary wouldn't find it, tho it could be the shell. Anyway, I think the proper thing would be to have our LibTool friends hide duplicates into MACOS_DYLD_xxx variables. Then I can add some magic OS/X specific code in a replacement exec() funciton.
-
You're right, dyld is the macOS-specific dynamic library loading mechanism, and the DYLD environment variables that can be used to modify its behavior are also macOS-specific. You're also right that libtool should handle this. libtool creates a script agen5/autogen which sets DYLD_LIBRARY_PATH and then launches the compiled executable agen5/.libs/autogen. I think the problem is related to the fact that autogen relaunches itself. When the getopt test fails, macOS generates two crash reports. Usually...
-
Should '-no-install' be removed?
-
It certainly doesn't make any sense to me now, either. That happened 3 years after I retired and since retirement I've been less than fully engaged in unpaid programming. :) Today, I'm trying to take pictures of hummingbirds fighting over sugar water. Anyway, I've removed that and am going through a build check for a 5.19.93 pre-release.
-
Should '-no-install' be removed?
-
Looks good to me, but strcpy should have been a void procedure from the get-go. Since we're fixing a warning triggered by a "we must warn about every conceivable issue", the return value from strcpy/strcpy_overlapping is ignored. May as well make this warning-go-away fix be scrupulous, too: static void strcpy_overlapping(char d, const char s) { memmove(d, s, strlen(s) + 1); } I'll be back from a wedding the end of March. On Tue, Feb 26, 2019 at 2:19 AM "Martin Liška" marxin@users.sourceforge.net...
-
autogen 5.18.16 + git build error SPN_COMPACT_NAME_CHARS
-
Just to be excruciatingly careful, I've added an explicit inclusion of ag-char-map.h in the compile, but it is also directly included in autoopts/project.h. It would be interesting to manually redo the compile with "-c" replaced with "-E" and the output redirected to a getdefs.i file. We can then see why the project.h header did not source in the ag-char-map.h file.
-
getopt.test test fails on macOS
-
I've never heard of DYLD environment variables before. Must be some OS/X-ism. I'm going to guess that the "run-ag.sh" script should hunt down the libopts..dylib from somewhere in the top_builddir and then set it. The proper fix is for the LibTool stuff figure it all out. the $top_builddir/agen5/autogen file is actually a script that is supposed to do the right thing. The binary that needs a mess of loader hints is named $top_builddir/agen5/.libs/autogen
-
Most tests fail
-
I've applied your patches, thank you. It rebuilds without problems on my platform, so they'll be included when I get 5.20 pushed out. Thanks again.
-
Thanks, that's promising. It got -L/opt/local/lib into the compile flags, but still not -lintl. With a little experimentation, I found that the changes to Makefile.am were not needed and the following changes let the tests (except getopt.test) pass: --- a/autoopts/test/defs.in +++ b/autoopts/test/defs.in @@ -283,7 +283,7 @@ compile() test "X${Dnam}" = "X" && Dnam="${testname}" d=`echo TEST_TEST_${Dnam}_OPTS | ${TR} '[a-z]-' '[A-Z]_'` - cc_cmd="${CC} ${CFLAGS} -D$d ${INC} -o ${Cexe} ${Csrc}.c ${LIB}"...
-
Since I'm not seeing it, would you be kind enough to try this patch? I think it should get the LD flags into the command line. diff --git a/autoopts/test/Makefile.am b/autoopts/test/Makefile.am index 33633e49..8c7ba791 100644 --- a/autoopts/test/Makefile.am +++ b/autoopts/test/Makefile.am @@ -34,6 +34,16 @@ TESTS = \ nls.test rc.test shell.test stdopts.test \ time.test usage.test vendor.test vers.test +TESTS_ENVIRONMENT = TERM='' \ + CFLAGS='$(CFLAGS)' \ + COMPILE='$(COMPILE)' \ + EXPRLIST="$(EXPRLIST)"...
-
Just to add, if nobody else sees this problem on macOS, maybe that's because nobody else is running the tests on macOS, or those who are aren't trying to do so with gettext. macOS doesn't ship with gettext so the user would have to install it themselves and configure autogen to use it. If I just run ./configure --disable-dependency-tracking ac_cv_func_utimensat=no make -j8 make check then it doesn't find gettext and all tests succeed (except one, for which I've filed bug #200). But if I have gettext...
-
getopt.test test fails on macOS
-
Most tests fail
-
I don't think you've got "gettext" installed properly. >>alias-compile> ccache /usr/bin/clang -pipe -Os -arch x86_64 -fno-strict-aliasing -DHAVE_CONFIG_H -DTEST_TEST_ALIAS_OPTS -I/path/to/autogen-5.18.16 -I/path/to/autogen-5.18.16/agen5 -I/path/to/autogen-5.18.16/autoopts -I/opt/local/include -o alias alias.c /path/to/autogen-5.18.16/autoopts/libopts_la-libopts.o Undefined symbols for architecture x86_64: "_gettext", referenced from: _AO_gettext in alias-24d154.o "_libintl_dgettext", referenced from:...
-
Well I'm the maintainer of gettext in MacPorts and I have over 150 other ports installed that use gettext, so I think gettext is installed correctly. I agree that the tests are failing because gettext symbols can't be found, but I think the reason for that is that the -L/opt/local/lib -lintl flags are not being used here in the tests. I don't know why that is though.
-
Most tests fail
-
I don't think you've got "gettext" installed properly. >>alias-compile> ccache /usr/bin/clang -pipe -Os -arch x86_64 -fno-strict-aliasing -DHAVE_CONFIG_H -DTEST_TEST_ALIAS_OPTS -I/path/to/autogen-5.18.16 -I/path/to/autogen-5.18.16/agen5 -I/path/to/autogen-5.18.16/autoopts -I/opt/local/include -o alias alias.c /path/to/autogen-5.18.16/autoopts/libopts_la-libopts.o Undefined symbols for architecture x86_64: "_gettext", referenced from: _AO_gettext in alias-24d154.o "_libintl_dgettext", referenced from:...
-
Most tests fail
1 >
