Thread: What's wrong with glibc-devel-2.2
YodaWu (yoda@cef.org.tw) reports a bug with a severity of 2 The lower the number the more severe it is. Short Description What's wrong with glibc-devel-2.2 Long Description This afternoon I download postgresql-7.1.tar.gz. After I extract this tarball,enter ./configure command to config this server. It was always blocked at the procedure of checking accept() function. After 5 hours of struggling I finally know the trouble source. The version of my glibc is 2.2,but seems postgresql based on glibc 2.1. So are there any plans of using glibc v2.2 ? Or I just only change source code of glibc from v2.2 to v2.1 ? It seems that glibc v2.2 is not compatible with v2.1 ,is it ? My English is very poor,thank you for finish reading. :) Sample Code No file was uploaded with this report
pgsql-bugs@postgresql.org writes:
> The version of my glibc is 2.2,but seems postgresql based on glibc 2.1.
Say what? Postgres isn't dependent on any particular version of glibc;
in fact it runs fine on many Unixen that don't use glibc at all.
How about telling us what your problem is, rather than jumping to a
conclusion about what caused it? What we want to see is exactly what
commands you issued and exactly what error messages you got.
regards, tom lane
pgsql-bugs@postgresql.org wrote: > This afternoon I download postgresql-7.1.tar.gz. > After I extract this tarball,enter ./configure command to config this > server. > It was always blocked at the procedure of checking accept() function. > After 5 hours of struggling I finally know the trouble source. > The version of my glibc is 2.2,but seems postgresql based on glibc 2.1. > So are there any plans of using glibc v2.2 ? I have built PostgreSQL 7.1 on a system with glibc-2.2 -- Red Hat 7.1. It works for me. There may be something else going onwith your system -- more details of your system configuration would be helpful. -- Lamar Owen WGCR Internet Radio 1 Peter 4:11
<yoda@cef.org.tw> writes:
> I think the key point is the define of accept() in 2.2.
> accept() define in glibc 2.2
> extern int accept (int __fd, __SOCKADDR_ARG __addr,
> socklen_t *__restrict __addr_len)
> __THROW;
> Definition of __SOCKADDR_ARG in glibc 2.2
> #if defined __cplusplus || !__GNUC_PREREQ (2, 7)
> # define __SOCKADDR_ARG struct sockaddr *__restrict
> # define __CONST_SOCKADDR_ARG __const struct sockaddr *
> #else
> Definition of __restrict in glibc 2.2
> /* __restrict is known in EGCS 1.2 and above. */
> #if !__GNUC_PREREQ (2,92)
> # define __restrict /* Ignore */
> #endif
Looks to me like it should work; int, struct sockaddr *, socklen_t *
are one of the combinations we try for accept() arguments. What does
config.log contain after the failure?
regards, tom lane
<yoda@cef.org.tw> writes:
> I think the key point is the define of accept() in 2.2.
> accept() define in glibc 2.2
> extern int accept (int __fd, __SOCKADDR_ARG __addr,
> socklen_t *__restrict __addr_len)
> __THROW;
> Definition of __SOCKADDR_ARG in glibc 2.2
> #if defined __cplusplus || !__GNUC_PREREQ (2, 7)
> # define __SOCKADDR_ARG struct sockaddr *__restrict
> # define __CONST_SOCKADDR_ARG __const struct sockaddr *
> #else
> Definition of __restrict in glibc 2.2
> /* __restrict is known in EGCS 1.2 and above. */
> #if !__GNUC_PREREQ (2,92)
> # define __restrict /* Ignore */
> #endif
After staring at this a little, I wonder whether the __restrict
qualifiers might be the problem. However, my compiler (gcc 2.95.3)
does not complain about this test program:
struct sockaddr { int x; };
typedef int socklen_t;
extern int accept (int __fd, struct sockaddr *__restrict __addr,
socklen_t *__restrict __addr_len);
extern int accept (int __fd, struct sockaddr * __addr,
socklen_t * __addr_len);
int main() { return 0; }
so at least in this version of gcc, it should not be a problem to
probe for accept's argument types without worrying about __restrict.
What compiler version are you using? Does it reject the above test
program?
regards, tom lane
On Tue, 17 Apr 2001, Tom Lane wrote:
> pgsql-bugs@postgresql.org writes:
> > The version of my glibc is 2.2,but seems postgresql based on glibc 2.1.
>
> Say what? Postgres isn't dependent on any particular version of glibc;
> in fact it runs fine on many Unixen that don't use glibc at all.
After I change the version from 2.2 to 2.1 , this problem solved.
I think the key point is the define of accept() in 2.2.
accept() define in glibc 2.2
extern int accept (int __fd, __SOCKADDR_ARG __addr,
socklen_t *__restrict __addr_len)
__THROW;
Definition of __SOCKADDR_ARG in glibc 2.2
#if defined __cplusplus || !__GNUC_PREREQ (2, 7)
# define __SOCKADDR_ARG struct sockaddr *__restrict
# define __CONST_SOCKADDR_ARG __const struct sockaddr *
#else
Definition of __restrict in glibc 2.2
/* __restrict is known in EGCS 1.2 and above. */
#if !__GNUC_PREREQ (2,92)
# define __restrict /* Ignore */
#endif
Thank you for your asistance ....:)
>
> How about telling us what your problem is, rather than jumping to a
> conclusion about what caused it? What we want to see is exactly what
> commands you issued and exactly what error messages you got.
>
> regards, tom lane
>
On Tue, 17 Apr 2001, Lamar Owen wrote: > I have built PostgreSQL 7.1 on a system with glibc-2.2 -- Red Hat 7.1. > It works for me. > > There may be something else going onwith your system -- more details of > your system configuration would be helpful. > -- > Lamar Owen > WGCR Internet Radio > 1 Peter 4:11 kernel 2.2.19 gcc 2.96 gmake 3.79.1 glibc 2.2 What else should I offer ? Should I change the /usr/src/linux to the directory of this kernel version ? Thank you for your asistance....:)