Mail Archives: cygwin/2004/04/27/09:11:22
At 12:07 AM 4/27/2004, you wrote:
>Igor Pechtchanski wrote:
>
>>On Mon, 26 Apr 2004, Carlo Florendo wrote:
>>
>>
>>>Larry Hall wrote:
>>>
>>>
>>>>At 11:28 PM 4/25/2004, you wrote:
>>>>
>>>>
>>>>>Hi,
>>>>>
>>>>>Now, upon running ./configure on blackbox, all was ok. When I started make, this is the error I got:
>>>>>
>>>>>Making all in src
>>>>>Window.cc:1396: error: `assert' undeclared (first use this function)
>>>>>Window.cc:3234: error: `assert' undeclared (first use this function)
>>>>>
>>>>Clearly the problem is that you're missing "#include <assert.h>". That's
>>>>likely the result of a configure problem but I didn't investigate to any
>>>>great extent so I might be wrong.
>>>>
>>>Right! When I added "#include <assert.h>", blackbox compiled clearly.
>>>How come it didn't complain in the past cygwin? I compiled the same
>>>blackbox at a linux box (without my added "#include <assert.h>") and the
>>>thing built perfectly. How come the new cygwin behaves differently?
>>>
>>>Thanks!
>>>
>>>Best Regards,
>>>Carlo
>>>
>>
>>Well, as a WAG, assert.h could have been #included in some standard header
>>file before, and isn't now. This indicates buggy software, BTW: it
>>shouldn't rely on anything else including the needed functionality --
>>that's what the double include guards are for. The rule of thumb is:
>>"when in doubt, include it". You might want to submit a patch to the
>>blackbox maintainers.
>> Igor
>I installed the exact blackbox version as last time which is the latest official release. This latest official release has one file that calls assert() but does not #include it. I checked its include tree and, as far as I looked, have not found the #include <assert.h> anywhere on the tree. Other files that call assert have the header included in them. The strangest thing is that the same version
>compiles under the current linux that I have (Redhat 9.0), the former cygwin, but *not* the latest cygwin. It compiles with the latest cygwin if I #include <assert.h> on the file in question.
>
>Does this mean that there is a problem with gcc? or configure? I'm confused now whether the problem resides in the packaging of blackbox,
>in the way ./configure runs on the old cygwin, or on the way ./configure runs on the new cygwin, or in Linux or even in gcc. Why doesn't gcc complain in the old cygwin and in Linux?
>
>I could submit a patch to the blackbox maintainers but will have to tell them that the reason for it is so that it will compile with the latest cygwin. Or could it be that ./configure needs to be patched?
>
>Thanks a lot!
There could be many different reasons for this, in theory, as you've
surmised. But the only one that matters is the one causing the problem.
If you have access to Linux (which it seems you do), you have the perfect
setup to compare the differences for this package and come to a conclusion.
But I concur with Igor. To me, if a source file uses some facility, it
should include what's necessary for that facility. If it doesn't, it's
broken.
--
Larry Hall http://www.rfk.com
RFK Partners, Inc. (508) 893-9779 - RFK Office
838 Washington Street (508) 893-9889 - FAX
Holliston, MA 01746
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
- Raw text -