ID: 16351
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Feedback
+Status: Bogus
Bug Type: *Configuration Issues
Operating System: Solaris 8
PHP Version: 4.1.2
New Comment:
This is and never was PHP problem. I'd check my PATH
settings and such since it seems like you've somehow
got the compiler stuff screwed.
Reinstall everything? :)
--Jani
Previous Comments:
------------------------------------------------------------------------
[2002-04-02 08:34:56] [EMAIL PROTECTED]
Apache has started on SOLARIS2.8 with PHP-4.2.0-dev as a module.
I don't think it's a great deal, I am disappointed a little bit with
solaris.. I prefer Linux..
Nevertheless very great thanks for your help :-), I've a lot to learn
on my side.
Marcel
------------------------------------------------------------------------
[2002-04-02 07:42:21] [EMAIL PROTECTED]
I comment #include_next<limits.h> (line 117) in
/usr/local/lib/gcc-lib/sparc-sun-solaris2.8/2.95.2/include/limits.h
More in the phpxxx/ext/posix.c I add
#define NGROUPS_MAX 256
No the make seems to be done correctly, now I've to check if PHP work
correctly, I will give you the follow up in a couple of hour.
Great thanks for your help
------------------------------------------------------------------------
[2002-04-02 05:31:16] [EMAIL PROTECTED]
In file included from
/usr/local/lib/gcc-lib/sparc-sun-solaris2.8/2.95.2/include/limits.h:117,
from
/usr/local/lib/gcc-lib/sparc-sun-solaris2.8/2.95.2/include/syslimits.h:7
,
from
/usr/local/lib/gcc-lib/sparc-sun-solaris2.8/2.95.2/include/limits.h:11,
from zend_qsort.c:21:
/usr/include/limits.h:112: No include path in which to find limits.h
Hmm, seems like recursive recursion.
My guess is, that
/usr/local/lib/gcc-lib/sparc-sun-solaris2.8/2.95.2/include/limits.h:117,
has the exact same line?
Since this all depends on gcc symbols I think you need to report the
issue to the gcc list - nothing PHP can do about it. As a work-around
you might comment out the lines around line 117 in the file mentioned
above.
About resolv.h:
If you could omit the -lnsl/-lresolv/-lsocket statements during
compilation one by one, then we can safely assume that the resolver
functions will be available to you (affecting getmxrr and checkdnsrr).
The headers are correct - just -lnsl isn't used in testing, so that
could be a problem.
------------------------------------------------------------------------
[2002-04-02 05:10:09] [EMAIL PROTECTED]
With your data I created totofoo.c and the compile fails
when I remove
#include <netinet/in.h>
and only with this remove
// Inside limits.h line 112, here is the section
#ifdef _GCC_NEXT_LIMITS_H
#include_next <limits.h> /* recurse down to
the real one */
#endif
Nothing about POSIX_SOURCE ANSI_SOURCE in this file
About limits I've also a limits.h file in :
/usr/lib/gcc-lib/sparc-sun-solaris2.8/2.95.3/include/limits.h
Thanks for your help.
Marcel
------------------------------------------------------------------------
[2002-04-02 04:32:32] [EMAIL PROTECTED]
Ok. You don't have the resolv.h problem anymore, so ignore the warning,
on the pre-compile issue.
Just to see, whether this will at all work at solaris, could you try to
save this to a file:
#include <sys/types.h>
#include <netinet/in.h>
#include <arpa/nameser.h>
#include <resolv.h>
#include <netdb.h>
int
main ()
{
const char host[7]="php.net";
u_char ans[1024];
int r;
res_init();
/* Capture result in r but return 0, since a working nameserver is
* not a requirement for compilation.
*/
r = res_search( host, C_IN, T_MX, (u_char *)&ans, sizeof(ans));
return 0;
res_close();
;
return 0;
}
And compile it as:
gcc -o name name.c -lsocket -lresolv -lnsl
then strip of a lib and try again till it fails.
On the limits.h issue:
usually it includes a system specific limits file, like
machine/limits.h or sys/limits.h.
The gcc installation didn't really pick this up very well, looking at
that include chain.
Could you post the section around line 112 in limits.h?
Can you tell if POSIX_SOURCE/ANSI_SOURCE should be defined/not defined
somewhere to skip that include?
By the way: I had the same problem with the wchar.h file on a BSDi
system and my own gcc installation. I simply renamed the original
wchar.h to get rid of it - not a nice thing to do, but it works :-) -
with limits.h I'd be more careful though.
------------------------------------------------------------------------
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/16351
--
Edit this bug report at http://bugs.php.net/?id=16351&edit=1
