(strcmp(gnu_get_libc_version(), 2.3.3) 0)
Why not? Note the comparison. Since 2.3.3, this should be definitely
fixed.
Please use strverscmp() or something similar. According to strcmp, 2.3.10 is
smaller than 2.3.3.
--
Egmont
___
Hello,
On Thu, 21 Jul 2005, Roland Illig wrote:
Pavel Tsekov wrote:
On Thu, 21 Jul 2005, Roland Illig wrote:
What about this?
#ifndef HAVE_GNU_GET_LIBC_VERSION
# define may_use_getgrouplist() (TRUE)
#else
# include gnu/libc-version.h
# define may_use_getgrouplist() \
Koblinger Egmont wrote:
(strcmp(gnu_get_libc_version(), 2.3.3) 0)
Why not? Note the comparison. Since 2.3.3, this should be definitely
fixed.
Please use strverscmp() or something similar. According to strcmp, 2.3.10 is
smaller than 2.3.3.
Hmmm, you're right. As we are sure to
Hello,
On Thu, 21 Jul 2005, Leonard den Ottolander wrote:
Hi Pavel,
On Thu, 2005-07-21 at 14:17, Pavel Tsekov wrote:
Well, this was already discussed. It is not good enough. Let's do this the
right way. Addin a new option to mc.lib is not really a big deal. I think
we can add the new
On Fri, Jul 22, 2005 at 09:30:11AM +0200, Roland Illig wrote:
Hmmm, you're right. As we are sure to have a glibc, there's also a
function strverscmp, which we can use. I had known this issue, but as
glibc-2.2 only got upto 2.2.6, I thought it would suffice.
Also AFAIK current 2.3.5 is the
On Fri, Jul 22, 2005 at 10:07:11AM +0200, Koblinger Egmont wrote:
On Fri, Jul 22, 2005 at 09:30:11AM +0200, Roland Illig wrote:
Hmmm, you're right. As we are sure to have a glibc, there's also a
function strverscmp, which we can use. I had known this issue, but as
glibc-2.2 only got
Hi Pavel,
On Fri, 2005-07-22 at 09:14, Pavel Tsekov wrote:
Well, certain users may have patched 2.3.2 or 2.2.5 with a fixed
getgrouplist(). What you suggest would not allow them to use it .
Whether or not getgrouplist() is used is currently a compile time
option, which I think is fine. Working
Hello,
On Fri, 22 Jul 2005, Leonard den Ottolander wrote:
Hi Pavel,
On Fri, 2005-07-22 at 09:14, Pavel Tsekov wrote:
Well, certain users may have patched 2.3.2 or 2.2.5 with a fixed
getgrouplist(). What you suggest would not allow them to use it .
Whether or not getgrouplist() is used
Hi Pavel,
On Fri, 2005-07-22 at 14:32, Pavel Tsekov wrote:
How about reading the whole thread ?
I sort of did that but must have glanced too casually. What did I miss?
Leonard.
--
mount -t life -o ro /dev/dna /genetic/research
___
Mc-devel
Hello,
On Fri, 22 Jul 2005, Pavel Tsekov wrote:
Hello,
On Fri, 22 Jul 2005, Leonard den Ottolander wrote:
Hi Pavel,
On Fri, 2005-07-22 at 09:14, Pavel Tsekov wrote:
Well, certain users may have patched 2.3.2 or 2.2.5 with a fixed
getgrouplist(). What you suggest would not allow
Hi Pavel,
On Fri, 2005-07-22 at 14:45, Pavel Tsekov wrote:
Well, Roland suggested a much better fix.
http://mail.gnome.org/archives/mc-devel/2005-July/msg00282.html
Yes, I read that and that is probably the way to go for HEAD, but I
don't want that to go into PRE at this time. *Please* let's
Hello,
On Fri, 22 Jul 2005, Leonard den Ottolander wrote:
Hi Pavel,
On Fri, 2005-07-22 at 14:45, Pavel Tsekov wrote:
Well, Roland suggested a much better fix.
http://mail.gnome.org/archives/mc-devel/2005-July/msg00282.html
Yes, I read that and that is probably the way to go for HEAD,
Hi Pavel,
On Fri, 2005-07-22 at 15:00, Pavel Tsekov wrote:
Roland's patch looks good and it is pretty straight-forward. I vote for
its inclusion in PRE.
And totally untested. From a standpoint of a proper release procedure
and stabilizing the tree before a release instead of introducing
.
Would this be a correct implementation of that proposal? Patch only
affects configure.ac and doesn't check for getgrouplist() in case glibc
2.3.3 and the user hasn't overridden it --with-getgrouplist.
Note that I have hardly any experience with patching configure.ac files,
so if people agree
Leonard den Ottolander wrote:
On Fri, 2005-07-22 at 15:00, Pavel Tsekov wrote:
Roland's patch looks good and it is pretty straight-forward. I vote for
its inclusion in PRE.
And totally untested.
I have tested it on NetBSD/i386. The normal case works well, and I
have also simulated the
(3)
+dnl function, so we cannot use that function.
+AC_ARG_WITH(getgrouplist,
+ [ --with-getgrouplistForce using getgrouplist on patched glibc systems [[no]]])
+if test x$with_getgrouplist == xyes; then
+AC_CHECK_FUNCS([getgrouplist])
+else
+AC_MSG_CHECKING([for glibc version
if mc_glibc_ge_2_3_3 -eq 1; then
should read
if $mc_glibc_ge_2_3_3 -eq 1; then
--
mount -t life -o ro /dev/dna /genetic/research
___
Mc-devel mailing list
http://mail.gnome.org/mailman/listinfo/mc-devel
Leonard den Ottolander wrote:
Hi,
Of course you can't use strverscmp() like that. Another go. Probably
futile but hey.
Indeed. That's still buggy. And totally untested.
Roland
___
Mc-devel mailing list
Leonard den Ottolander wrote:
if mc_glibc_ge_2_3_3 -eq 1; then
should read
if $mc_glibc_ge_2_3_3 -eq 1; then
well, after
mc_glibc_ge_2_3_3=test 1
this makes even sense.
Roland
___
Mc-devel mailing list
Hi Roland,
On Fri, 2005-07-22 at 16:24, Roland Illig wrote:
Indeed. That's still buggy. And totally untested.
Well, yes, if you'd give me a hand as you know I have no experience with
patching configure.ac that would be nice.
Still, if this is done correctly it is far less likely to cause
Hello,
On Fri, 22 Jul 2005, Leonard den Ottolander wrote:
Hi Roland,
On Fri, 2005-07-22 at 16:24, Roland Illig wrote:
Indeed. That's still buggy. And totally untested.
Well, yes, if you'd give me a hand as you know I have no experience with
patching configure.ac that would be nice.
On Fri, Jul 22, 2005 at 03:24:37PM +0200, Leonard den Ottolander wrote:
On Fri, 2005-07-22 at 15:00, Pavel Tsekov wrote:
Roland's patch looks good and it is pretty straight-forward. I vote
for its inclusion in PRE.
And totally untested.
bah. there is no need to test a patch that can be
On Fri, Jul 22, 2005 at 08:43:51PM +0200, Roland Illig wrote:
Oswald Buddenhagen wrote:
i'd be opposed to this patch in general if it was not for the plainly
incorrect semantics of the old code.
Why this? [...]
Any questions left?
no, only an instruction: try to understand my statement
Oswald Buddenhagen wrote:
no, only an instruction: try to understand my statement another way (the
way i meant it). :-)
clarification: this patch relates to any freakin' getgroups problem
patch, not your patch. quoting the above sentence without the
preceeding one does not exactly further the
Hello,
On Thu, 21 Jul 2005, Leonard den Ottolander wrote:
How does one test for the availability of glibc in configure.ac, and for
glibc's version next?
Please, don't do this. The check should be made at runtime and not
configure time. Andrew's approach seems better to me. And it is not only
Hello,
On Thu, 21 Jul 2005, Roland Illig wrote:
Pavel Tsekov wrote:
Hello,
On Thu, 21 Jul 2005, Leonard den Ottolander wrote:
How does one test for the availability of glibc in configure.ac, and for
glibc's version next?
Please, don't do this. The check should be made at
Pavel Tsekov wrote:
On Thu, 21 Jul 2005, Roland Illig wrote:
What about this?
#ifndef HAVE_GNU_GET_LIBC_VERSION
# define may_use_getgrouplist() (TRUE)
#else
# include gnu/libc-version.h
# define may_use_getgrouplist() \
(strcmp(gnu_get_libc_version(), 2.3.3) 0)
#endif
Well, this
Hi Pavel,
On Thu, 2005-07-21 at 14:17, Pavel Tsekov wrote:
Well, this was already discussed. It is not good enough. Let's do this the
right way. Addin a new option to mc.lib is not really a big deal. I think
we can add the new option without adding a gui element to support it for
now.
Could
and, in src/utilunix.c, write
#if defined(HAVE_GETGROUPLIST) !defined(HAVE_GLIBC_2_3_2)
...
#endif
Roland
Index: configure.ac
===
RCS file: /cvsroot/mc/mc/configure.ac,v
retrieving revision 1.30
diff -u -p -r1.30 configure.ac
---
Hi Roland,
On Wed, 2005-07-20 at 21:08, Roland Illig wrote:
and, in src/utilunix.c, write
#if defined(HAVE_GETGROUPLIST) !defined(HAVE_GLIBC_2_3_2)
...
#endif
We shouldn't need to patch utilunix.c. Just don't do
AC_CHECK_FUNCS([getgrouplist]) in case of glibc version 2.3.2. Well,
that's
Hi,
How does one test for the availability of glibc in configure.ac, and for
glibc's version next?
Leonard.
--
mount -t life -o ro /dev/dna /genetic/research
___
Mc-devel mailing list
http://mail.gnome.org/mailman/listinfo/mc-devel
31 matches
Mail list logo
