Okay, a couple things.
First, I reinstalled gcc to make sure it was synched with any new headers from
OS patching. Then I rebuilt apache2 (to get apr and apr-util) and then rebuilt
subversion. (By rebuilt I mean 'make extraclean' first...)
I still get the same problem as before, but I may have left out one detail in
my previous description which may be significant. When I build subversion as
described above, make fails here:
In file included from subversion/include/svn_pools.h:27,
from subversion/libsvn_delta/cancel.c:19:
/usr/local/apache2/include/apr.h:428:2: #error no decision has been made on
APR_PATH_MAX for your platform
By looking in /usr/include/limits.h, I see that PATH_MAX is (should be) set to
1024 if not defined. So if I edit apr.h to set APR_PATH_MAX to 1024 if not
defined (instead of throwing error) and try to rebuild subversion, THEN I get
the parse error in signal.h. Perhaps it is a mistake to set APR_PATH_MAX this
way? Is there something else I should try to correct the "no decision has been
made on APR_PATH_MAX" error?
If setting APR_PATH_MAX in this way is okay, then I guess I will continue
trying to determine what is going on with sigset_t by looking at preprocessor
output.
Thanks.
--- "Martin_v._Löwis" <martin@v.loewis.de> wrote:
> > Thanks for your help - been a decade or so since I've done any real
> C/C++... I
> > would like to know the root cause, though, others have not had this problem
> on
> > Solaris 2.8 using same apache2/subversion versions. My Solaris box recently
> had
> > patches applied, but maybe it still isn't completey patched up? Or is this
> > possibly an issue with the subversion build process?
>
> One possible cause may be that you have patched the system. Everytime a
> system header changes, the gcc installation may become incorrect.
>
> gcc copies a number of header files at installation time, and modifies
> them. If the system header changes, gcc's copies won't simultaneously
> change. You have to reinstall gcc, to invoke the "fixincludes" process
> again.
>
> It also may be that some header changes outright break gcc, so that even
> a re-installation won't help (e.g. when Sun manages to break a system
> header so that gcc cannot fix it).
>
> Notice that reinstalling gcc won't tell you what the problem is. I
> advise you to study the preprocessor output in more detail, to find out
> what sys/signal.h got replaced with.
>
> Regards,
> Martin
__________________________________
Do you Yahoo!?
The New Yahoo! Search - Faster. Easier. Bingo.
http://search.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sun May 4 18:16:27 2003