Package Details: enchant1.6 1.6.1-9

Git Clone URL: https://aur.archlinux.org/enchant1.6.git (read-only, click to copy)
Package Base: enchant1.6
Description: A wrapper library for generic spell checking
Upstream URL: https://abiword.github.io/enchant/
Licenses: LGPL
Submitter: Schmeidenbacher
Maintainer: bidulock
Last Packager: bidulock
Votes: 20
Popularity: 0.000000
First Submitted: 2017-12-03 12:19 (UTC)
Last Updated: 2021-05-25 05:07 (UTC)

Latest Comments

« First ‹ Previous 1 2 3 Next › Last »

Schmeidenbacher commented on 2017-12-07 16:44 (UTC)

@philo: You'll have to tell that to the maintainer of the rainlendar-lite package. They have to add it as a dependency to be listed here.

@Tharbad: Are we talking about the automake issue? That one remained for me as well. This package can only be reliably built in a clean chroot (https://wiki.archlinux.org/index.php/DeveloperWiki:Building_in_a_Clean_Chroot).

philo commented on 2017-12-07 16:04 (UTC)

Also required by rainlendar-lite!

Tharbad commented on 2017-12-07 11:53 (UTC) (edited on 2017-12-07 14:22 (UTC) by Tharbad)

Doesn't work for me. Error remains. Same for v5

dtbaumann commented on 2017-12-06 19:33 (UTC) (edited on 2017-12-06 19:37 (UTC) by dtbaumann)

I moved "./autogen.sh" from prepare() to build() and dropped the NOCONFIGURE=1 statement to resolve the automake error.

simona commented on 2017-12-06 09:40 (UTC) (edited on 2017-12-06 09:42 (UTC) by simona)

==> Avvio di prepare() in corso...

aclocal: overwriting 'm4/ax_cxx_compile_stdcxx.m4' with '/usr/share/aclocal/ax_cxx_compile_stdcxx.m4' aclocal: installing 'm4/libtool.m4' from '/usr/share/aclocal/libtool.m4' aclocal: installing 'm4/ltoptions.m4' from '/usr/share/aclocal/ltoptions.m4' aclocal: installing 'm4/ltsugar.m4' from '/usr/share/aclocal/ltsugar.m4' aclocal: installing 'm4/ltversion.m4' from '/usr/share/aclocal/ltversion.m4' aclocal: installing 'm4/lt~obsolete.m4' from '/usr/share/aclocal/lt~obsolete.m4' aclocal: installing 'm4/pkg.m4' from '/usr/share/aclocal/pkg.m4' aclocal: installing 'm4/ax_require_defined.m4' from '/usr/share/aclocal/ax_require_defined.m4'

aclocal: error: too many loops

aclocal: Please contact bug-automake@gnu.org. at /usr/share/automake-1.15/Automake/Channels.pm line 662.

    Automake::Channels::msg("automake", "", "too many loops") called at /usr/share/automake-1.15/Automake/ChannelDefs.pm line 212

    Automake::ChannelDefs::prog_error("too many loops") called at /usr/bin/aclocal line 1188

==> ERRORE: Si è verificato un errore in prepare().

aspirogrammer commented on 2017-12-05 23:53 (UTC)

I tested the mentioned fix; works here.

eschwartz commented on 2017-12-05 19:02 (UTC) (edited on 2017-12-05 19:13 (UTC) by eschwartz)

Unfortunately, this package sucks as it causes this bug: https://bugs.archlinux.org/task/56597

Please use versioning for the installed plugins, or at least conflict with the official package.

You should be able to version this by patching src/Makefile.am to define ENCHANT_GLOBAL_MODULE_DIR=\"$(libdir)/enchant1.6\" instead of its current definition of ENCHANT_GLOBAL_MODULE_DIR=\"$(libdir)/enchant\"

Also _tempdir="$srcdir/temp"

EDIT: okay, why does readelf claim that the enchant plugins for enchant1.6 are linked against libenchant.so.2

ivanruvalcaba commented on 2017-12-04 12:45 (UTC)

Nice day!

I'm also presenting this issue with automake in my system. Would you be so kind as to check this out?

willspoke commented on 2017-12-04 07:53 (UTC)

without using pacaur the following error occurs:

aclocal: error: too many loops aclocal: Please contact bug-automake@gnu.org. at /usr/share/automake-1.15/Automake/Channels.pm line 662. Automake::Channels::msg("automake", "", "too many loops") called at /usr/share/automake-1.15/Automake/ChannelDefs.pm line 212 Automake::ChannelDefs::prog_error("too many loops") called at /usr/bin/aclocal line 1188

Schmeidenbacher commented on 2017-12-03 21:16 (UTC)

No idea. I don't use pacaur and i only have the time to support official build tools. I did check out the pacaur source code to see what it does, but it mostly seems to do it's own thing.

I suspect it puts the source code in some other folder than the PKGBUILD and rewrites the $pkgdir variable with it's own thing. Since i had to change that to another variable i can't really say what you would have to change for that. Sorry.

« First ‹ Previous 1 2 3 Next › Last »