Package Details: goldendict-git 1:1.5.0rc2.r521.g99982a1c-2

Git Clone URL: https://aur.archlinux.org/goldendict-git.git (read-only, click to copy)
Package Base: goldendict-git
Description: Feature-rich dictionary lookup program supporting multiple dictionary formats
Upstream URL: https://github.com/goldendict/goldendict
Licenses: GPL3
Conflicts: goldendict
Provides: goldendict
Submitter: Infy
Maintainer: aksr
Last Packager: MarsSeed
Votes: 93
Popularity: 0.010415
First Submitted: 2009-11-13 13:32 (UTC)
Last Updated: 2022-06-08 02:16 (UTC)

Latest Comments

« First ‹ Previous 1 2 3 4 5 6 7 8 9 10 .. 15 Next › Last »

InnerPeace commented on 2022-06-23 12:25 (UTC) (edited on 2022-06-23 12:26 (UTC) by InnerPeace)

Hi @MarsSeed, Yes, this solved my problem of target not found 'libeb'. Finally, I have installed goldendict successfully!. Thanks for your suggestion.

MarsSeed commented on 2022-06-12 10:48 (UTC)

Hi @InnerPeace,

First you have to package and install libeb from AUR to be able to build this package. :)

But what I recommend instead:

pacman -Syu base-devel
git clone https://aur.archlinux.org/yay.git
cd yay
makepkg --syncdeps --rmdeps --install

After that, you can just use

yay -Syu goldendict-git

and that will install all the dependencies of it, including libeb.

InnerPeace commented on 2022-06-12 05:41 (UTC) (edited on 2022-06-12 05:42 (UTC) by InnerPeace)

I just git clone it to my arch system. But, after I use command makepkg -si , it so me error : target not found 'libeb'. I have reupdate my arch with pacman -S Syu but still the same. Anyone can take me out. Thanks.

MarsSeed commented on 2022-06-08 12:31 (UTC)

This turned out to be quite educational for me.

With your help I've learnt that yes, GNU's libc (a.k.a. glibc) does indeed contain an iconv() encoding converter implementation (one which is both very robust and fast at the same time, and supports a dizzyingly large number of encoding formats).

On the other hand, the GNU project also provides the libiconv library, for operating systems that don't have a built-in iconv() function.

That said, libeb's autoconf setup was definitely at fault here, by accidentally linking to libiconv on Linux (erm, GNU/Linux) in spite of the fact that the code itself is using glibc's version on such systems. (Those configuration scripts are, frankly, quite a convoluted mess in libeb.)

Anyway, TLDR; libiconv is for non-GNU/Linux systems so by default it is not needed and should not be used on Linux.

(And now I'm wondering why on Earth did AUR/libiconv get adopted into the Arch [community] repo... Because it is redundant on Arch 'GNU/Linux'! Also, nothing in Arch repos use that library. But to each their own.. :] )

MarsSeed commented on 2022-06-08 07:05 (UTC)

Thanks for reporting the issue! Glad that it got solved now by the rebuild.

vedg commented on 2022-06-08 06:55 (UTC) (edited on 2022-06-08 06:57 (UTC) by vedg)

@vedg indeed, please try to rebuild both now (latest versions from AUR).

Thanks. Rebuilding libeb alone sufficed: now ldd /usr/bin/goldendict |grep iconv returns nothing and removing libiconv no longer affects GoldenDict.

MarsSeed commented on 2022-06-08 02:24 (UTC) (edited on 2022-06-08 07:03 (UTC) by MarsSeed)

@vedg indeed, please try to rebuild both now (latest versions from AUR).

I've realized that the autoconf scripts of libeb were force-linking libiconv, libnsl and libresolv to the libeb.so.2 file, even though those links ended up unused:

$ namcap libeb-4.4.3-8-x86_64.pkg.tar.zst

libeb W: Unused shared library '/usr/lib/libiconv.so.2' by file ('usr/lib/libeb.so.16.0.0')
libeb W: Unused shared library '/usr/lib/libnsl.so.3' by file ('usr/lib/libeb.so.16.0.0')
libeb W: Unused shared library '/usr/lib/libresolv.so.2' by file ('usr/lib/libeb.so.16.0.0')

This led to the situation that if libiconv was installed before building libeb, it got linked to it; whereas if libeb was built while libiconv was not installed, then the libeb.so binary did not have any links to libiconv.

vedg commented on 2022-06-07 17:51 (UTC) (edited on 2022-06-07 17:53 (UTC) by vedg)

@vedg which commit version do you have of goldendict-git?

The version was a customized (not related to libiconv) variant based on https://github.com/goldendict/goldendict/commit/b10cdf685c8c02d2be2f1ae4f1e03a4e02db48d8. I just built customized goldendict-git based on latest master with libiconv uninstalled. But the following warning appeared at the end of the build log:

linking goldendict
/usr/bin/ld: warning: libiconv.so.2, needed by /usr/lib/gcc/x86_64-pc-linux-gnu/12.1.0/../../../../lib/libeb.so, not found (try using -rpath or -rpath-link)

Then goldendict failed to launch until I reinstalled libiconv:

$ ldd /usr/bin/goldendict |grep iconv
    libiconv.so.2 => not found
$ goldendict
goldendict: error while loading shared libraries: libiconv.so.2: cannot open shared object file: No such file or directory

Do I have to rebuild libeb to get rid of the transitive libiconv dependency?

Note that iconv.h included in GoldenDict's iconv.hh is provided by glibc:

$ pacman -Qo /usr/include/iconv.h
/usr/include/iconv.h is owned by glibc 2.35-5

MarsSeed commented on 2022-06-07 15:49 (UTC) (edited on 2022-06-07 15:49 (UTC) by MarsSeed) 

$ ldd /usr/bin/goldendict |grep iconv libiconv.so.2 => /usr/lib/libiconv.so.2 (0x00007f5cf043e000)

@vedg which commit version do you have of goldendict-git?

MarsSeed commented on 2022-06-07 15:45 (UTC)

But for some reason, the project makefiles don't link to the libiconv C library during build; only on Windows, Mac, FreeBSD, and on ARM platforms, but otherwise not on Linux.

« First ‹ Previous 1 2 3 4 5 6 7 8 9 10 .. 15 Next › Last »