When trying to compile clanlib with -DNDEBUG set in order to generate a release version with ASSERT() macros turning into no-ops (which is ANSI-defined behaviour), the ebuild fails. Reproducible: Always Steps to Reproduce: 1.emerge =dev-tex/luatex-0.30.3 2. 3. Actual Results: Build failure Expected Results: Should build successfully The problem is that #ifdef NDEBUG is used correctly in some sections of the source file where debugging helper variables are defined, but not all the places which make use of those variables are actually put within #ifdef NDEBUG sections as well. The source therefore only compiles correctly if NDEBUG is *not* defined, which is clearly a portability bug in the source files because usage of NDEBUG is defined behavior in the ANSI C standard. Rationale: Compiling a C source file without NDEBUG defined actually results in compiling it in debugging mode, which is evident when reading the documentation of assert(). Such code might also execute slower than code compiled with NDEBUG, as additional debugging checks might be enabled which should be disabled for the final release builds.
Created attachment 185774 [details, diff] Fixes the problem Only a single source file is affected by the problem. By "-p1"-applying the accompanying patch to the top-level directory of the ebuild's unpacked source-tree, that source file is tricked into believing that NDEBUG has not been defined, no matter whether this is actually the case. The sources will therefore compile fine whether or not -DNDEBUG has been defined in CFLAGS.
Although the patch accompanying the previous comment fixes the problem for now, this is clearly a bug and should eventually be relayed to upstream.
Comment on attachment 185774 [details, diff] Fixes the problem while this is certainly a bug, that patch which undefines NDEBUG cannot be correct as it does just the contrary of what you want when defining NDEBUG
Created attachment 185927 [details, diff] Solves the problem w/o defining NDEBUG
(In reply to comment #3) > while this is certainly a bug, that patch which undefines NDEBUG cannot be > correct as it does just the contrary of what you want when defining NDEBUG Admittedly, it's certainly a dirty hack rather a clean fix... but it seemed to work. Nevertheless, I have uploaded a new patch which, instead of inserting a "#define NDEBUG", will replace all "#ifndef NDEBUG" by "#if 1". This should have the same effect for the #ifdefs, but without a requirement to define NDEBUG in a way which might contradict a global -DNDEBUG setting for the build. Alternatively, instead of applying that patch, the single command $ sed -i -e 's,#ifndef NDEBUG,#if 1,' \ luatex-beta-0.30.3/src/texk/web2c/luatexdir/tex/texnodes.c executed from within unpack() in the ebuild should achieve the same effect in a more compact manner. Actually, this is how I created the changes from which the new patch has been created.
I had started a patch which would have fixed this by applying #ifndef NDEBUG around all code sections using varmem_sizes, but I believe that this should actually be fixed upstream by a programmer who understands what the code is trying to achieve.
(In reply to comment #6) > around all code sections using varmem_sizes, but I believe that this should > actually be fixed upstream by a programmer who understands what the code is > trying to achieve. Well, initially I tried to do the same, and came to exactly the same conclusion. I just hoped there might be some people around here who are deeper familiar with the code and do know what it actually does. Well, it seems not so. And as obviously no-one feels an urge to dwelve into that code, I think we should indeed leave that to upstream. I am therefore closing the bug with resolution UPSTREAM and will try to relay a bug report to upstream. Let's hope they are responsive. For the meantime, I will post a portage override script here which fixes the problem by disabling NDEBUG temporarily.
Created attachment 189185 [details] /etc/portage/env/dev-tex/luatex Install this as /etc/portage/env/dev-tex/luatex on systems which have -DNDEBUG in their default CFLAGS. It will disable -DNDEBUG locally for that ebuild.
Hi all, I have just received a response from upstream as follows: > [...] You could try version 0.40.0 (released today) because I recall > having dealt with this bug report a few months ago (commit #1721, > added on January 2, based on a report by Bjørn Augestad). > > Nevertheless, I think it is madness to mark luatex as either > stable or released at this point in time, and handling it thus > is not supported. [...]
(In reference to comment #9) In the new light of upstream's own assessment of the package's maturity, one might consider masking this version. On the other hand, this may have consequences for other packages which rely on it. However, how "reliable" can dev-text/luatex be at this early point of development anyway? It's still a beta after all!
Obviously, it would be the best idea to check out the new 4.0 version and see whether the problem has indeed been fixed there. I therefore suggest we close this bug with resolution "REMIND" or "LATER".
please try with 0.60.1
(In reply to comment #12) > please try with 0.60.1 Works fine! Builds without any troubles on amd64 with -DNDEBUG active. Thanks a lot for the fine work!
