Re: Building m4 on BSDI 4.0.1
Stepan, I guess you may have found something there. The fact that this option is available again shows an acknowledgement that wchar.h has been an issue in the past. I have more e-mails to read in this thread, but is this the best solution or should the configure script itself be made smarter to handle this without the need for using the ac_cv_header_wchar_h=no manually? Thanks, Chris At 10:22 AM 12/14/2006, Stepan Kasal wrote: Hello, On Tue, Dec 12, 2006 at 01:21:02PM -0500, Chris McGuire wrote: mv /usr/include/wchar.h /usr/include/wchar.h.off I guess the following hack forces configure to ignore wchar.h: ./configure ac_cv_header_wchar_h=no Just a detail.
Re: Building m4 on BSDI 4.0.1
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Chris, and happy new year, According to Chris McGuire on 1/3/2007 7:41 AM: I guess the following hack forces configure to ignore wchar.h: ./configure ac_cv_header_wchar_h=no I guess you may have found something there. The fact that this option is available again shows an acknowledgement that wchar.h has been an issue in the past. Anything that autoconf caches can always be overwritten in this manner. Basically, you are just priming the cache to make the outcome match your goal rather than performing the autoconf test that gets the wrong answer. I have more e-mails to read in this thread, but is this the best solution or should the configure script itself be made smarter to handle this without the need for using the ac_cv_header_wchar_h=no manually? No. The best solution is for you to continue helping us improve gnulib's mbchar_.h so that it can work around your platform's broken wchar.h. Then things will just work out of the box for you, without you having to prime the cache. More in my followup to your other message. - -- Don't work too hard, make some time for fun as well! Eric Blake [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (Cygwin) Comment: Public key at home.comcast.net/~ericblake/eblake.gpg Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFm8PF84KuGfSFAYARAggcAJ4zqFIwKRTJPDgnXvPAhltFAvR85QCfUHu8 zhFKL80JrBxlQi9Zzr3ma0k= =XDti -END PGP SIGNATURE-
Re: Building m4 on BSDI 4.0.1
Hello, On Tue, Dec 12, 2006 at 01:21:02PM -0500, Chris McGuire wrote: mv /usr/include/wchar.h /usr/include/wchar.h.off I guess the following hack forces configure to ignore wchar.h: ./configure ac_cv_header_wchar_h=no Just a detail.
Re: Building m4 on BSDI 4.0.1
At 02:38 AM 12/13/2006, you wrote: Chris McGuire [EMAIL PROTECTED] writes: I suspect that it is just a matter of configure not applying changes it would make to BSD/OS 4.1 to my BSDI 4.0.1 box. Yes, most likely so. But to turn this vague idea into code that actually works for you, we need a concrete example of a simple C program that does not work on your host. Something like this: #include wchar.h #include sys/types.h wchar_t foo; or whatever the pattern is that makes your C compiler reject the program. To be very honest, this is beyond my knowledge...unfortunately. :( I would need something that I could simply cut and paste and you'd tell me what command(s) to run and test it. I'm sure you don't have time for that. But if you do, I'm more than willing to try. Wasn't the output of the build process that I sent along originally (showing where it failed) an example? On second thought, perhaps you should just remove /usr/include/wchar.h on your host. That solves your problem, and the file can't be doing you any good anyway. That is exactly what I did and it seems to work well. I only wonder if there is a replacement for wchar.h that would allow it to work properly or if autoconf or configure could be tweaked in future versions to apply what appears to be a known issue and fix for BSD/OS 4.1 to BSDI 4.0.1 as well? Thanks, Chris
Re: Building m4 on BSDI 4.0.1
Chris McGuire [EMAIL PROTECTED] writes: Wasn't the output of the build process that I sent along originally (showing where it failed) an example? Sorry, no, as the output doesn't contain a test program. if autoconf or configure could be tweaked in future versions to apply what appears to be a known issue and fix for BSD/OS 4.1 to BSDI 4.0.1 as well? I'm afraid that will happen only if you supply the tweak. I suspect that you're the only person in the world that still cares about portability of GNU applications to BSD/OS 4.0.1. So if you (or someone you hire :-) won't do the job, nobody will.
Re: Building m4 on BSDI 4.0.1
Chris McGuire [EMAIL PROTECTED] writes: To get m4 to build on my old BSDI 4.0.1 machine Hmm, that's software from a company (BSDI) that exists no longer. And the company's successor (Wind River Systems) discontinued support for BSD/OS at the end of 2004. Our usual rule is to not worry about platforms that the original supplier no longer supports, but in some cases we make exceptions. Are you actively using this machine in production, or is this more of a computer-museum situation? Anyway, if it is a production machine and if you have an obvious fix it might be nice to fix this in m4 and/or gnulib. Is there some simple test program that illustrates the bug in wchar.h? (I am assuming there is a bug there somewhere.)
Re: Building m4 on BSDI 4.0.1
At 07:44 PM 12/12/2006, you wrote: Chris McGuire wrote: I'll say I'm sorry up front if I'm not sending this to the proper people or in the proper format. My hope is to just provide you with a little feedback about an OS that you might not deal with much. The bug-m4@gnu.org list is a more appropriate forum. I did e-mail them and got a response. I'm including everybody in my responses. wchar.h is messed up on BSDI 4.0.1 and the newer m4 tries to find it and use it. It finds it and thinks it is okay to use, but it isn't. In order to teach M4 that BSDI's wchar is broken, and that M4's substitute wchar.h must be used instead, we must know what the failure scenario is. My original e-mail provided the output of a full ./configure, make, make install for both failed and successful tries. pico src/stackovf.c Replace 'ss_sp' with 'ss_base' That's a non-standard spelling, but easy enough to write a configure check for. See, you know what this means. I just know I need to make that edit. That is why I'm passing this info on to you guys so that you might be able to do something productive with it and save hacks like me hours down the road or be able to claim support for one more outdated OS. :) Yes, my box is an active web server with all modern versions of major Open Source software running. I'll move the customers off of there somebody. But since I hack at it to make it work, I figured I could at least try to give back a little of what I've come up with. I'm sorry that I can not provide you more details or a real patch. :( ln -s /usr/local/bin/m4 m4 Gross. Why not just './configure --prefix=/usr' in the first place? Sorry to disgust you. I'll use your way from now on. I hope the info about my probelms with wchar.h and ss_sp vs. ss_base may be able to help you implement a build process for BSDI 4.0.1 that will work smoothly in the future. I am doubtful that there will be a release of M4 1.4.9 unless other serious bugs turn up; and I highly doubt that BSDI, being an obsolete system, is well supported by libtool, which is a new prerequisite of the future M4 2.0 series. Since it appears to be a computer museum, the best you will probably get for now is your hacked build. That said, I'm still interested in simple patches that make M4 portable even to obsolete systems, where such patches are not a maintanence nightmare. Eric, most of this is addressed above. But if there is something more I can provide I will try. Thanks, Chris -- Eric Blake
