I guess there is only one case where the current "fix" would help. If
someone had some library providing libungif in a different place, the
broken symlinks in /usr/lib might take precedence, thus hiding the
correct files.
In my opinion, removing the dangling symlinks is a slight improvement on
the
I tested the package from trusty-proposed, but I am not sure whether the
issue can be considered fixed.
In fact, the dangling symlinks have been removed, but they have not been
added in the right place. This means that software depending on libungif
will still not compile.
The question is, whethe
I updated the Impact and Test Case sections of this bug's description. I
hope this better fits the purpose of describing the actual impact on
users.
** Description changed:
Impact
==
- libgif-dev in Ubuntu 14.04 LTS depends on libgif4 and has these symlinks:
- /usr/lib/libungif.a -> libgi
The workaround suggested by Ikuya Awashiro (setting the gateway for the
route to 0.0.0.0) does not work for me. The problem persits even after
applying this workaround. The VPN connection is only established when
all static routes are deleted from the configuration.
--
You received this bug notif
@sds: Yes, they exist, but in /usr/lib, while they should be in
/usr/lib/x86_64-linux-gnu (depending on the platform). As libgif.* is
not in /usr/lib, the symbol links point to files that do not exist.
--
You received this bug notification because you are a member of Desktop
Packages, which is su
Are there any plans to backport this change to giflib-4.1.6-11 on
trusty? Considering that trusty is still going to be supported for more
than three years, it might make sense to backport this bugfix.
--
You received this bug notification because you are a member of Desktop
Packages, which is sub
Public bug reported:
In Ubuntu 14.04 LTS on x86_64 I am experiencing the following bug in
libgif-dev 4.1.6-11:
Symbol links for libungif.a, libungif.la, and libungif.so are created in
/usr/lib that point to libgif.a, libgif.la and libgif.so.4.1.6
respectively. However, these files are not in /usr
7 matches
Mail list logo
