SlackwareThis Forum is for the discussion of Slackware Linux.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
I'm not convinced that this is actually a problem...at the end of the bug report it is stated that the original report was incorrect. 'aide' (which has a SlackBuild from slackbuilds.org) uses autoconf and includes mhash.h. Other than posting a bug report from 2008, do you have any actual evidence that this is a problem? Do you have any code that isn't compiling?
Even issuing `autoreconf --force` in the source directory for aide and then running `./configure && make` still works...so unless you can provide a real world scenario, I don't see this as a problem.
no, I just realized that asking to the guy that maintain alone a whole distribution to fix auto* warnings of unmaintaned sources maybe is not too fair (I've done myself too and now I ask forgiveness, sorry Pat).
Well if it is fixed in 0.9.9.9 despite being a non-issue perhaps a version bump is in order...
Which as far as current goes, appears to have already been bumped. 0.9.9.9 installed here.
edit:
Ok, now I'm completely confused.
Changelog this morning:
Quote:
l/mhash-0.9.9.9-x86_64-2.txz: Rebuilt.
Do not #define MUTILS_USE_MHASH_CONFIG in mhash.h. Thanks to guanx.
Now, if the bug was originally found in 0.9.9 back in Oct 2008 and according to sourceforge 0.9.9.9 was released december 2008 and the debian bug report is correct when it suggests that fixed it, then haven't we just applied a patch that shouldn't be necessary? And if so, isn't it possible that there could be side effects?
I haven't looked into any of this in detail, but this is looking a little messy.
Now, if the bug was originally found in 0.9.9 back in Oct 2008 and according to sourceforge 0.9.9.9 was released december 2008 and the debian bug report is correct when it suggests that fixed it, then haven't we just applied a patch that shouldn't be necessary? And if so, isn't it possible that there could be side effects?
I haven't looked into any of this in detail, but this is looking a little messy.
It's possible. Pretty much I was duped on this one into thinking it was more than just warnings. The usual policy is to not fix warnings at this level, especially ones related to autoconf.
But, it does seem correct to me anyway, and I doubt there will be any side effects. There might have been if the patch were applied right in the sources prior to compilation (as someone said would "probably be OK" or something in one of those bugs reports), but it's fixed up with sed after the "make install". I plan to leave it, but if it does cause problems let us know.
Ooops, Aide 0.15.1 no longer compiles on my current-64 box when "#define MUTILS_USE_MHASH_CONFIG" is commented out of /usr/include/mhash.h
Add it back in and it compiles fine again.
It figures. Reverting this one, and please folks, double check bug reports, and test compile (at least) update requests. Retweeting someone else's bugzilla is generally not helpful without independent verification. :/
Ooops, Aide 0.15.1 no longer compiles on my current-64 box when "#define MUTILS_USE_MHASH_CONFIG" is commented out of /usr/include/mhash.h
Code:
In file included from /usr/include/limits.h:153:0,
from /usr/lib64/gcc/x86_64-slackware-linux/4.5.2/include-fixed/limits.h:169,
from /usr/lib64/gcc/x86_64-slackware-linux/4.5.2/include-fixed/syslimits.h:7,
from /usr/lib64/gcc/x86_64-slackware-linux/4.5.2/include-fixed/limits.h:34,
from /usr/include/sys/param.h:26,
from commandconf.c:28:
/usr/include/bits/xopen_lim.h:95:6: error: missing binary operator before token "("
/usr/include/bits/xopen_lim.h:98:7: error: missing binary operator before token "("
make[3]: *** [commandconf.o] Error 1
make[3]: Leaving directory `/tmp/aide-0.15.1/src'
make[2]: *** [all] Error 2
make[2]: Leaving directory `/tmp/aide-0.15.1/src'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/tmp/aide-0.15.1'
make: *** [all] Error 2
Add it back in and it compiles fine again.
What not compiling is
Code:
#if ((int) (~0U >> 1)) == 32767
This is because the preprocessor does not do type conversions. It's the compiler's task. Therefore the stupid "INT_MAX" macro, if really wanted by mhash internally, should be elsewhere (e.g. in "mutils/mhash_config.h") rather than in "mutils/mincludes.h".
There is another reason to not have this INT_MAX macro -- The preprocessor integer does not necessarily have the same size as the compiler's. For example, in slackware-current, the preprocessor (~0U >> 1) is 2^63-1 and the compiler (~0U >> 1) is 2^31-1. So simply removing the "(int)" shoule not work.
Because this INT_MAX macro, as well as many other "#define"s, are only used internally in mhash and not in the mhash interface, they should not be exposed to the outside. I think THIS is the proper solution for your problem.
It depends on his coding philosophy if one should correct the wrong code, or should introduce more wrong code and let only some specific source compile. The "MUTILS_USE_MHASH_CONFIG" problem is such an example.
Thanks for the diagnosis guanx, and yes, I agree that the existing headers are ugly. and removing the brain-dead INT_MAX/MIN macro definitions from /usr/include/mutils/mincludes.h does indeed solve the build issue seen in AIDE, which seems to suggest that (at least in the case of AIDE) they're not a required part of the public interface to the library, and I suspect that they won't be used internally either as HAVE_LIMITS_H or HAVE_STDINT_H should have resulted in those values already being defined on linux.
Clearly, patching out MUTILS_USE_MHASH_CONFIG on its own isn't sufficient. So, the options seem to be:
1) Leave it as shipped by upstream
2) Patch out both MUTILS_USE_MHASH_CONFIG from mhash.h and INT_MAX/MIN from mutils/mincludes.h
(plus deal with any other issues that could show up in future)
The question then is: is this re-engineering of header files something within Pat's remit as a distro maintainer and something he should be doing? Though I'm a bit of a 'correctness freak' myself, in this case I tend to think that unless the headers as shipped by upstream are seen to be causing specific issues with builds then it's probably best to leave them as shipped, and that is in keeping with my understanding of Slackware's mimimal patching policy on this sort of thing.
Do you have any examples of the original upstream headers causing an actual problem?
Thanks for the diagnosis guanx, and yes, I agree that the existing headers are ugly. and removing the brain-dead INT_MAX/MIN macro definitions from /usr/include/mutils/mincludes.h does indeed solve the build issue seen in AIDE, which seems to suggest that (at least in the case of AIDE) they're not a required part of the public interface to the library, and I suspect that they won't be used internally either as HAVE_LIMITS_H or HAVE_STDINT_H should have resulted in those values already being defined on linux.
Clearly, patching out MUTILS_USE_MHASH_CONFIG on its own isn't sufficient. So, the options seem to be:
1) Leave it as shipped by upstream
2) Patch out both MUTILS_USE_MHASH_CONFIG from mhash.h and INT_MAX/MIN from mutils/mincludes.h
(plus deal with any other issues that could show up in future)
The question then is: is this re-engineering of header files something within Pat's remit as a distro maintainer and something he should be doing? Though I'm a bit of a 'correctness freak' myself, in this case I tend to think that unless the headers as shipped by upstream are seen to be causing specific issues with builds then it's probably best to leave them as shipped, and that is in keeping with my understanding of Slackware's mimimal patching policy on this sort of thing.
Do you have any examples of the original upstream headers causing an actual problem?
Hi GazL, Yes. Recently I've been using mhash. My program should be compatible with various compiler/libc's so the autoconf results of the "HAVE_*" macros are not always the same as those in "mhash_config.h". I saw no clean way to get rid of these conflictions. Including the aotuconf "config.h" after "mhash.h" doesn't work because the "HAVE_*" macros which shouldn't appear are not "#undef"ed, but simply commented out in the autoconf "config.h".
I do have a way to solve this problem: In a separate ".c" file, include only "mhash.h" and wrap the mhash functions, then export to other units with a separate ".h" file. But I think this solution looks funny.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
