Warning: file_exists(): open_basedir restriction in effect. File(/srv/http/vhosts/aur.archlinux.org/public/web/locale//en/LC_MESSAGES/aurweb.mo) is not within the allowed path(s): (/srv/http/vhosts/aur-dev.archlinux.org/:/etc/aurweb/) in /srv/http/vhosts/aur-dev.archlinux.org/public/web/lib/streams.php on line 90
AUR (en) - emacs-git

Notice: Undefined variable: name in /srv/http/vhosts/aur-dev.archlinux.org/public/web/lib/pkgfuncs.inc.php on line 248

Package Details: emacs-git 26.0.50.127403-1

Git Clone URL: https://aur-dev.archlinux.org/emacs-git.git (read-only)
Package Base: emacs-git
Description: GNU Emacs. Master development branch.
Upstream URL: http://www.gnu.org/software/emacs/
Keywords: development editor IDE text
Licenses: GPL
Conflicts: emacs
Provides: emacs
Submitter: vorbote
Maintainer: vorbote
Last Packager: vorbote
Votes: 57
Popularity: 0.488209
First Submitted: 2014-01-05 02:05
Last Updated: 2016-11-14 14:03

Required by (196)

Sources (1)

Latest Comments

« First ‹ Previous ... 3 4 5 6 7 8 9 10 11 12 13 ... Next › Last »

nicolasavru commented on 2014-06-19 17:34

I tried the emacs-24 branch and it has the same issue. The reporter of the bug [1] also reports the same results. The current assumption is that it is a bug with something in the toolchain (gcc/binutils mentioned) related to link time optimization [2]. Compiling without link time optimization does indeed fix it.

As fir the giflib patch, it was already committed to the emacs-24 branch and should be merged into trunk soon.

Conclusion: the emacs-24 branch currently compiles without link time optimization. trunk does not yet have the giflib patch, but it will probably also only compile without link time optimization.

[1] http://lists.gnu.org/archive/html/bug-gnu-emacs/2014-06/msg00692.html
[2] http://lists.gnu.org/archive/html/bug-gnu-emacs/2014-06/msg00697.html

vorbote commented on 2014-06-19 13:42

Make that

$pkgname::git://git.savannah.gnu.org/emacs.git#branch=emacs-24

I am uploading the giflib patch as part of the PKGBUILD because there will be a fix integrated sometime soon. In the meantime I'll point you guys to this gist:

https://gist.github.com/palopezv/a88a038ba8c1473bfef5

vorbote commented on 2014-06-19 13:34

@nicolassavru Thanks for the heads up! I have applied cleanly a patch based on the bug report but as you poing out, there are serious problems with gettext in trunk.

For now I recommend to stay in whatever rev you are right now. If you are trying to compile emacs-git for the first time in your system be patient until trunk is unbroken, OR add "branch=emacs-24" to the git checkout line in sources as that will give you the stable maintenance tree.

I could upload that as a new PKGBUILD. You wouldn't need to redownload your git repo but rather move it, copy it or link it with a different name.

Let me know if you want that.

nicolasavru commented on 2014-06-19 01:57

The giflib bug should be fixed now: http://lists.gnu.org/archive/html/bug-gnu-emacs/2014-06/msg00565.html

Unfortunately I cannot test that because there is another bug preventing emacs trunk from building currently. This bug seems to also affect Debian unstable and has already been reported [1][2], but a fix hasn't been proposed yet.

[1] http://lists.gnu.org/archive/html/emacs-devel/2014-06/threads.html
[2] http://lists.gnu.org/archive/html/bug-gnu-emacs/2014-06/msg00683.html

guotsuan commented on 2014-06-17 09:33

Hi,
I tried to port the patch in emacs 24.3 in the extra repos to 24.4 emacs-git here. It works for me. Could you help test it and include it in the package if it is ok?
Thanks.

emacs-24.4-giflib5.patch
================================================================================
--- src/image.c
+++ src/image.c
@@ -7414,7 +7414,12 @@ gif_load (struct frame *f, struct image *img)
if (!check_image_size (f, gif->SWidth, gif->SHeight))
{
image_error ("Invalid image size (see `max-image-size')", Qnil, Qnil);
+#if GIFLIB_MAJOR >=5 && GIFLIB_MINOR >=1
+ fn_DGifCloseFile (gif, NULL);
+#else
fn_DGifCloseFile (gif);
+#endif
+
return 0;
}

@@ -7423,7 +7428,11 @@ gif_load (struct frame *f, struct image *img)
if (rc == GIF_ERROR || gif->ImageCount <= 0)
{
image_error ("Error reading `%s'", img->spec, Qnil);
+#if GIFLIB_MAJOR >=5 && GIFLIB_MINOR >=1
+ fn_DGifCloseFile (gif, NULL);
+#else
fn_DGifCloseFile (gif);
+#endif
return 0;
}

@@ -7435,7 +7444,12 @@ gif_load (struct frame *f, struct image *img)
{
image_error ("Invalid image number `%s' in image `%s'",
image_number, img->spec);
- fn_DGifCloseFile (gif);
+
+#if GIFLIB_MAJOR >=5 && GIFLIB_MINOR >=1
+ fn_DGifCloseFile (gif, NULL);
+#else
+ fn_DGifCloseFile (gif);
+#endif
return 0;
}
}
@@ -7453,7 +7467,11 @@ gif_load (struct frame *f, struct image *img)
if (!check_image_size (f, width, height))
{
image_error ("Invalid image size (see `max-image-size')", Qnil, Qnil);
+#if GIFLIB_MAJOR >=5 && GIFLIB_MINOR >=1
+ fn_DGifCloseFile (gif, NULL);
+#else
fn_DGifCloseFile (gif);
+#endif
return 0;
}

@@ -7471,7 +7489,11 @@ gif_load (struct frame *f, struct image *img)
&& 0 <= subimg_left && subimg_left <= width - subimg_width))
{
image_error ("Subimage does not fit in image", Qnil, Qnil);
- fn_DGifCloseFile (gif);
+#if GIFLIB_MAJOR >=5 && GIFLIB_MINOR >=1
+ fn_DGifCloseFile (gif, NULL);
+#else
+ fn_DGifCloseFile (gif);
+#endif
return 0;
}
}
@@ -7479,7 +7501,11 @@ gif_load (struct frame *f, struct image *img)
/* Create the X image and pixmap. */
if (!image_create_x_image_and_pixmap (f, img, width, height, 0, &ximg, 0))
{
+#if GIFLIB_MAJOR >=5 && GIFLIB_MINOR >=1
+ fn_DGifCloseFile (gif, NULL);
+#else
fn_DGifCloseFile (gif);
+#endif
return 0;
}

@@ -7650,7 +7676,11 @@ gif_load (struct frame *f, struct image *img)
Fcons (make_number (gif->ImageCount),
img->lisp_data));

- fn_DGifCloseFile (gif);
+#if GIFLIB_MAJOR >=5 && GIFLIB_MINOR >=1
+ fn_DGifCloseFile (gif, NULL);
+#else
+ fn_DGifCloseFile (gif);
+#endif

/* Maybe fill in the background field while we have ximg handy. */
if (NILP (image_spec_value (img->spec, QCbackground, NULL)))

vorbote commented on 2014-06-16 15:34

Sooo, the fix for now is to add "--without-gif" to the compilation options. All who have working installations should stay with them for the time being.

vorbote commented on 2014-06-16 15:23

LTO has nothing to do with building failures. It has all to do with the new giflib library in Arch, which emacs cannot handle. I don't have time right now to port the fix applied to emacs 2.4.3 in the extra repos. If anyone has the time and beats me to it, I'll gladly include it in this PKGBUILD.

guotsuan commented on 2014-06-15 23:46

with the option --enable-link-time-optimization
The building of the package failed.

I'm wondering if anyone met the same questions too?

vorbote commented on 2014-03-29 18:44

@fizban007 Thanks for the heads up and fix.

fizban007 commented on 2014-03-29 15:49

The PKGBUILD has a problem with pkgver() function in the latest git pull. It reads "bug-gnu-emacs@gnu.org" instead of the correct string "24.4.50". Consider changing the regex to the following

's/^.\+\ \([0-9]\+\.[0-9]\+\.[0-9]\+\).\+$/\1/'