Horton
Menu

Thread

  1. What's wrong with glibc-devel-2.2

    PostgreSQL Bugs List <pgsql-bugs@postgresql.org> — 2001-04-17T13:26:31Z

    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

  2. Re: What's wrong with glibc-devel-2.2

    Lamar Owen <lamar.owen@wgcr.org> — 2001-04-17T15:38:59Z

    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

  3. Re: What's wrong with glibc-devel-2.2

    Tom Lane <tgl@sss.pgh.pa.us> — 2001-04-17T17:04:27Z

    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

  4. Re: What's wrong with glibc-devel-2.2

    yoda@cef.org.tw — 2001-04-17T18:59:14Z

    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....:)

  5. Re: What's wrong with glibc-devel-2.2

    yoda@cef.org.tw — 2001-04-17T19:10:37Z

    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
>

  6. Re: What's wrong with glibc-devel-2.2

    Tom Lane <tgl@sss.pgh.pa.us> — 2001-04-17T20:45:50Z

    <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

  7. Re: What's wrong with glibc-devel-2.2

    Tom Lane <tgl@sss.pgh.pa.us> — 2001-04-18T00:01:45Z

    <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