* removing old installations
@ 2011-06-25 17:34 Eric Abrahamsen
2011-06-25 19:58 ` Peter Dyballa
2011-06-26 6:08 ` Andreas Röhler
0 siblings, 2 replies; 7+ messages in thread
From: Eric Abrahamsen @ 2011-06-25 17:34 UTC (permalink / raw
To: help-gnu-emacs
I'm running the Ubuntu repository version of emacs (23.2.1) on Natty. In
the past I've tried compiling both emacs 24 and emacs 23 myself on this
machine, before deciding it was unnecessary and just using the
repository version. As near as I can tell I've cleared the old 24 and 23
installations out of my system, but leftover files are still interfering
with byte compilation in my present system.
Makefiles in external packages like gnus or org-mode set the executable
to "emacs" (ie, no full path). There are no other "emacs" executables on
my path, but still I need to change the makefiles to specify
"/usr/bin/emacs", or else I pick up weird bits from emacs 24, and my
compiled files behave strangely (I can provide more details). Even with
the full path to emacs specified, I get these warnings with each byte
compilation:
Warning: Lisp directory `/usr/local/share/emacs/23.2/site-lisp' does not exist.
Warning: Lisp directory `/usr/local/share/emacs/site-lisp' does not exist.
All my site-lisp directories are under /usr/share/emacs or
/usr/share/emacs23, and I don't know what configuration or startup files
are telling it to look under /usr/local/share.
Given that no other "emacs" executables are on my system (at least, to
the best of my knowledge, and I spent a while rooting them out), what
other leftover files could be confusing my present installation?
Thanks!
Eric
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: removing old installations
2011-06-25 17:34 removing old installations Eric Abrahamsen
@ 2011-06-25 19:58 ` Peter Dyballa
2011-06-25 22:57 ` Eric Abrahamsen
2011-06-26 6:08 ` Andreas Röhler
1 sibling, 1 reply; 7+ messages in thread
From: Peter Dyballa @ 2011-06-25 19:58 UTC (permalink / raw
To: Eric Abrahamsen; +Cc: help-gnu-emacs
Am 25.06.2011 um 19:34 schrieb Eric Abrahamsen:
> Given that no other "emacs" executables are on my system (at least, to
> the best of my knowledge, and I spent a while rooting them out), what
> other leftover files could be confusing my present installation?
With locate (or find) you can find all instances of "emacs" and also
"emacs-23.2" and "emacs-24.0.50" and remove them. The same for the
version sub-directories "23.2" and "24.0.50" in /usr/local/libexec/
emacs and /usr/local/share/emacs.
You can launch that "emacs" binary in your PATH and choose from the
Help menu "Send Bug Report…" or type M-x report-emacs-bug RET. In the
*unsent mail to bug-gnu-emacs@gnu.org* buffer you'll find a text
describing where and how this "emacs" was built.
Finally you can use the trace utilities to see which files and
directories these "emacs" executable files open.
--
Greetings
Pete
How many Microsoft engineers does it take to screw in a light-bulb?
None.
They just redefine "dark" as the new standard.
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: removing old installations
2011-06-25 19:58 ` Peter Dyballa
@ 2011-06-25 22:57 ` Eric Abrahamsen
2011-06-26 14:18 ` Peter Dyballa
0 siblings, 1 reply; 7+ messages in thread
From: Eric Abrahamsen @ 2011-06-25 22:57 UTC (permalink / raw
To: help-gnu-emacs
On Sat, Jun 25 2011, Peter Dyballa wrote:
> Am 25.06.2011 um 19:34 schrieb Eric Abrahamsen:
>
>> Given that no other "emacs" executables are on my system (at least, to
>> the best of my knowledge, and I spent a while rooting them out), what
>> other leftover files could be confusing my present installation?
>
>
> With locate (or find) you can find all instances of "emacs" and also
> "emacs-23.2" and "emacs-24.0.50" and remove them. The same for the
> version sub-directories "23.2" and "24.0.50" in
> /usr/local/libexec/emacs and /usr/local/share/emacs.
>
> You can launch that "emacs" binary in your PATH and choose from the
> Help menu "Send Bug Report…" or type M-x report-emacs-bug RET. In the
> *unsent mail to bug-gnu-emacs@gnu.org* buffer you'll find a text
> describing where and how this "emacs" was built.
>
> Finally you can use the trace utilities to see which files and
> directories these "emacs" executable files open.
Thanks for these tips! If you have a moment I hope you'll look at this
one step further.
I'm quite sure I've removed everything emacs-related from /usr/local/*.
One odd thing is, my emacs man file is located at
/usr/share/man/man1/emacs.1.gz (symlinked from
/etc/alternatives/emacs.1.gz), but within the FILES section of that man
page, it gives all the emacs-related paths as /usr/local/*. Not sure
what that's about.
The bug report data shows that emacs was compiled by Debian. I note that
--enable-locallisppath includes, among many other paths, the two paths
that emacs complains about when it's run from the command line.
Among the voluminous output of strace is:
access("/usr/local/share/emacs/23.2/site-lisp", F_OK) = -1 ENOENT (No such file or directory)
write(2, "Warning: Lisp directory `/usr/lo"..., 80) = 80
access("/usr/local/share/emacs/site-lisp", F_OK) = -1 ENOENT (No such file or directory)
write(2, "Warning: Lisp directory `/usr/lo"..., 75) = 75
But the same trace is absolutely stuffed with stat64 calls to half a
million non-existent files and directories (including lots of /usr/local
stuff), so I don't know why that should merit an error. If you or anyone
else is really interested, I've put a large chunk of the trace here:
http://pastebin.com/paWFrRGh
Is my only problem that emacs was compiled with some non-existent
directories in the lisploadpath?
Thanks,
Eric
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: removing old installations
2011-06-25 17:34 removing old installations Eric Abrahamsen
2011-06-25 19:58 ` Peter Dyballa
@ 2011-06-26 6:08 ` Andreas Röhler
2011-06-27 3:42 ` Eric Abrahamsen
1 sibling, 1 reply; 7+ messages in thread
From: Andreas Röhler @ 2011-06-26 6:08 UTC (permalink / raw
To: help-gnu-emacs
Am 25.06.2011 19:34, schrieb Eric Abrahamsen:
> I'm running the Ubuntu repository version of emacs (23.2.1) on Natty. In
> the past I've tried compiling both emacs 24 and emacs 23 myself on this
> machine, before deciding it was unnecessary and just using the
> repository version. As near as I can tell I've cleared the old 24 and 23
> installations out of my system, but leftover files are still interfering
> with byte compilation in my present system.
>
> Makefiles in external packages like gnus or org-mode set the executable
> to "emacs" (ie, no full path). There are no other "emacs" executables on
> my path, but still I need to change the makefiles to specify
> "/usr/bin/emacs", or else I pick up weird bits from emacs 24, and my
> compiled files behave strangely (I can provide more details).
Hi,
that would be of interest for me, just to understand how Emacs behaves.
Even with
> the full path to emacs specified, I get these warnings with each byte
> compilation:
>
> Warning: Lisp directory `/usr/local/share/emacs/23.2/site-lisp' does not exist.
> Warning: Lisp directory `/usr/local/share/emacs/site-lisp' does not exist.
Given the issue above wouldn't exist --which seems a more serious one--
that warning alone would tell me:
when Emacs was build these directories existed, now they are gone.
Then it should be OK providing empty directories to get rid of the
warning. (?)
Andreas
>
> All my site-lisp directories are under /usr/share/emacs or
> /usr/share/emacs23, and I don't know what configuration or startup files
> are telling it to look under /usr/local/share.
>
> Given that no other "emacs" executables are on my system (at least, to
> the best of my knowledge, and I spent a while rooting them out), what
> other leftover files could be confusing my present installation?
>
> Thanks!
> Eric
>
>
>
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: removing old installations
2011-06-25 22:57 ` Eric Abrahamsen
@ 2011-06-26 14:18 ` Peter Dyballa
2011-06-27 18:52 ` Eric Abrahamsen
0 siblings, 1 reply; 7+ messages in thread
From: Peter Dyballa @ 2011-06-26 14:18 UTC (permalink / raw
To: Eric Abrahamsen; +Cc: help-gnu-emacs
Am 26.06.2011 um 00:57 schrieb Eric Abrahamsen:
> I'm quite sure I've removed everything emacs-related from /usr/local/
> *.
> One odd thing is, my emacs man file is located at
> /usr/share/man/man1/emacs.1.gz (symlinked from
> /etc/alternatives/emacs.1.gz), but within the FILES section of that
> man
> page, it gives all the emacs-related paths as /usr/local/*. Not sure
> what that's about.
I've forgotten these! And there's more than one file:
-rw-r--r-- 1 root wheel 6367 9. Jun 21:38 man1/emacs.1.gz
-rw-r--r-- 1 root wheel 1632 9. Jun 21:38 man1/emacsclient.1.gz
-rw-r--r-- 1 root wheel 4444 9. Jun 21:38 man1/etags.1.gz
-rw-r--r-- 1 root wheel 993 9. Jun 21:38 man1/grep-changelog.1.gz
-rw-r--r-- 1 root wheel 1191 9. Jun 21:38 man1/rcs-checkin.1.gz
-rw-r--r-- 1 root wheel 37 9. Jun 21:38 man1/ctags.1.gz
-rw-r--r-- 1 root wheel 1128 9. Jun 21:38 man1/ebrowse.1.gz
Another area with around 90 files is /usr/local/share/info. And
there's also /usr/local/share/applications/emacs.desktop!
The sym-links to /etc/alternatives are *not* from your "private"
installation of GNU Emacs, they're presumably from Debian (package).
The reason is that you can have more that one packaged GNU Emacs
version on your PC. Then *some* man page must be present (similarly
for the INFO files – and this Debian scheme really works quite fine,
on my Mac).
>
> The bug report data shows that emacs was compiled by Debian.
So you can be sure now that it's not your own "private" Emacs!
> I note that --enable-locallisppath includes, among many other paths,
> the two paths
> that emacs complains about when it's run from the command line.
>
> Among the voluminous output of strace is:
>
> access("/usr/local/share/emacs/23.2/site-lisp", F_OK) = -1 ENOENT
> (No such file or directory)
> write(2, "Warning: Lisp directory `/usr/lo"..., 80) = 80
> access("/usr/local/share/emacs/site-lisp", F_OK) = -1 ENOENT (No
> such file or directory)
> write(2, "Warning: Lisp directory `/usr/lo"..., 75) = 75
So presumably they're just *warnings*, not /errors/! You've deleted
these directory branches when you found that they might contain data
from your "private" installations, but they were created before when
you installed some GNU Emacs package.
I'd recommend to check (the dates of) the MAN and INFO files. This
step could be performed again after this most important step: remove
all GNU Emacs packages from your PC to clean the situation as far as
possible. (Then recheck the places I mentioned in my posts.) Finally
re-install these packages/this package. It will create the paths GNU
Emacs is complaining about.
>
> Is my only problem that emacs was compiled with some non-existent
> directories in the lisploadpath?
No, I presume that you started cleaning after you had installed the
first GNU Emacs package (and found some interference of the two
Emacsen). And during this operation you just removed a few bits too
much. By removing and reinstalling you'll get these bits back. And a
sane system!
--
Greetings
Pete
Upgraded, adj.:
Didn't work the first time.
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: removing old installations
2011-06-26 6:08 ` Andreas Röhler
@ 2011-06-27 3:42 ` Eric Abrahamsen
0 siblings, 0 replies; 7+ messages in thread
From: Eric Abrahamsen @ 2011-06-27 3:42 UTC (permalink / raw
To: help-gnu-emacs
On Sat, Jun 25 2011, Andreas Röhler wrote:
> Am 25.06.2011 19:34, schrieb Eric Abrahamsen:
>> I'm running the Ubuntu repository version of emacs (23.2.1) on Natty. In
>> the past I've tried compiling both emacs 24 and emacs 23 myself on this
>> machine, before deciding it was unnecessary and just using the
>> repository version. As near as I can tell I've cleared the old 24 and 23
>> installations out of my system, but leftover files are still interfering
>> with byte compilation in my present system.
>>
>> Makefiles in external packages like gnus or org-mode set the executable
>> to "emacs" (ie, no full path). There are no other "emacs" executables on
>> my path, but still I need to change the makefiles to specify
>> "/usr/bin/emacs", or else I pick up weird bits from emacs 24, and my
>> compiled files behave strangely (I can provide more details).
>
>
> Hi,
>
> that would be of interest for me, just to understand how Emacs behaves.
What was happening was that a call to a function named
internal-temp-output-buffer-show, which only exists in emacs 24, was
getting dragged in when my org-mode files were compiled. I ran into it
in the org-export function, though grepping my compiled org-mode
codebase showed that it had crept into more than a few of the compiled
files.
It was confusing because org-export complained that the function
couldn't be found; meanwhile no mention of that function appears
anywhere in the org codebase. Manually re-compiling the org-export
function definition from within emacs cleared the problem up.
That function seems to be included in src/window.c in the emacs trunk
source, but I don't know where in your system it ends up after you've
compiled and installed emacs 24. Nor do I know why it was pollution byte
compilation in my regular emacs.
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: removing old installations
2011-06-26 14:18 ` Peter Dyballa
@ 2011-06-27 18:52 ` Eric Abrahamsen
0 siblings, 0 replies; 7+ messages in thread
From: Eric Abrahamsen @ 2011-06-27 18:52 UTC (permalink / raw
To: help-gnu-emacs
On Sun, Jun 26 2011, Peter Dyballa wrote:
> Am 26.06.2011 um 00:57 schrieb Eric Abrahamsen:
>
>> I'm quite sure I've removed everything emacs-related from
>> /usr/local/*.
>> One odd thing is, my emacs man file is located at
>> /usr/share/man/man1/emacs.1.gz (symlinked from
>> /etc/alternatives/emacs.1.gz), but within the FILES section of that
>> man
>> page, it gives all the emacs-related paths as /usr/local/*. Not sure
>> what that's about.
>
> I've forgotten these! And there's more than one file:
>
> -rw-r--r-- 1 root wheel 6367 9. Jun 21:38 man1/emacs.1.gz
> -rw-r--r-- 1 root wheel 1632 9. Jun 21:38 man1/emacsclient.1.gz
> -rw-r--r-- 1 root wheel 4444 9. Jun 21:38 man1/etags.1.gz
> -rw-r--r-- 1 root wheel 993 9. Jun 21:38 man1/grep-changelog.1.gz
> -rw-r--r-- 1 root wheel 1191 9. Jun 21:38 man1/rcs-checkin.1.gz
> -rw-r--r-- 1 root wheel 37 9. Jun 21:38 man1/ctags.1.gz
> -rw-r--r-- 1 root wheel 1128 9. Jun 21:38 man1/ebrowse.1.gz
>
> Another area with around 90 files is /usr/local/share/info. And
> there's also /usr/local/share/applications/emacs.desktop!
>
> The sym-links to /etc/alternatives are *not* from your "private"
> installation of GNU Emacs, they're presumably from Debian (package).
> The reason is that you can have more that one packaged GNU Emacs
> version on your PC. Then *some* man page must be present (similarly
> for the INFO files – and this Debian scheme really works quite fine,
> on my Mac).
>
>
>>
>> The bug report data shows that emacs was compiled by Debian.
>
> So you can be sure now that it's not your own "private" Emacs!
>
>> I note that --enable-locallisppath includes, among many other paths,
>> the two paths
>> that emacs complains about when it's run from the command line.
>>
>> Among the voluminous output of strace is:
>>
>> access("/usr/local/share/emacs/23.2/site-lisp", F_OK) = -1 ENOENT
>> (No such file or directory)
>> write(2, "Warning: Lisp directory `/usr/lo"..., 80) = 80
>> access("/usr/local/share/emacs/site-lisp", F_OK) = -1 ENOENT (No
>> such file or directory)
>> write(2, "Warning: Lisp directory `/usr/lo"..., 75) = 75
>
> So presumably they're just *warnings*, not /errors/! You've deleted
> these directory branches when you found that they might contain data
> from your "private" installations, but they were created before when
> you installed some GNU Emacs package.
>
> I'd recommend to check (the dates of) the MAN and INFO files. This
> step could be performed again after this most important step: remove
> all GNU Emacs packages from your PC to clean the situation as far as
> possible. (Then recheck the places I mentioned in my posts.) Finally
> re-install these packages/this package. It will create the paths GNU
> Emacs is complaining about.
Yes, it turned out that all the man files (even those that claimed that
emacs would be installed under /usr/local) were all part of the debian
install, and were in the right places. The two directories it was
complaining about were part of the proper install, and after they were
recreated the warnings stopped. Just goes to show how often the problem
you think you have isn't the one you actually have.
>>
>> Is my only problem that emacs was compiled with some non-existent
>> directories in the lisploadpath?
>
>
> No, I presume that you started cleaning after you had installed the
> first GNU Emacs package (and found some interference of the two
> Emacsen). And during this operation you just removed a few bits too
> much. By removing and reinstalling you'll get these bits back. And a
> sane system!
Yup, that was exactly right.
Thank you!
^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2011-06-27 18:52 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2011-06-25 17:34 removing old installations Eric Abrahamsen
2011-06-25 19:58 ` Peter Dyballa
2011-06-25 22:57 ` Eric Abrahamsen
2011-06-26 14:18 ` Peter Dyballa
2011-06-27 18:52 ` Eric Abrahamsen
2011-06-26 6:08 ` Andreas Röhler
2011-06-27 3:42 ` Eric Abrahamsen
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.