Menu
▾
▴
#2175 WSL: libmingwex.a lacks llround, llroundf, and llroundl functions
closed
Bug
fixed
IINR_-_Include_In_Next_Release
False
2017-12-18
2014-01-22
No
As noted in follow up of ticket [#2155], these three functions, all of which should be derived from the lround_generic.c source, are missing from the WSL build of libmingwex.a, whereas they were included in the mingwrt-3.x builds.
Related
Discussion
Diff:
Patch added.
Thanks, but I'm not going to accept any patch which proliferates redundant source file stubs, such as
asinh[fl].c,llround.c, andllround[fl].c; rather, I want to get rid of the few such redundancies which already exist, such asround[fl].c, andlround[fl].c, (and even the stubs currently provided forround.c, andlround.c, which may be conveniently replaced by renaminground_generic.c, andlround_generic.c, respectively).The crux of this issue is that, when you run make, the wrong pattern rules seem to be selected for targets such as
src/libcrt/math/fabs[fl].o, orsrc/libcrt/math/asinh[fl].o, whereas, when I run it, the correct rules are selected:The pattern rules are correct; we need to identify why they are not being selected correctly, when you run make.
I just followed the same scheme.
As posted earlier, make 3.82 is installed on my system, which is still the current one, but your version 3.81 is certainly still in use (e.g. its the one that comes with MSYS), and that is the only difference i can see here.
If you are only concerned about redundancy: with all the stub source files in place, the pattern rules for $(math_SOURCES) are actually not needed at all.
So the different behaviour seems to be caused by (make 3.82):
selecting the '$(SRCDIR)/%f.o: $(SRCDIR)/%.c' pattern rule, while yours (make 3.81) read:
selecting the more generic '%.o : %.c' pattern rule. To verify this, i just compiled make-3.81 from sources, and with this version i got the same result as you.
And looking at the Changelog of make, i found:
So this behaviour has indeed changed, and actually is visible in the .FEATURES variable.
Last edit: Keith Marshall 2014-01-24
Then, this is a regression in GNU make; we should file a bug report.
Seems back to front, to me. Surely, patterns should be prioritized on the basis of longest possible match first?
Yes, you did, by copying and adapting existing redundant files which should never have existed in the first place.
It is the redundancy of maintaining all those stub files, which should not be there at all, which I object to; they must be removed, so...
...they most definitely are. If we are to accommodate broken GNU make-3.82, maybe they need to be expressed as static pattern rules, but the redundant files must go.
Thorsten,
Following up on my own suggestion:
On this basis, I've created the attached alternative makefile fragment; could you please confirm that it delivers the appropriate result? For me, this is:
To test this, you will need to create a new build directory somewhere adjacent to, or within, your source tree; (I put it in
${top_srcdir}/build/foo). Drop the new Makefile in there, and adjust itstop_srcdirdefinition to the appropriate relative path. (I guess you'll also need to adjust theCCandARdefinitions to suit your own tool chain). In addition to this, you will need to:to get rid of the unwanted stub files, before you test this new make strategy.
i'm a bit surprised that you are so concerned about a few more files ;-)
After all, beside from the copyright notice, they all together contain no more code than the Makefile rules that are neccesary to properly compile them ;) It was just a quick solution to fix a problem that didn't exist in WSL 3.xx, if i went in the wrong direction, i apologize for that.
I'm not familiar with the internals of make, but i guess they had a reason to change that. And as expected, the same bevaviour is also present in make 4.00.
And even if someone there thinks this might be a bug,it took almost 3 years between release 3.82 and 4.00, so we can't expect that to be fixed soon, and it wont help for a cross-compiler, where you usually have to live with whatever make version is installed there, so we have to find a way to avoid that 'feature'.
Sure.
So this indeed does work, tested with all 3 make versions (3.81, 3.82 and 4.00).
PS.: while you are at it, the lengthy definition of w32api_lib_LIBRARIES is identical to
$(winapi_lib_LIBRARIES) $(winapi_lib_DDK_LIBRARIES) $(winapi_lib_DIRECTX_LIBRARIES) $(winapi_lib_DIRECTX_DINPUT_LIBRARIES) $(winapi_mri_LIBRARIES) $(winapi_lib_EXTRA_LIBRARIES)
computed near the top of the Makefile.
Yes, but that's a separate issue, perhaps more closely associated with my rant on ticket [#2172].
Related
Issues: #2172
I'm not concerned about a few extra files; I am concerned about the box of sticking plasters you want to use to shore up a crack in the design. The engineer in me wants to understand why that design isn't working as intended, and fix it; I do not want to paper over the cracks.
That is 23 lines of copyright declaration...
...over two lines of (barely copyrightable) effective code; how ludicrous is that? Especially given that one of those effective lines, in each case, is a
#definethat the properly implemented pattern rule would have passed as a-Dcommand line assignment, and the second is a#includeto compile the real source file, as the pattern rule would do directly.So that's 25 lines for each and every sticking plaster, (and we've already got 12 of them); that's already 300 lines of sticking plaster, instead of around a dozen or two lines (at most) in the Makefile. Your maths doesn't stack up...
But it isn't a solution; it's a kludge! Furthermore, I suspect that a proper solution will be just as simple, and perhaps even quicker to implement.
Perhaps it didn't exist, because it was implemented properly in 3.x; the original pattern rules had the design form:
(Yes, that's only six effective lines, compared to your 300 of sticking plaster, but there is a small additional overhead for special cases, such as the llround functions). The real issue here seems to be that the
_genericsuffix to the stem of the function name representation, in the associated source file name, got dropped from the pattern rules in 4.x, to be replaced by the first sticking plaster; that would likely be where it started going wrong.Sure enough, if I adapt the Makefile from my trial yesterday, as attached, reinstate the round_generic.c, and lround_generic.c sources, rename the asinh.c source to asinh_generic.c, and remove all the sticking plasters, I still achieve a successful outcome:
That's with exactly eight lines of effective makefile code, in pattern rules, versus 300 lines of sticking plaster. Unless you tell me this doesn't work for you, I'll work toward a solution on this basis.
Thats a bit unfair, not all of those 300 lines where from the patch ;)
And it is a common practice i've seen/used several times before, but those projects used automake mostly, and probably didnt want to rely on gmake features.
It does work, again tested with all 3 version of make.
The only small problem is that now
is always executed.
Even if it did exist, in native builds this would not have been noticed before, because msys 1.0 comes with make 3.81.
PS.: is there some better place to discuss general problems/suggestions?
Last edit: Thorsten Otto 2014-01-26
I didn't mean to imply that they were. Someone else had already started the rot; your patch just added to it. It's time to stop it.
Thanks. I guess this is the way to go, then. I'll work up a new patch, to integrate this into the existing Makefile.in; the rest of the rubbish can be cleaned up later -- better to progress gradually, than to rush headlong into too much too quickly.
Is that such a problem? I think not, really. Anyhow, this was just a proof of concept; a final implementation should address the dependency, such that libmingwex.a would be regenerated only when any of
libobjs/libmingwex-objects/*.o(or however else they may ultimately be called) changes.On the general MinGW-Users mailing list perhaps, or if you'd like to become more involved, consider joining the development team.
I committed this (on branch 4.0-dev only, for now). It's still hideously ugly -- and the ugliness made this patch more difficult to formulate than it should have been -- but a formal clean up will have to wait.
I presume this should be good to close, now.
mingwrt-4.xis dead, and buried; this issue should have gone with it, and should no longer arise with anymingwrt-3.xormingwrt-5.xrelease.