Invalid symlinks for libungif.so and libungif.a

Bug #1337898 reported by Sebastian Marsching on 2014-07-04
34
This bug affects 6 people
Affects Status Importance Assigned to Milestone
giflib (Debian)
Fix Released
Unknown
giflib (Ubuntu)
Low
Unassigned
Trusty
Low
Unassigned

Bug Description

Impact
======
Linking programs that need libungif ("-lungif") will fail.

Test Case
=========
apt-get install build-essential libgif-dev
cat >>test.c EOF
int main(int argc, char **argv) {
  return 0;
}
EOF
gcc -lungif test.c

GCC will fail with "/usr/bin/ld: cannot find -lungif" on affected systems.

Regression Potential
====================
None, just removing some dangling symlinks that couldn't work any way.

Original Bug Report
===================
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/lib but in /usr/lib/x86_64-linux-gnu. Therefore, the symbol links are invalid.

I suggest fixing this by placing the symbol links in the same directory as the target files.

Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in giflib (Ubuntu):
status: New → Confirmed
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package giflib - 5.1.1-0ubuntu1

---------------
giflib (5.1.1-0ubuntu1) xenial; urgency=medium

  * New upstream version.
  * Enable parallel builds.
  * Build-depend on xmlto.
  * Don't ship broken libungif symlinks. Closes: #732272. LP: #1337898.

 -- Matthias Klose <email address hidden> Wed, 21 Oct 2015 16:28:17 +0200

Changed in giflib (Ubuntu):
status: Confirmed → Fix Released

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.

sds (sds-gnu) wrote :

I see

# ls -l libung*
0 lrwxrwxrwx 1 root root 8 Dec 16 2013 libungif.a -> libgif.a
0 lrwxrwxrwx 1 root root 9 Dec 16 2013 libungif.la -> libgif.la
0 lrwxrwxrwx 1 root root 15 Dec 16 2013 libungif.so -> libgif.so.4.1.6

after

# aptitude reinstall libgif-dev
The following packages will be REINSTALLED:
  libgif-dev
0 packages upgraded, 0 newly installed, 1 reinstalled, 0 to remove and 4 not upgraded.
Need to get 0 B/20.3 kB of archives. After unpacking 0 B will be used.
(Reading database ... 260156 files and directories currently installed.)
Preparing to unpack .../libgif-dev_4.1.6-11_amd64.deb ...
Unpacking libgif-dev (4.1.6-11) over (4.1.6-11) ...
Setting up libgif-dev (4.1.6-11) ...

@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.

Jeremy Bicha (jbicha) on 2016-12-25
tags: added: trusty
no longer affects: clojure (Ubuntu)
no longer affects: clojure (Ubuntu Trusty)
Changed in giflib (Ubuntu Trusty):
status: New → Triaged
importance: Undecided → Low
Jeremy Bicha (jbicha) wrote :

debdiff attached for sponsoring

description: updated
Changed in giflib (Ubuntu):
importance: Undecided → Low
tags: added: patch
tags: added: packaging
Robie Basak (racb) wrote :

Is there any actual impact to Trusty users, please? Or is this just tidying up some dangling symlinks for the sake of it?

Robie Basak (racb) wrote :

The "Impact" section in the bug whiteboard is supposed to contain this information for an SRU, but right now it seems to contain a technical description of what is wrong rather than describing any actual impact to users.

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: updated
Robie Basak (racb) wrote :

Uploaded, thanks!

I made the following minor changes:

1. I ran update-maintainer. Please see https://wiki.ubuntu.com/DebianMaintainerField

2. I adjusted the package version string to 4.1.6-11ubuntu0.14.04.1 because 4.1.6-11 also exists in Vivid. Though that's EOL on desktop, it lives on phone at the moment (and so does appear on Launchpad's summary page for the package). I don't want to make it awkward to update giflib on Vivid for the phone side. Though it seems unlikely and it probably doesn't use that package, at least this way we're consistent. See https://wiki.ubuntu.com/SecurityTeam/UpdatePreparation#Update_the_packaging.

Convention is to use a "-p1" patch, which is what debdiffs produce. Please try to do this when submitting patches, since it makes sponsoring a little easier.

Now awaiting SRU team review.

Changed in giflib (Ubuntu Trusty):
status: Triaged → In Progress

Hello Sebastian, or anyone else affected,

Accepted giflib into trusty-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/giflib/4.1.6-11ubuntu0.14.04.1 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed.Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, and change the tag from verification-needed to verification-done. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed. In either case, details of your testing will help us make a better decision.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance!

Changed in giflib (Ubuntu Trusty):
status: In Progress → Fix Committed
tags: added: verification-needed

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, whether this is by intention: Should libgif provide an alias for libungif (because it effectively provides the functionality of libungif) or is it an intentional choice not to provide libungif and should all software depending on it be changed to depend on libgif instead?

Robie Basak (racb) wrote :

Thank you for testing this.

I accepted the SRU on the assumption that "Linking programs that need libungif ("-lungif") will fail" would be fixed. In other words, that "-lungif" in the test case would now succeed. If this is not the case, then I think the SRU is pointless and that we shouldn't release it.

Jeremy, any opinion?

Robie Basak (racb) wrote :

> I accepted the SRU

I forgot which hat I was wearing. I sponsored it and Brian SRU-reviewed/accepted it. But my opinion is still the same.

Jeremy Bicha (jbicha) wrote :

Oh, maybe the test case is wrong. This SRU is the same fix as was done in Debian's 5.1.1 (present in Xenial) to "not ship broken symlinks".

See https://bugs.debian.org/732272 and comment #2

On Mon, Mar 06, 2017 at 12:47:20PM -0000, Jeremy Bicha wrote:
> Oh, maybe the test case is wrong. This SRU is the same fix as was done
> in Debian's 5.1.1 (present in Xenial) to "not ship broken symlinks".
>
> See https://bugs.debian.org/732272 and comment #2

Different considerations apply to the development release, of course.

But if that is what is proposed to be done in Trusty, why is the SRU
needed at all? This "fix" won't solve anything for the user, will it?

Robie Basak (racb) wrote :

Let's treat this as verification-failed, unless someone can give us a good reason that this does need to land in Trusty.

tags: added: verification-failed
removed: verification-needed

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 current situation and the risk of breaking something is very low. On the hand, I do not know whethere there are other considerations regarding a SRU in addition to the potential for regressions (which is low in this case).

Jeremy Bicha (jbicha) wrote :

Oh, now I know why the test case looked funny to me. The bug was updated because you didn't like the original, accurate impact and test case.

https://bugs.launchpad.net/ubuntu/+source/giflib/+bug/1337898/+activity

Sure, it's low priority but the fix isn't wrong.

Robie Basak (racb) wrote :

On Mon, Mar 06, 2017 at 01:27:14PM -0000, Sebastian Marsching wrote:
> 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.

Do we know if anyone has reported this case?

> In my opinion, removing the dangling symlinks is a slight improvement on
> the current situation and the risk of breaking something is very low. On
> the hand, I do not know whethere there are other considerations
> regarding a SRU in addition to the potential for regressions (which is
> low in this case).

The risk may be low but it is non-zero. If we don't know of any user
impacted, I don't think there is any justification for an SRU.

> Sure, it's low priority but the fix isn't wrong.

Sure, but that's something for the development release. In the stable
release, I think we need a better reason (such as non-hypothetical
affected users).

Changed in giflib (Debian):
status: Unknown → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.