4:13 a.m.
>>>> "AO" == Alexandre Oliva
<aoliva(a)redhat.com> writes:
AO> The only problem I encountered with 21.1.13 was on Solaris 7/x86.
AO> Dumping xemacs crashes using unexsol2-6.c (the default), but it works
AO> with unexelf.c. You may want to change that for the next release.
AO> The compiler I use is GCC 2.95.2. Unfortunately, I don't have access
AO> to `cc' on this platform, so I can't tell whether it would have
AO> worked.
I have access to i386-pc-solaris2.8 and sparc-sun-solaris2.7, and
there are no dumping problems on these platforms (with gcc or cc). I
don't think anyone has reported problems on i386-pc-solaris2.7, so I
am inclined not to change something that has worked for many years.
As usual, if I can get access to your machine, I'll take a look at how
your xemacs build is different from mine, and debug the problem.
AO> Hope this helps.
Thanks for letting us know.
AO> Sorry about the long delay in answering.
All good free software hackers eventually become guilty of this.
8:46 p.m.
New subject: Alpha/Linux configure fix -- avoid /usr/shlib
On Jan 22, 2001, Martin Buchholz <martin(a)xemacs.org> wrote:
I have access to i386-pc-solaris2.8 and sparc-sun-solaris2.7, and
there are no dumping problems on these platforms (with gcc or cc). I
don't think anyone has reported problems on i386-pc-solaris2.7, so I
am inclined not to change something that has worked for many years.
Perfectly understandable :-)
I'll try to find a couple of spare minutes to investigate the failure
mode.
As usual, if I can get access to your machine, I'll take a look
at how
your xemacs build is different from mine, and debug the problem.
Unfortunately, I'm a guest on that machine myself, so I can't grant
you log in access.
AO> Sorry about the long delay in answering.
All good free software hackers eventually become guilty of this.
:-)
BTW, there's another issue in XEmacs that has been bothering me for a
while. It seems to have a very low limit on resolving soft links, and
I often get errors from ``Finding truename: Too many levels of
symbolic links''. It turns out that, because of various reasons, my
various cross-NFS-mounted home directories are a maze of soft-links,
and XEmacs imposes a lower limit than what would have been enough for
me. It hasn't annoyed me sufficiently for me to go hunt the culprit
piece of code and increase the limit myself, but... Any chance of
getting this limit increased a little bit? :-)
Thanks in advance,
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer aoliva(a){cygnus.com, redhat.com}
CS PhD student at IC-Unicamp oliva(a){lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist *Please* write to mailing lists, not to me
8:51 a.m.
New subject: Alpha/Linux configure fix -- avoid /usr/shlib
>>>> "AO" == Alexandre Oliva
<aoliva(a)redhat.com> writes:
AO> BTW, there's another issue in XEmacs that has been bothering me for a
AO> while. It seems to have a very low limit on resolving soft links, and
AO> I often get errors from ``Finding truename: Too many levels of
AO> symbolic links''. It turns out that, because of various reasons, my
AO> various cross-NFS-mounted home directories are a maze of soft-links,
AO> and XEmacs imposes a lower limit than what would have been enough for
AO> me. It hasn't annoyed me sufficiently for me to go hunt the culprit
AO> piece of code and increase the limit myself, but... Any chance of
AO> getting this limit increased a little bit? :-)
If changing the definition of MAX_READLINKS in src/realpath.c
#define MAX_READLINKS 32
to
#define MAX_READLINKS 64
fixes your problem, then I would accept that change for 21.1 and 21.2.
I don't know what Linux does now, but didn't it used to have an
incredibly low limit, like 5? One would think you would be using
Linux on one of your machines, given your email address...
So actually, I think you're hitting the Linux kernel or libc limit,
not the XEmacs limit.
I've occasionally thought about fixing this limit in the Linux kernel
and in libc, and in XEmacs. If you want to fix this, I'm probably
easier to convince than Linus or Uli.
8:17 p.m.
New subject: Alpha/Linux configure fix -- avoid /usr/shlib
On Jan 25, 2001, Martin Buchholz <martin(a)xemacs.org> wrote:
If changing the definition of MAX_READLINKS in src/realpath.c
#define MAX_READLINKS 32
to
#define MAX_READLINKS 64
fixes your problem, then I would accept that change for 21.1 and
21.2.
I'll give it a spin. But I doubt I've got this many links. It must
be something else.
I don't know what Linux does now, but didn't it used to have
an
incredibly low limit, like 5?
I don't know. I don't encounter the limit with any system calls, I
think it's just with pathname canonicalization as done by XEmacs. I
don't encounter any problem with GNU Emacs either. In fact, whenever
XEmacs fails to open a file with this kind of complaint, I go open it
with GNU Emacs and it works. Same machine, same pathname.
One would think you would be using Linux on one of your machines,
given your email address...
Sure :-)
But not only...
So actually, I think you're hitting the Linux kernel or libc
limit,
not the XEmacs limit.
I doubt it.
I've occasionally thought about fixing this limit in the Linux
kernel
and in libc, and in XEmacs. If you want to fix this, I'm probably
easier to convince than Linus or Uli.
If that were the case, I'd ping Uli about it. But I'm pretty sure it
isn't.
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer aoliva(a){cygnus.com, redhat.com}
CS PhD student at IC-Unicamp oliva(a){lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist *Please* write to mailing lists, not to me
4:25 a.m.
New subject: Alpha/Linux configure fix -- avoid /usr/shlib
>>>> "AO" == Alexandre Oliva
<aoliva(a)redhat.com> writes:
AO> On Jan 25, 2001, Martin Buchholz <martin(a)xemacs.org> wrote:
> If changing the definition of MAX_READLINKS in src/realpath.c
> #define MAX_READLINKS 32
> to
> #define MAX_READLINKS 64
> fixes your problem, then I would accept that change for 21.1 and
21.2.
AO> I'll give it a spin. But I doubt I've got this many links. It must
AO> be something else.
> I don't know what Linux does now, but didn't it used to
have an
> incredibly low limit, like 5?
AO> I don't know. I don't encounter the limit with any system calls, I
AO> think it's just with pathname canonicalization as done by XEmacs. I
AO> don't encounter any problem with GNU Emacs either. In fact, whenever
AO> XEmacs fails to open a file with this kind of complaint, I go open it
AO> with GNU Emacs and it works. Same machine, same pathname.
Hmmmm. Sure sounds like an XEmacs bug. The only thing I can think of
is ... automounter breakage?
A bug like this should be easy to fix. If one can reproduce it.
6:39 a.m.
New subject: XEmacs' pathname canonicalization versus Red Hat Linux 7's realpath()
On Jan 26, 2001, Martin Buchholz <martin(a)xemacs.org> wrote:
AO> I don't know. I don't encounter the limit with any system calls, I
AO> think it's just with pathname canonicalization as done by XEmacs. I
AO> don't encounter any problem with GNU Emacs either. In fact, whenever
AO> XEmacs fails to open a file with this kind of complaint, I go open it
AO> with GNU Emacs and it works. Same machine, same pathname.
Hmmmm. Sure sounds like an XEmacs bug. The only thing I can think
of
is ... automounter breakage?
A bug like this should be easy to fix. If one can reproduce it.
Ok, I have managed to get rid of the problem by not using realpath()
from glibc, using the one in XEmacs' sources instead.
The original pathname was
/home/guarana/aoliva/.lsd/public_html/contact where:
/home -> l/h
/l/h/guarana -> ../home/guarana
/l/home/guarana/aoliva/.lsd -> /home/lsd/oliva
/l/h/lsd -> /net/home.lsd.ic.unicamp.br/l/home/lsd
/net/home.lsd.ic.unicamp.br -> /.automount/home/root
/.automount/home/root/l/home -> x/home
/.automount/home/root/l/x/home/lsd/oliva/public_html -> /home/phd/oliva/public_html
/l/x/phd -> /net/eufrates/l/phd01
/net/eufrates -> /.automount/eufrates/root
Heh :-) No surprise it got in trouble :-)
The problem was that realpath() returned -1 for the full pathname.
Then, XEmacs attempted to iterate over each pathname component, but,
when it got to /l/home/guarana/aoliva/.lsd, realpath() returned -1.
resolved_path contained /net/home.lsd.ic.unicamp.br, and errno was
ELOOP.
Uli, is this a known problem? (Red Hat Linux 7's glibc 2.2-12) Any
chance of bumping up the maximum number of soft-links realpath()
follows (or whatever condition it uses to decide that it's got an
ELOOP), so that I don't have to rework my *apparently* insane
soft-link maze? :-)
Note that this is just one of the cases in which it fails for me.
I've got dozens of other examples, if you care...
Oh! And the only reason why GNU Emacs doesn't fail similarly is that
it just doesn't use realpath for pathname canonicalization.
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer aoliva(a){cygnus.com, redhat.com}
CS PhD student at IC-Unicamp oliva(a){lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist *Please* write to mailing lists, not to me
8513
days inactive
8517
days old
5 comments
2 participants
participants (2)
-
Alexandre Oliva -
Martin Buchholz