Emacs 23.2.94 pretest

Emacs 23.2.94 pretest

[Chong Yidong]

Emacs pretest 23.2.94 is now available for download via FTP, at the
following location:

  ftp://alpha.gnu.org/gnu/emacs/pretest/emacs-23.2.94.tar.gz

This is the fifth pretest for what will become Emacs 23.3, which is
mostly a bugfix release.  The xdelta against 23.2.93 is at

  ftp://alpha.gnu.org/gnu/emacs/pretest/emacs-23.2.93-23.2.94.xdelta

Please send me an email reporting success or failure on your build
platform.  Report bugs via M-x report-emacs-bugs, or email
bug-gnu-emacs@gnu.org.  For questions, email emacs-devel@gnu.org.

Developers: please note that the emacs-23 branch is now in hard freeze.
Commits should be for regressions against 23.2, or documentation bugs,
only.  For any exceptions that may crop up, discuss on emacs-devel.

Thanks for helping to test Emacs.

Re: Emacs 23.2.94 pretest

[Miles Bader]

Chong Yidong <cyd@stupidchicken.com> writes:
>   ftp://alpha.gnu.org/gnu/emacs/pretest/emacs-23.2.93-23.2.94.xdelta
>
> Please send me an email reporting success or failure on your build
> platform.  Report bugs via M-x report-emacs-bugs, or email
> bug-gnu-emacs@gnu.org.  For questions, email emacs-devel@gnu.org.

What about the "copyright.el botch" I posted about a few days ago...?

Lars suggested a fix (let-binding write-file-hooks instead of
copyright-update), but I dunno if that's considered the right thing...

-miles

-- 
80% of success is just showing up.  --Woody Allen

Re: Emacs 23.2.94 pretest

[Chong Yidong]

Miles Bader <miles@gnu.org> writes:

> Chong Yidong <cyd@stupidchicken.com> writes:
>>   ftp://alpha.gnu.org/gnu/emacs/pretest/emacs-23.2.93-23.2.94.xdelta
>>
>> Please send me an email reporting success or failure on your build
>> platform.  Report bugs via M-x report-emacs-bugs, or email
>> bug-gnu-emacs@gnu.org.  For questions, email emacs-devel@gnu.org.
>
> What about the "copyright.el botch" I posted about a few days ago...?
>
> Lars suggested a fix (let-binding write-file-hooks instead of
> copyright-update), but I dunno if that's considered the right thing...

Sorry, I forgot about that.  Does something like this work?

Also, it would be nice if someone could figure out why this used to
work.


*** lisp/gnus/nnfolder.el	2011-01-02 23:50:46 +0000
--- lisp/gnus/nnfolder.el	2011-02-15 15:47:59 +0000
***************
*** 1099,1106 ****
      (gnus-make-directory (file-name-directory (buffer-file-name)))
      (let ((coding-system-for-write
  	   (or nnfolder-file-coding-system-for-write
! 	       nnfolder-file-coding-system))
! 	  (copyright-update nil))
        (save-buffer)))
    (unless (or gnus-nov-is-evil nnfolder-nov-is-evil)
      (nnfolder-save-nov)))
--- 1099,1106 ----
      (gnus-make-directory (file-name-directory (buffer-file-name)))
      (let ((coding-system-for-write
  	   (or nnfolder-file-coding-system-for-write
! 	       nnfolder-file-coding-system)))
!       (set (make-local-variable 'copyright-update) nil)
        (save-buffer)))
    (unless (or gnus-nov-is-evil nnfolder-nov-is-evil)
      (nnfolder-save-nov)))

copyright-update in nnfolder [was Re: Emacs 23.2.94 pretest]

[Glenn Morris]

Chong Yidong wrote:

> *** lisp/gnus/nnfolder.el	2011-01-02 23:50:46 +0000
> --- lisp/gnus/nnfolder.el	2011-02-15 15:47:59 +0000
[...]
> !       (set (make-local-variable 'copyright-update) nil)

I think it would be better for nnfolder just not to do this at all.
First, how many mail folders happen to contain copyright headers at
the start?
Second, people should be more selective about enabling features on
buffer-save. It's not the responsibility of every package that saves a
buffer to disable every feature (trailing whitespace removal, etc) that
people might have added to save hooks.

Re: copyright-update in nnfolder [was Re: Emacs 23.2.94 pretest]

[Stefan Monnier]

>> *** lisp/gnus/nnfolder.el	2011-01-02 23:50:46 +0000
>> --- lisp/gnus/nnfolder.el	2011-02-15 15:47:59 +0000
> [...]
>> !       (set (make-local-variable 'copyright-update) nil)

> I think it would be better for nnfolder just not to do this at all.
> First, how many mail folders happen to contain copyright headers at
> the start?
> Second, people should be more selective about enabling features on
> buffer-save. It's not the responsibility of every package that saves a
> buffer to disable every feature (trailing whitespace removal, etc) that
> people might have added to save hooks.

That's a very good point.  But it's also true that it's reasonable for
users to be able to set such features globally rather than having to do
it for each and every major mode that they happen to use to edit
normal files.

There are some related concepts where we also take such special
precautions, such as ignoring coding cookies in tar files.
We should probably try to come up with some more general approach to
solve all these centrally.
E.g. define some notion of "normal file", so copyright-update can be
used in "all normal files" and coding cookies would be ignored in
non-normal files.


        Stefan

Re: copyright-update in nnfolder [was Re: Emacs 23.2.94 pretest]

[Miles Bader]

Glenn Morris <rgm@gnu.org> writes:
>> !       (set (make-local-variable 'copyright-update) nil)
>
> I think it would be better for nnfolder just not to do this at all.
> First, how many mail folders happen to contain copyright headers at
> the start?

Sadly, it's all too common for copyright headers to appear in places
that confuse copyright.el; e.g., patch files that update the copyright
(it sees the "from" branch first, so...)!

I presume this sort of very specific workaround wouldn't have been added
to nnfolder unless people had hit

> Second, people should be more selective about enabling features on
> buffer-save. It's not the responsibility of every package that saves a
> buffer to disable every feature (trailing whitespace removal, etc) that
> people might have added to save hooks.

copyright.el, at least, at least _asks_ before doing something, and
rarely actually takes action (because it has fairly narrow criteria for
when an update is needed), so it tends to be just annoying rather than
dangerous (whitespace munging without prompting is downright evil
though).

I agree that there should be a "better" way to do this, but unless there
is, people will continue to do whatever gets the best results on
average; there are annoyances _either_ way.

If there's a convenient way to distinguish "text files" from "other
stuff like mail archives / tar files / ...", then packages like
copyright.el could check that, and ignore any non-text-files...

-miles

-- 
Dawn, n. When men of reason go to bed.

Re: Emacs 23.2.94 pretest

[Lars Ingebrigtsen]

Chong Yidong <cyd@stupidchicken.com> writes:

> Sorry, I forgot about that.  Does something like this work?

[...]

> ! 	  (copyright-update nil))

[...]

> !       (set (make-local-variable 'copyright-update) nil)

Yes, that should work, I think?  If we're not let-binding the variable,
but only making it buffer-local, then loading copyright.el "in" this
form won't leave us with an unbound copyright-update variable.  I think? 

> Also, it would be nice if someone could figure out why this used to
> work.

Yes.

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: Emacs 23.2.94 pretest

[Sean Sieger]

Chong Yidong <cyd@stupidchicken.com> writes:

    Emacs pretest 23.2.94 is now available for download via FTP, at the
    following location:

      ftp://alpha.gnu.org/gnu/emacs/pretest/emacs-23.2.94.tar.gz

    This is the fifth pretest for what will become Emacs 23.3, which is
    mostly a bugfix release.  The xdelta against 23.2.93 is at

      ftp://alpha.gnu.org/gnu/emacs/pretest/emacs-23.2.93-23.2.94.xdelta

    Please send me an email reporting success or failure on your build
    platform.  Report bugs via M-x report-emacs-bugs, or email
    bug-gnu-emacs@gnu.org.  For questions, email emacs-devel@gnu.org.

    Developers: please note that the emacs-23 branch is now in hard freeze.
    Commits should be for regressions against 23.2, or documentation bugs,
    only.  For any exceptions that may crop up, discuss on emacs-devel.

    Thanks for helping to test Emacs.

The pretest was built and runs successfully on Windows.  Binaries have
been published in

http://alpha.gnu.org/gnu/emacs/pretest/windows/

Re: Emacs 23.2.94 pretest

[Uday S Reddy]

On 2/17/2011 1:00 AM, Sean Sieger wrote:

>
> The pretest was built and runs successfully on Windows.  Binaries have
> been published in
>
> http://alpha.gnu.org/gnu/emacs/pretest/windows/

This is just to put it on record that I have experienced very frequent 
crashes with this build.  Sometimes it happened spontaneously while I 
wasn't doing anything with the Emacs session at all.  (But, there are a 
few timer tasks that go on when I use VM.  It could be due to them.)

Unfortunately I don't yet know how to get core dumps on Windows.  I 
would appreciate tips on how to obtain a core dump.

Cheers,
Uday

Re: Emacs 23.2.94 pretest

[Chong Yidong]

Uday S Reddy <u.s.reddy@cs.bham.ac.uk> writes:

> This is just to put it on record that I have experienced very frequent
> crashes with this build.  Sometimes it happened spontaneously while I
> wasn't doing anything with the Emacs session at all.  (But, there are
> a few timer tasks that go on when I use VM.  It could be due to them.)
>
> Unfortunately I don't yet know how to get core dumps on Windows.  I
> would appreciate tips on how to obtain a core dump.

Did you have any such problems with 23.2.93?

Re: Emacs 23.2.94 pretest

[Uday S Reddy]

Chong Yidong writes:

> Did you have any such problems with 23.2.93?

No, I had an occasional crash, but nothing like this.

Cheers,
Uday

Re: Emacs 23.2.94 pretest

[Eli Zaretskii]

> From: Uday S Reddy <u.s.reddy@cs.bham.ac.uk>
> Date: Wed, 23 Feb 2011 17:36:40 +0000
> Cc: help-emacs-windows@gnu.org
> 
> Unfortunately I don't yet know how to get core dumps on Windows.  I 
> would appreciate tips on how to obtain a core dump.

You can't, not with the native Windows build, anyway.

One way of reporting more info would be to run Emacs under GDB.  You
can download a Windows port of GDB from the MinGW site.  Then, when
Emacs crashes, you can walk the call stack and show us what you see.

Another way is to install DrMinGW, a JIT debugger that will allow you
to produce a backtrace when Emacs crashes.  You can find the
instructions here:

   http://code.google.com/p/jrfonseca/wiki/DrMingw

Given that the precompiled binaries were built with optimizations, I
expect difficulties in interpreting the backtraces and anything GDB
will report, so the useful next step (after you find out what can be
found with these binaries) would be to try running an unoptimized
build.

FWIW, I have yet to see even a single crash in Emacs 23.2.94, but then
I don't use VM.

Re: Emacs 23.2.94 pretest

[Chong Yidong]

Uday S Reddy <u.s.reddy@cs.bham.ac.uk> writes:

> Chong Yidong writes:
>
>> Did you have any such problems with 23.2.93?
>
> No, I had an occasional crash, but nothing like this.

There are only about six changes between .93 and .94 that are likely to
create crashed where none previously existed.  If the crashes are
frequent enough, I suggest reverting each of these to see what makes a
difference.

Are you using the binaries, or building Emacs from source?  If the
latter, try individually reverting each of these in turn:

  100470
  100466
  100459
  100458
  100444
  100441

I can mail you the patches if you don't have access to bzr.  Running
Emacs in gdb and getting the backtrace, as Eli suggested, would also be
helpful.

Re: Emacs 23.2.94 pretest

[Eli Zaretskii]

> From: Chong Yidong <cyd@stupidchicken.com>
> Date: Wed, 23 Feb 2011 14:01:40 -0500
> Cc: emacs-devel@gnu.org
> 
> There are only about six changes between .93 and .94 that are likely to
> create crashed where none previously existed.  If the crashes are
> frequent enough, I suggest reverting each of these to see what makes a
> difference.
> 
> Are you using the binaries, or building Emacs from source?  If the
> latter, try individually reverting each of these in turn:
> 
>   100470
>   100466
>   100459
>   100458
>   100444
>   100441

I doubt that any of these could be the reason, given the fact that
Emacs crashes even when Uday does nothing at all.  That is usually a
symptom of a crash in GC, and none of the revisions above seems to
have some relation to GC, unless I'm missing something.

Of course, it can never do any harm to try to take out these changes,
and see if the problem persists.

Re: Emacs 23.2.94 pretest

[Uday S Reddy]

Chong Yidong writes:

> Are you using the binaries, or building Emacs from source?  If the
> latter, try individually reverting each of these in turn:

I am using Sean Sieger's binaries.  I never built Emacs on Win32.

I tried to find the revisions on Savannah.  But the link 

   http://bzr.savannah.gnu.org/lh/emacs

So, I am pulling the branch now, and will check the revisions once the
download completes.

I have had several hours of stable operation today.  I am trying
narrow things down.  

Cheers,
Uday

Re: Emacs 23.2.94 pretest

[Lennart Borgman]

On Wed, Feb 23, 2011 at 9:36 PM, Uday S Reddy <u.s.reddy@cs.bham.ac.uk> wrote:
> Chong Yidong writes:
>
>> Are you using the binaries, or building Emacs from source?  If the
>> latter, try individually reverting each of these in turn:
>
> I am using Sean Sieger's binaries.  I never built Emacs on Win32.
>
> I tried to find the revisions on Savannah.  But the link
>
>   http://bzr.savannah.gnu.org/lh/emacs

Is there anything that prevents naming the uploaded binaries after the
bzr rev number/id?

Re: Emacs 23.2.94 pretest

[Chong Yidong]

Uday S Reddy <u.s.reddy@cs.bham.ac.uk> writes:

> So, I am pulling the branch now, and will check the revisions once the
> download completes.

Thanks.  Please remember to compile without optimizations, and with
debugging symbols (CFLAGS="-g").

Re: Emacs 23.2.94 pretest

[Eli Zaretskii]

> From: Chong Yidong <cyd@stupidchicken.com>
> Date: Wed, 23 Feb 2011 16:21:48 -0500
> Cc: emacs-devel@gnu.org
> 
> Uday S Reddy <u.s.reddy@cs.bham.ac.uk> writes:
> 
> > So, I am pulling the branch now, and will check the revisions once the
> > download completes.
> 
> Thanks.  Please remember to compile without optimizations, and with
> debugging symbols (CFLAGS="-g").

Actually, it's "-gdwarf-2 -g3", and that's automatic unless explicitly
disabled at configure time.

Uday, you want to run nt/configure.bat with the --no-opt switch, then
the build will be unoptimized.

Re: Emacs 23.2.94 pretest

[Chong Yidong]

Eli Zaretskii writes:

> Actually, it's "-gdwarf-2 -g3", and that's automatic unless explicitly
> disabled at configure time.
> 
> Uday, you want to run nt/configure.bat with the --no-opt switch, then
> the build will be unoptimized.

Thanks, Eli.  I am not yet sure how this works.  If I run
  configure.bat --no-opt
in cmd shell, it says 'cp' is not a recognized command (even though
c:\mingw\bin is on the path).

If I run 
  cmd /c configure.bat --no-opt
in msys shell, then it just enters a cmd subshell without apparently
doing anything.

If I do this without the --no-opt switch, then msys goes through
configure wihout a problem and the whole build goes through.

I suppose you want me to redo this with the --no-opt switch?  How do I
get around the difficulty of 'cp'?  I suppose something else needs to
go on the path?

Cheers,
Uday

Re: Emacs 23.2.94 pretest

[Uday Reddy]

Sorry, that message was from me, not Chong.  

(This is embarrassing.  I was testing a whiz bang rule-based system
for filling in headers and ended up writing a bad rule!)

Cheers,
Uday

Chong Yidong writes:

> Thanks, Eli.  I am not yet sure how this works.  If I run
>   configure.bat --no-opt
> in cmd shell, it says 'cp' is not a recognized command (even though
> c:\mingw\bin is on the path).
> 
> If I run 
>   cmd /c configure.bat --no-opt
> in msys shell, then it just enters a cmd subshell without apparently
> doing anything.
> 
> If I do this without the --no-opt switch, then msys goes through
> configure wihout a problem and the whole build goes through.
> 
> I suppose you want me to redo this with the --no-opt switch?  How do I
> get around the difficulty of 'cp'?  I suppose something else needs to
> go on the path?
> 
> Cheers,
> Uday
> 
> 

Re: Emacs 23.2.94 pretest

[Uday S Reddy]

The 23.2.94 pretest worked stably this evening.  I am thinking that
the reason for the crashes earlier might have been that I was running
several versions of emacs simultaneously and there could have been
some background interference between them, especially with the
emacs-server.

So, for the time being, things look ok.

Cheers,
Uday

Re: Emacs 23.2.94 pretest

[Christoph]

Lennart Borgman <lennart.borgman@gmail.com> writes:

> Is there anything that prevents naming the uploaded binaries after the
> bzr rev number/id?

Just the .zip file? Or the 24.0.50 folder contained in it? 

I agree that we should identify the weekly trunk snapshot Sean builds
with a bzr revision id. However, this should be an automated process
executed when running `make dist' and not some manual (error-prone)
renaming.

Once I finish the Python cleanup I am working on right now, I want to
try to extend the `make dist' rule to incorporate this.

The sole purpose of this would be to tie the weekly Windows snapshot to
a revision in bzr for troubleshooting. Since the bzr revision is not
unique across branches it is not very useful for general Emacs builds
unless one can be sure the source of the build is the trunk. 

I will think more about this, maybe there is a solution that works for
all builds on all systems.

Christoph

Re: Emacs 23.2.94 pretest

[Sean Sieger]

Eli Zaretskii <eliz@gnu.org> writes:

    Given that the precompiled binaries were built with optimizations, I
    expect difficulties in interpreting the backtraces and anything GDB
    will report, so the useful next step (after you find out what can be
    found with these binaries) would be to try running an unoptimized
    build.

I configure with `--no-opt', you weren't expecting me to? or,
optimizations are made regardless?

Re: Emacs 23.2.94 pretest

[Eli Zaretskii]

> Date: Wed, 23 Feb 2011 23:11:21 +0000
> From: Chong Yidong <cyd@stupidchicken.com>
> Cc: Chong Yidong <cyd@stupidchicken.com>,
>     u.s.reddy@cs.bham.ac.uk,
>     emacs-devel@gnu.org
> 
> Thanks, Eli.  I am not yet sure how this works.  If I run
>   configure.bat --no-opt
> in cmd shell, it says 'cp' is not a recognized command (even though
> c:\mingw\bin is on the path).

Is there a cp.exe in c:\mingw\bin ?

If not, you will need to find some port of cp (and also rm and mv).
You can find a port of GNU Coreutils on the GnuWin32 site.

> If I run 
>   cmd /c configure.bat --no-opt
> in msys shell, then it just enters a cmd subshell without apparently
> doing anything.

I don't recommend using MSYS, it has too many tricky issues wrt
building Emacs.

Re: Emacs 23.2.94 pretest

[Eli Zaretskii]

> From: Sean Sieger <sean.sieger@gmail.com>
> Date: Wed, 23 Feb 2011 20:13:14 -0500
> Cc: help-emacs-windows@gnu.org
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
>     Given that the precompiled binaries were built with optimizations, I
>     expect difficulties in interpreting the backtraces and anything GDB
>     will report, so the useful next step (after you find out what can be
>     found with these binaries) would be to try running an unoptimized
>     build.
> 
> I configure with `--no-opt', you weren't expecting me to? or,
> optimizations are made regardless?

No, I just forgot that you build without optimizations.  Sorry, and
thanks for reminding me.

Re: Emacs 23.2.94 pretest

[Chong Yidong]

Andreas Röhler <andreas.roehler@online.de> writes:

> in directory which contains Emacs sources alone
> configure fails right after start:
>
> CFLAGS="-g -O2 -fno-optimize-sibling-calls" ./configure
> checking build system type... i686-pc-linux-gnu
> checking host system type... i686-pc-linux-gnu
> checking for gcc... gcc
> checking whether the C compiler works... yes
> checking for C compiler default output file name... a.out
> checking for suffix of executables...
> checking whether we are cross compiling... configure: error: in
> /home/My-Name/emacs-23.2.94':
> configure: error: cannot run C compiled programs.
> If you meant to cross compile, use `--host'.
> See `config.log' for more details
>
>
> Linux 2.6.31.14-0.6-default #1 SMP 2010-12-10 11:18:32 +0100 i686 i686
> i386 GNU/Linux

Anyone know what this error refers to?

Re: Emacs 23.2.94 pretest

[Andreas Schwab]

Chong Yidong <cyd@stupidchicken.com> writes:

> Andreas Röhler <andreas.roehler@online.de> writes:
>
>> in directory which contains Emacs sources alone
>> configure fails right after start:
>>
>> CFLAGS="-g -O2 -fno-optimize-sibling-calls" ./configure
>> checking build system type... i686-pc-linux-gnu
>> checking host system type... i686-pc-linux-gnu
>> checking for gcc... gcc
>> checking whether the C compiler works... yes
>> checking for C compiler default output file name... a.out
>> checking for suffix of executables...
>> checking whether we are cross compiling... configure: error: in
>> /home/My-Name/emacs-23.2.94':
>> configure: error: cannot run C compiled programs.
>> If you meant to cross compile, use `--host'.
>> See `config.log' for more details
   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>>
>>
>> Linux 2.6.31.14-0.6-default #1 SMP 2010-12-10 11:18:32 +0100 i686 i686
>> i386 GNU/Linux
>
> Anyone know what this error refers to?

See above.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Emacs 23.2.94 pretest

[Andreas Röhler]

Am 24.02.2011 19:56, schrieb Andreas Schwab:
> Chong Yidong<cyd@stupidchicken.com>  writes:
>
>> Andreas Röhler<andreas.roehler@online.de>  writes:
>>
>>> in directory which contains Emacs sources alone
>>> configure fails right after start:
>>>
>>> CFLAGS="-g -O2 -fno-optimize-sibling-calls" ./configure
>>> checking build system type... i686-pc-linux-gnu
>>> checking host system type... i686-pc-linux-gnu
>>> checking for gcc... gcc
>>> checking whether the C compiler works... yes
>>> checking for C compiler default output file name... a.out
>>> checking for suffix of executables...
>>> checking whether we are cross compiling... configure: error: in
>>> /home/My-Name/emacs-23.2.94':
>>> configure: error: cannot run C compiled programs.
>>> If you meant to cross compile, use `--host'.
>>> See `config.log' for more details
>     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>>>
>>>
>>> Linux 2.6.31.14-0.6-default #1 SMP 2010-12-10 11:18:32 +0100 i686 i686
>>> i386 GNU/Linux
>>
>> Anyone know what this error refers to?
>
> See above.
>
> Andreas.

Here it is:

This file contains any messages produced by compilers while
running configure, to aid debugging if configure makes a mistake.

It was created by emacs configure 23.2.94, which was
generated by GNU Autoconf 2.67.  Invocation command line was

   $ ./configure

## --------- ##
## Platform. ##
## --------- ##

hostname = localhost
uname -m = i686
uname -r = 2.6.31.14-0.6-default
uname -s = Linux
uname -v = #1 SMP 2010-12-10 11:18:32 +0100

/usr/bin/uname -p = unknown
/bin/uname -X     = unknown

/bin/arch              = i686
/usr/bin/arch -k       = unknown
/usr/convex/getsysinfo = unknown
/usr/bin/hostinfo      = unknown
/bin/machine           = unknown
/usr/bin/oslevel       = unknown
/bin/universe          = unknown

PATH: /usr/local/bin
PATH: /usr/bin
PATH: /bin
PATH: /usr/bin/X11
PATH: /usr/X11R6/bin
PATH: /usr/games
PATH: /opt/kde3/bin
PATH: /usr/lib/mit/bin
PATH: /usr/lib/mit/sbin
PATH: .
PATH: /usr/lib/qt3/bin
PATH: MY-PATH/bin
PATH: MY-PATH/python
PATH: MY-PATH/perl
PATH: /usr/local/share/f-prot/
PATH: MY-PATH/bin
PATH: MY-PATH/python
PATH: MY-PATH/perl
PATH: /usr/local/share/f-prot/


## ----------- ##
## Core tests. ##
## ----------- ##

configure:2974: checking build system type
configure:2988: result: i686-pc-linux-gnu
configure:3008: checking host system type
configure:3021: result: i686-pc-linux-gnu
configure:3437: checking for gcc
configure:3453: found /usr/bin/gcc
configure:3464: result: gcc
configure:3693: checking for C compiler version
configure:3702: gcc --version >&5
gcc (SUSE Linux) 4.4.1 [gcc-4_4-branch revision 150839]
Copyright (C) 2009 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

configure:3713: $? = 0
configure:3702: gcc -v >&5
Using built-in specs.
Target: i586-suse-linux
Configured with: ../configure --prefix=/usr --infodir=/usr/share/info 
--mandir=/usr/share/man --libdir=/usr/lib --libexecdir=/usr/lib 
--enable-languages=c,c++,objc,fortran,obj-c++,java,ada 
--enable-checking=release --with-gxx-include-dir=/usr/include/c++/4.4 
--enable-ssp --disable-libssp --with-bugurl=http://bugs.opensuse.org/ 
--with-pkgversion='SUSE Linux' --disable-libgcj --disable-libmudflap 
--with-slibdir=/lib --with-system-zlib --enable-__cxa_atexit 
--enable-libstdcxx-allocator=new --disable-libstdcxx-pch 
--enable-version-specific-runtime-libs --program-suffix=-4.4 
--enable-linux-futex --without-system-libunwind --with-arch-32=i586 
--with-tune=generic --build=i586-suse-linux
Thread model: posix
gcc version 4.4.1 [gcc-4_4-branch revision 150839] (SUSE Linux)
configure:3713: $? = 0
configure:3702: gcc -V >&5
gcc: '-V' option must have argument
configure:3713: $? = 1
configure:3702: gcc -qversion >&5
gcc: unrecognized option '-qversion'
gcc: no input files
configure:3713: $? = 1
configure:3733: checking whether the C compiler works
configure:3755: gcc -g -O2 -fno-optimize-sibling-calls   conftest.c  >&5
configure:3759: $? = 0
configure:3807: result: yes
configure:3810: checking for C compiler default output file name
configure:3812: result: a.out
configure:3818: checking for suffix of executables
configure:3825: gcc -o conftest -g -O2 -fno-optimize-sibling-calls 
conftest.c  >&5
configure:3829: $? = 0
configure:3851: result:
configure:3873: checking whether we are cross compiling
configure:3881: gcc -o conftest -g -O2 -fno-optimize-sibling-calls 
conftest.c  >&5
conftest.c:11:19: error: /usr/local/include/stdio.h: Permission denied
conftest.c: In function 'main':
conftest.c:15: error: 'FILE' undeclared (first use in this function)
conftest.c:15: error: (Each undeclared identifier is reported only once
conftest.c:15: error: for each function it appears in.)
conftest.c:15: error: 'f' undeclared (first use in this function)
configure:3885: $? = 1
configure:3892: ./conftest
./configure: line 3894: ./conftest: No such file or directory
configure:3896: $? = 127
configure:3903: error: in `/home/MY-NAME/emacs-23.2.94':
configure:3905: error: cannot run C compiled programs.
If you meant to cross compile, use `--host'.
See `config.log' for more details

## ---------------- ##
## Cache variables. ##
## ---------------- ##

ac_cv_build=i686-pc-linux-gnu
ac_cv_env_CC_set=
ac_cv_env_CC_value=
ac_cv_env_CFLAGS_set=set
ac_cv_env_CFLAGS_value='-g -O2 -fno-optimize-sibling-calls'
ac_cv_env_CPPFLAGS_set=
ac_cv_env_CPPFLAGS_value=
ac_cv_env_CPP_set=
ac_cv_env_CPP_value=
ac_cv_env_LDFLAGS_set=
ac_cv_env_LDFLAGS_value=
ac_cv_env_LIBS_set=
ac_cv_env_LIBS_value=
ac_cv_env_XMKMF_set=
ac_cv_env_XMKMF_value=
ac_cv_env_build_alias_set=
ac_cv_env_build_alias_value=
ac_cv_env_host_alias_set=
ac_cv_env_host_alias_value=
ac_cv_env_target_alias_set=
ac_cv_env_target_alias_value=
ac_cv_host=i686-pc-linux-gnu
ac_cv_prog_ac_ct_CC=gcc

## ----------------- ##
## Output variables. ##
## ----------------- ##

ALLOCA=''
ALSA_CFLAGS=''
ALSA_LIBS=''
CC='gcc'
CFLAGS='-g -O2 -fno-optimize-sibling-calls'
CFLAGS_SOUND=''
CPP=''
CPPFLAGS=''
CRT_DIR=''
C_SWITCH_X_SITE=''
DBUS_CFLAGS=''
DBUS_LIBS=''
DEFS=''
ECHO_C=''
ECHO_N='-n'
ECHO_T=''
EGREP=''
EXEEXT=''
FONTCONFIG_CFLAGS=''
FONTCONFIG_LIBS=''
FREETYPE_CFLAGS=''
FREETYPE_LIBS=''
GCONF_CFLAGS=''
GCONF_LIBS=''
GETLOADAVG_LIBS=''
GETOPTOBJS=''
GETOPT_H=''
GNUSTEP_MAKEFILES=''
GNUSTEP_SYSTEM_HEADERS=''
GNUSTEP_SYSTEM_LIBRARIES=''
GNU_OBJC_CFLAGS=''
GREP=''
GTK_CFLAGS=''
GTK_LIBS=''
GZIP_PROG=''
HAVE_XSERVER=''
INSTALL_DATA=''
INSTALL_INFO=''
INSTALL_PROGRAM=''
INSTALL_SCRIPT=''
KMEM_GROUP=''
LDFLAGS=''
LD_SWITCH_X_SITE=''
LD_SWITCH_X_SITE_AUX=''
LIBOBJS=''
LIBOTF_CFLAGS=''
LIBOTF_LIBS=''
LIBS=''
LIBSOUND=''
LIB_SRC_EXTRA_INSTALLABLES=''
LN_S=''
LTLIBOBJS=''
M17N_FLT_CFLAGS=''
M17N_FLT_LIBS=''
MAINT='#'
MAKEINFO=''
NEED_SETGID=''
OBJEXT=''
OTHER_FILES=''
PACKAGE_BUGREPORT=''
PACKAGE_NAME='emacs'
PACKAGE_STRING='emacs 23.2.94'
PACKAGE_TARNAME='emacs'
PACKAGE_URL=''
PACKAGE_VERSION='23.2.94'
PATH_SEPARATOR=':'
PKG_CONFIG=''
RANLIB=''
RSVG_CFLAGS=''
RSVG_LIBS=''
SET_MAKE=''
SHELL='/bin/sh'
XFT_CFLAGS=''
XFT_LIBS=''
XMKMF=''
X_TOOLKIT_TYPE=''
ac_ct_CC='gcc'
archlibdir='${libexecdir}/emacs/${version}/${configuration}'
bindir='${exec_prefix}/bin'
bitmapdir=''
build='i686-pc-linux-gnu'
build_alias=''
build_cpu='i686'
build_os='linux-gnu'
build_vendor='pc'
c_switch_machine=''
c_switch_system=''
canonical='i686-pc-linux-gnu'
configuration='i686-pc-linux-gnu'
datadir='${datarootdir}'
datarootdir='${prefix}/share'
docdir='${datadir}/emacs/${version}/etc'
dvidir='${docdir}'
etcdir='${datadir}/emacs/${version}/etc'
exec_prefix='NONE'
gamedir='${localstatedir}/games/emacs'
gameuser='games'
host='i686-pc-linux-gnu'
host_alias=''
host_cpu='i686'
host_os='linux-gnu'
host_vendor='pc'
htmldir='${docdir}'
includedir='${prefix}/include'
infodir='${datarootdir}/info'
libdir='${exec_prefix}/lib'
libexecdir='${exec_prefix}/libexec'
liblockfile=''
lispdir='${datadir}/emacs/${version}/lisp'
lisppath='${locallisppath}:${lispdir}:${datadir}/emacs/${version}/leim'
localedir='${datarootdir}/locale'
locallisppath='${datadir}/emacs/${version}/site-lisp:${datadir}/emacs/site-lisp'
localstatedir='${prefix}/var'
machfile='m/intel386.h'
mandir='${datarootdir}/man'
ns_appbindir=''
ns_appdir=''
ns_appresdir=''
ns_appsrc=''
oldincludedir='/usr/include'
opsysfile='s/gnu-linux.h'
pdfdir='${docdir}'
prefix='NONE'
program_transform_name='s,x,x,'
psdir='${docdir}'
sbindir='${exec_prefix}/sbin'
sharedstatedir='${prefix}/com'
srcdir='/home/MY-NAME/emacs-23.2.94'
sysconfdir='${prefix}/etc'
target_alias=''
version=''
x_default_search_path=''

## ----------- ##
## confdefs.h. ##
## ----------- ##

/* confdefs.h */
#define PACKAGE_NAME "emacs"
#define PACKAGE_TARNAME "emacs"
#define PACKAGE_VERSION "23.2.94"
#define PACKAGE_STRING "emacs 23.2.94"
#define PACKAGE_BUGREPORT ""
#define PACKAGE_URL ""
#define MAIL_USE_POP 1
#define SYNC_INPUT 1

configure: exit 1

>

Re: Emacs 23.2.94 pretest

[Davis Herring]

> configure:3873: checking whether we are cross compiling
> configure:3881: gcc -o conftest -g -O2 -fno-optimize-sibling-calls
> conftest.c  >&5
> conftest.c:11:19: error: /usr/local/include/stdio.h: Permission denied

This looks like the important bit.

Davis

-- 
This product is sold by volume, not by mass.  If it appears too dense or
too sparse, it is because mass-energy conversion has occurred during
shipping.

Re: Emacs 23.2.94 pretest

[Andreas Röhler]

Am 24.02.2011 23:20, schrieb Davis Herring:
>> configure:3873: checking whether we are cross compiling
>> configure:3881: gcc -o conftest -g -O2 -fno-optimize-sibling-calls
>> conftest.c>&5
>> conftest.c:11:19: error: /usr/local/include/stdio.h: Permission denied
>
> This looks like the important bit.
>
> Davis
>

Hi,

turns out

/usr/local/include

is empty, /usr/local/ looks like


drw-r--r--  2 root root  4096 24. Okt 2009  src
drw-r--r--  2 root root  4096 24. Okt 2009  sbin
drw-r--r--  2 root root  4096 24. Okt 2009  include
drw-r--r--  2 root root  4096 24. Okt 2009  games
drwxr-x---  4 root users 4096 28. Mai 2010  share
drw-r--r-- 12 root root  4096 14. Jun 2010  man
drw-r--r--  3 root root  4096  8. Aug 2010  lib
drwxrwxrwx 12 root users 4096  8. Aug 2010  thunderbird
drw-r--r--  2 root root  4096 24. Feb 15:30 bin

Thanks all

Andreas

Re: Emacs 23.2.94 pretest

[Andreas Röhler]

Am 24.02.2011 23:20, schrieb Davis Herring:
>> configure:3873: checking whether we are cross compiling
>> configure:3881: gcc -o conftest -g -O2 -fno-optimize-sibling-calls
>> conftest.c>&5
>> conftest.c:11:19: error: /usr/local/include/stdio.h: Permission denied
>
> This looks like the important bit.
>
> Davis
>

BTW

have an stdio.h at

/usr/include

here, not at /usr/local/include

with Suse 10.2

Same with Suse 10.3

Andreas

Re: Emacs 23.2.94 pretest

[Andreas Schwab]

Andreas Röhler <andreas.roehler@online.de> writes:

> drw-r--r--  2 root root  4096 24. Okt 2009  src
> drw-r--r--  2 root root  4096 24. Okt 2009  sbin
> drw-r--r--  2 root root  4096 24. Okt 2009  include
> drw-r--r--  2 root root  4096 24. Okt 2009  games
> drwxr-x---  4 root users 4096 28. Mai 2010  share
> drw-r--r-- 12 root root  4096 14. Jun 2010  man
> drw-r--r--  3 root root  4096  8. Aug 2010  lib
> drw-r--r--  2 root root  4096 24. Feb 15:30 bin

Fix that.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Emacs 23.2.94 pretest

[Andreas Röhler]

Am 25.02.2011 10:32, schrieb Andreas Schwab:
> Andreas Röhler<andreas.roehler@online.de>  writes:
>
>> drw-r--r--  2 root root  4096 24. Okt 2009  src
>> drw-r--r--  2 root root  4096 24. Okt 2009  sbin
>> drw-r--r--  2 root root  4096 24. Okt 2009  include
>> drw-r--r--  2 root root  4096 24. Okt 2009  games
>> drwxr-x---  4 root users 4096 28. Mai 2010  share
>> drw-r--r-- 12 root root  4096 14. Jun 2010  man
>> drw-r--r--  3 root root  4096  8. Aug 2010  lib
>> drw-r--r--  2 root root  4096 24. Feb 15:30 bin
>
> Fix that.
>
> Andreas.
>

Ok, thanks. Setting permissions to 755 did it so far.
Next error reported separately.

Andreas

Re: Emacs 23.2.94 pretest

[Andreas Röhler]

Am 15.02.2011 05:46, schrieb Chong Yidong:
> Emacs pretest 23.2.94 is now available for download via FTP, at the
> following location:
>
>    ftp://alpha.gnu.org/gnu/emacs/pretest/emacs-23.2.94.tar.gz
>
> This is the fifth pretest for what will become Emacs 23.3, which is
> mostly a bugfix release.  The xdelta against 23.2.93 is at
>
>    ftp://alpha.gnu.org/gnu/emacs/pretest/emacs-23.2.93-23.2.94.xdelta
>
> Please send me an email reporting success or failure on your build
> platform.  Report bugs via M-x report-emacs-bugs, or email
> bug-gnu-emacs@gnu.org.  For questions, email emacs-devel@gnu.org.
>
> Developers: please note that the emacs-23 branch is now in hard freeze.
> Commits should be for regressions against 23.2, or documentation bugs,
> only.  For any exceptions that may crop up, discuss on emacs-devel.
>
> Thanks for helping to test Emacs.
>
>

Hi,

get the following good old error, not seen for long time:

checking build system type... i686-pc-linux-gnu
checking host system type... i686-pc-linux-gnu
checking for gcc... gcc
checking whether the C compiler works... yes
checking for C compiler default output file name... a.out
checking for suffix of executables...
checking whether we are cross compiling... no
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ISO C89... none needed
checking how to run the C preprocessor... gcc -E
checking for grep that handles long lines and -e... /usr/bin/grep
checking for egrep... /usr/bin/grep -E
checking for ANSI C header files... yes
checking for sys/types.h... yes
checking for sys/stat.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for memory.h... yes
checking for strings.h... yes
checking for inttypes.h... yes
checking for stdint.h... yes
checking for unistd.h... yes
checking minix/config.h usability... no
checking minix/config.h presence... no
checking for minix/config.h... no
checking whether it is safe to define __EXTENSIONS__... yes
checking whether gcc understands -Wno-pointer-sign... yes
checking whether gcc understands -Wdeclaration-after-statement... yes
checking whether ln -s works... yes
checking how to run the C preprocessor... gcc -E
checking for a BSD-compatible install... /usr/bin/install -c
checking for ranlib... ranlib
checking for install-info... /usr/bin/install-info
checking for install-info... (cached) /usr/bin/install-info
checking for install-info... (cached) /usr/bin/install-info
checking for gzip... /usr/bin/gzip
checking for makeinfo... no
checking for -znocombreloc... yes
configure: checking the machine- and system-dependent files to find out
  - which libraries the lib-src programs will want, and
  - whether the GNU malloc routines are usable...
checking for special C compiler options needed for large files... no
checking for _FILE_OFFSET_BITS value needed for large files... 64
checking machine/soundcard.h usability... no
checking machine/soundcard.h presence... no
checking for machine/soundcard.h... no
checking sys/soundcard.h usability... yes
checking sys/soundcard.h presence... yes
checking for sys/soundcard.h... yes
checking soundcard.h usability... no
checking soundcard.h presence... no
checking for soundcard.h... no
checking for _oss_ioctl in -lossaudio... no
checking for pkg-config... /usr/bin/pkg-config
checking for alsa >= 1.0.0... yes
checking ALSA_CFLAGS... -I/usr/include/alsa
checking ALSA_LIBS... -lasound
checking sys/select.h usability... yes
checking sys/select.h presence... yes
checking for sys/select.h... yes
checking sys/timeb.h usability... yes
checking sys/timeb.h presence... yes
checking for sys/timeb.h... yes
checking sys/time.h usability... yes
checking sys/time.h presence... yes
checking for sys/time.h... yes
checking for unistd.h... (cached) yes
checking utime.h usability... yes
checking utime.h presence... yes
checking for utime.h... yes
checking linux/version.h usability... yes
checking linux/version.h presence... yes
checking for linux/version.h... yes
checking sys/systeminfo.h usability... no
checking sys/systeminfo.h presence... no
checking for sys/systeminfo.h... no
checking termios.h usability... yes
checking termios.h presence... yes
checking for termios.h... yes
checking limits.h usability... yes
checking limits.h presence... yes
checking for limits.h... yes
checking for string.h... (cached) yes
checking for stdlib.h... (cached) yes
checking termcap.h usability... yes
checking termcap.h presence... yes
checking for termcap.h... yes
checking stdio_ext.h usability... yes
checking stdio_ext.h presence... yes
checking for stdio_ext.h... yes
checking fcntl.h usability... yes
checking fcntl.h presence... yes
checking for fcntl.h... yes
checking for strings.h... (cached) yes
checking coff.h usability... no
checking coff.h presence... no
checking for coff.h... no
checking pty.h usability... yes
checking pty.h presence... yes
checking for pty.h... yes
checking sys/mman.h usability... yes
checking sys/mman.h presence... yes
checking for sys/mman.h... yes
checking sys/param.h usability... yes
checking sys/param.h presence... yes
checking for sys/param.h... yes
checking sys/vlimit.h usability... yes
checking sys/vlimit.h presence... yes
checking for sys/vlimit.h... yes
checking sys/resource.h usability... yes
checking sys/resource.h presence... yes
checking for sys/resource.h... yes
checking locale.h usability... yes
checking locale.h presence... yes
checking for locale.h... yes
checking sys/_mbstate_t.h usability... no
checking sys/_mbstate_t.h presence... no
checking for sys/_mbstate_t.h... no
checking sys/utsname.h usability... yes
checking sys/utsname.h presence... yes
checking for sys/utsname.h... yes
checking pwd.h usability... yes
checking pwd.h presence... yes
checking for pwd.h... yes
checking utmp.h usability... yes
checking utmp.h presence... yes
checking for utmp.h... yes
checking if personality LINUX32 can be set... yes
checking for term.h... yes
checking for ANSI C header files... (cached) yes
checking whether time.h and sys/time.h may both be included... yes
checking whether sys_siglist is declared... no
checking whether __sys_siglist is declared... no
checking for sys/wait.h that is POSIX.1 compatible... yes
checking for struct utimbuf... yes
checking return type of signal handlers... void
checking for speed_t... yes
checking for struct timeval... yes
checking for struct exception... yes
checking sys/socket.h usability... yes
checking sys/socket.h presence... yes
checking for sys/socket.h... yes
checking for net/if.h... yes
checking whether struct tm is in sys/time.h or time.h... time.h
checking for struct tm.tm_zone... yes
checking for struct tm.tm_gmtoff... yes
checking for struct ifreq.ifr_flags... yes
checking for struct ifreq.ifr_hwaddr... yes
checking for struct ifreq.ifr_netmask... yes
checking for struct ifreq.ifr_broadaddr... yes
checking for struct ifreq.ifr_addr... yes
checking for function prototypes... yes
checking for working volatile... yes
checking for an ANSI C-conforming const... yes
checking for void * support... yes
checking whether make sets $(MAKE)... yes
checking whether we are using GNU Make... yes
checking whether gcc understands -MMD -MF... yes
checking for long file names... yes
checking for X... libraries , headers
checking for malloc_get_state... yes
checking for malloc_set_state... yes
checking whether __after_morecore_hook exists... yes
checking for stdlib.h... (cached) yes
checking for unistd.h... (cached) yes
checking for sys/param.h... (cached) yes
checking for sys/time.h... (cached) yes
checking for getpagesize... yes
checking for working mmap... yes
checking for dnet_ntoa in -ldnet... no
checking for main in -lXbsd... no
checking for cma_open in -lpthreads... no
checking whether X on GNU/Linux needs -b to link... no
checking for Xkb... yes
checking for XrmSetDatabase... yes
checking for XScreenResourceString... yes
checking for XScreenNumberOfScreen... yes
checking for XSetWMProtocols... yes
checking X11 version 6... 6 or newer
checking for pkg-config... (cached) /usr/bin/pkg-config
checking for librsvg-2.0 >= 2.11.0... no
checking for pkg-config... (cached) /usr/bin/pkg-config
checking for gtk+-2.0 >= 2.6 glib-2.0 >= 2.6... yes
checking GTK_CFLAGS... -I/usr/include/gtk-2.0 -I/usr/lib/gtk-2.0/include 
-I/usr/include/atk-1.0 -I/usr/include/cairo -I/usr/include/pango-1.0 
-I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include 
-I/usr/include/pixman-1 -I/usr/include/freetype2 -I/usr/include/libpng12
checking GTK_LIBS... -lgtk-x11-2.0 -lgdk-x11-2.0 -latk-1.0 -lgio-2.0 
-lpangoft2-1.0 -lgdk_pixbuf-2.0 -lpangocairo-1.0 -lcairo -lpango-1.0 
-lfreetype -lfontconfig -lgobject-2.0 -lgmodule-2.0 -lglib-2.0
checking for gtk_main... yes
checking for gdk_display_open... yes
checking whether GTK_TYPE_FILE_SELECTION is declared... yes
checking for gtk_file_selection_new... yes
checking whether GTK_TYPE_FILE_CHOOSER is declared... yes
checking for gtk_file_chooser_dialog_new... yes
checking pthread.h usability... yes
checking pthread.h presence... yes
checking for pthread.h... yes
checking for pthread_self in -lpthread... yes
checking for pkg-config... (cached) /usr/bin/pkg-config
checking for dbus-1 >= 1.0... yes
checking DBUS_CFLAGS... -I/usr/include/dbus-1.0 
-I/usr/lib/dbus-1.0/include
checking DBUS_LIBS... -ldbus-1 -lpthread -lrt
checking for dbus_watch_get_unix_fd... yes
checking for pkg-config... (cached) /usr/bin/pkg-config
checking for gconf-2.0 >= 2.13... yes
checking GCONF_CFLAGS... -DORBIT2=1 -pthread -I/usr/include/gconf/2 
-I/usr/include/orbit-2.0 -I/usr/include/dbus-1.0 
-I/usr/lib/dbus-1.0/include -I/usr/include/glib-2.0 
-I/usr/lib/glib-2.0/include
checking GCONF_LIBS... -lgconf-2 -lglib-2.0
checking for g_type_init... yes
checking for pkg-config... (cached) /usr/bin/pkg-config
checking for fontconfig >= 2.2.0... yes
checking FONTCONFIG_CFLAGS...
checking FONTCONFIG_LIBS... -lfontconfig
checking for pkg-config... (cached) /usr/bin/pkg-config
checking for xft >= 0.13.0... yes
checking XFT_CFLAGS... -I/usr/include/freetype2
checking XFT_LIBS... -lXft -lXrender -lfontconfig -lfreetype -lX11
checking for XRenderQueryExtension in -lXrender... yes
checking X11/Xft/Xft.h usability... yes
checking X11/Xft/Xft.h presence... yes
checking for X11/Xft/Xft.h... yes
checking for XftFontOpen in -lXft... yes
checking for pkg-config... (cached) /usr/bin/pkg-config
checking for libotf... no
checking X11/xpm.h usability... yes
checking X11/xpm.h presence... yes
checking for X11/xpm.h... yes
checking for XpmReadFileToPixmap in -lXpm... yes
checking for XpmReturnAllocPixels preprocessor define... yes
checking jerror.h usability... yes
checking jerror.h presence... yes
checking for jerror.h... yes
checking for jpeg_destroy_compress in -ljpeg... yes
checking png.h usability... yes
checking png.h presence... yes
checking for png.h... yes
checking libpng/png.h usability... no
checking libpng/png.h presence... no
checking for libpng/png.h... no
checking for png_get_channels in -lpng... yes
checking tiffio.h usability... yes
checking tiffio.h presence... yes
checking for tiffio.h... yes
checking for TIFFGetVersion in -ltiff... yes
checking gif_lib.h usability... no
checking gif_lib.h presence... no
checking for gif_lib.h... no
configure: error: The following required libraries were not found:
      libgif/libungif
Maybe some development libraries/packages are missing?
If you don't want to link with them give
      --with-gif=no
as options to configure


;;;;;;;;;;

Is this an issue still?

Suse 10.2 tells giflib is installed for that:


giflib - Eine Bibliothek zur Arbeit mit GIF-Bildern

This Library allows manipulatng GIF Image files. Since the LZW patents 
have expired, giflib can be used instead of libungif again.


Thanks

Andreas

Re: Emacs 23.2.94 pretest

[Andreas Schwab]

Andreas Röhler <andreas.roehler@online.de> writes:

> checking gif_lib.h usability... no
> checking gif_lib.h presence... no
> checking for gif_lib.h... no

# zypper in giflib-devel

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Emacs 23.2.94 pretest

[Andreas Röhler]

Am 25.02.2011 11:29, schrieb Andreas Schwab:
> Andreas Röhler<andreas.roehler@online.de>  writes:
>
>> checking gif_lib.h usability... no
>> checking gif_lib.h presence... no
>> checking for gif_lib.h... no
>
> # zypper in giflib-devel
>
> Andreas.
>

Thanks a lot again.
Configure passed now.

Next error with separate post.

Andreas

Re: Emacs 23.2.94 pretest

[Andreas Röhler]

Hi,

emacs -q starts on Suse 10.2 saying

This is GNU Emacs 23.2.94.1 (i686-pc-linux-gnu, GTK+ Version 2.18.6)
  of 2011-02-25

Thanks all BTW

However

make -k bootstrap

finished with

make[2]: Leaving directory `/home/MY-NAME/emacs-23.2.94/leim'
make[1]: Leaving directory `/home/MY-NAME/emacs-23.2.94'
make: *** [bootstrap] Fehler 2

Compilation exited abnormally with code 2 at Fri Feb 25 12:23:01

Anyone interested to read the rather large compile-messages?

Andreas

Re: Emacs 23.2.94 pretest

[Davis Herring]

> have an stdio.h at
>
> /usr/include
>
> here, not at /usr/local/include

Of course -- most systems (all?) put it there.  But nothing specifies a
full path; the compiler checks in many places, and died on
/usr/local/include before it looked in /usr/include.

Davis

-- 
This product is sold by volume, not by mass.  If it appears too dense or
too sparse, it is because mass-energy conversion has occurred during
shipping.