Bug 439979 - libvncserver is using internal version of minilzo
libvncserver is using internal version of minilzo
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: libvncserver (Show other bugs)
14
All Linux
medium Severity medium
: ---
: ---
Assigned To: Rex Dieter
Fedora Extras Quality Assurance
: Patch, Reopened, Triaged
Depends On:
Blocks: x11vnc-review
  Show dependency treegraph
 
Reported: 2008-04-01 02:39 EDT by Marek Mahut
Modified: 2011-12-13 09:40 EST (History)
7 users (show)

See Also:
Fixed In Version: 0.9.1-3
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2011-12-13 09:40:09 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
new spec (2.85 KB, text/plain)
2008-04-10 15:44 EDT, manuel wolfshant
no flags Details
patch which removes references to minilzo from Makefile.* (6.45 KB, patch)
2008-04-10 15:45 EDT, manuel wolfshant
no flags Details | Diff
log for failed mock build (41.08 KB, text/plain)
2008-04-10 15:46 EDT, manuel wolfshant
no flags Details
revised spec -- explicitely adds libminilzo to %make (2.90 KB, text/plain)
2008-04-10 17:02 EDT, manuel wolfshant
no flags Details
x11vnc-0.9.8-use-system-minilzo.patch (185.16 KB, patch)
2009-07-22 13:39 EDT, Pavel Alexeev
no flags Details | Diff

  None (edit)
Description Marek Mahut 2008-04-01 02:39:19 EDT
Description of problem:

libvncserver is using static minilzo code:

  ./LibVNCServer-0.9.1/libvncserver/lzoconf.h
  ./LibVNCServer-0.9.1/libvncserver/minilzo.c
  ./LibVNCServer-0.9.1/libvncserver/minilzo.h
  ./LibVNCServer-0.9.1/libvncclient/lzoconf.h
  ./LibVNCServer-0.9.1/libvncclient/minilzo.c
  ./LibVNCServer-0.9.1/libvncclient/minilzo.h

This is in violation of packaging guidelines.
http://fedoraproject.org/wiki/Packaging/Guidelines#head-17396a3b06ec849a7c0c6fc3243673b17e5fed90

The elegant solution would be if Steven or Hans include a sub-package minilzo to
lzo package (as it's from same upstream, same functionality) so we can use this
to build libvncserver.

Hans, Steven, Thoughts?


Version-Release number of selected component (if applicable):

libvncserver-0.9.1-2.fc8
Comment 1 Hans de Goede 2008-04-02 11:03:25 EDT
Adding a minilzo shared lib is fine by me, here is a proposed new version with
minilzo sub-package, can someone check this works as intended?

http://people.atrpms.net/~hdegoede/lzo-2.02-5.fc9.src.rpm
http://people.atrpms.net/~hdegoede/lzo.spec
Comment 2 Marek Mahut 2008-04-02 12:02:20 EDT
lzo-2.02-5.fc9 works fine for me
Comment 3 Hans de Goede 2008-04-02 13:32:36 EDT
(In reply to comment #2)
> lzo-2.02-5.fc9 works fine for me

As in you build a libvncserver using this minilzo instead of the included one,
and that works, or ... ?
Comment 4 Marek Mahut 2008-04-05 07:47:31 EDT
Rex, can you check and reply to comment #3, please?
Comment 5 Marek Mahut 2008-04-10 08:38:54 EDT
ping Rex
ping Steve
Comment 6 Rex Dieter 2008-04-10 09:14:30 EDT
sorry, busy, plate overfull atm (f9/kde4 fun and all).  I'll have to (re)visit
this when things settle down a bit.
Comment 7 manuel wolfshant 2008-04-10 15:44:59 EDT
Created attachment 302058 [details]
new spec
Comment 8 manuel wolfshant 2008-04-10 15:45:43 EDT
Created attachment 302060 [details]
patch which removes references to minilzo from Makefile.*
Comment 9 manuel wolfshant 2008-04-10 15:46:30 EDT
Created attachment 302061 [details]
log for failed mock build
Comment 10 manuel wolfshant 2008-04-10 15:49:30 EDT
I've tried to use Hans's minilzo package (from comment #1) instead of the
internal copy of minilzo, but I had no success so far.
If someone more experienced can lend a hand, please do.
I have attached the new spec, the patch which removes references to minilzo from
Makefile.* (I might have been wrong here..., my autofoo skills are nil ) and the
log of the failed build.
Comment 11 manuel wolfshant 2008-04-10 17:01:31 EDT
I kind of fixed it (it builds, but it's ugly as hell).  Revised spec attached.
Comment 12 manuel wolfshant 2008-04-10 17:02:38 EDT
Created attachment 302074 [details]
revised spec -- explicitely adds libminilzo to %make
Comment 13 manuel wolfshant 2008-04-10 18:32:41 EDT
Retested: lzo-devel can be ditched from the BR; lzo-minilzo is enough for a mock
build
Comment 14 Hans de Goede 2008-04-11 01:32:34 EDT
(In reply to comment #13)
> Retested: lzo-devel can be ditched from the BR; lzo-minilzo is enough for a mock
> build

That doesn't sound right, because then you don't have the .so symlink to link
to, nor the headers to include, so this sounds like you're still building
against the included copy.

Try "rm -fr <includeded-copy>" in %prep, that always helps to ensure you are
really using the system version.
Comment 15 manuel wolfshant 2008-04-11 16:46:27 EDT
Mkey, so Hans was right. The bundled minilzo was still used. I've nuked it with
find -exec rm -f and patched the sources to use #include <minilzo.h> instead of
#include "minilzo.h"
The good part is that the package now builds.
The bad part[s] are
- I had to add /usr/include/lzo and -Llibminilzo.so to the %make line, otherwise
neither the includes not the lib are seen/used (and build freakes out with nasty
'minilzo.h file not found' or 'symbol <smtg-related-to-compress>' errors)
- the binary rpms do not seem to have a dependency on minilzo (or lzo)

I've uploaded to http://wolfy.fedorapeople.org/x11vnc/ the patch, the new spec
and the rpms; I am in dark now so a helping hand would be useful.
Comment 16 Hans de Goede 2008-04-13 15:33:16 EDT
(In reply to comment #15)


> - the binary rpms do not seem to have a dependency on minilzo (or lzo)
> 

Thats bad, the should depend upon libminilzo.so.0
Comment 17 manuel wolfshant 2008-04-13 15:49:47 EDT
I know, that's what puzzles me. It does not build unless I use 
   make CFLAGS="$RPM_OPT_FLAGS %{_libdir}/libminilzo.so.0 -I %{_includedir}/lzo"
but (kind of obviously in fact ) rpmbuild does not find any dependency on lzo

When I tried
   make CFLAGS="$RPM_OPT_FLAGS -l%{_libdir}/libminilzo.so.0 -I %{_includedir}/lzo".
(thus notifying that libminilzo.so is a library) build failed with:

make[2]: Entering directory
`/builddir/build/BUILD/LibVNCServer-0.9.1/client_examples'
if gcc -DHAVE_CONFIG_H -I. -I. -I..    -I .. -g -Wall -O2 -g -pipe -Wall
-Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-prote
ctor --param=ssp-buffer-size=4 -m64 -mtune=generic -l/usr/lib64/libminilzo.so.0
-I /usr/include/lzo -MT ppmtest.o -MD -MP -
MF ".deps/ppmtest.Tpo" -c -o ppmtest.o ppmtest.c; \
        then mv -f ".deps/ppmtest.Tpo" ".deps/ppmtest.Po"; else rm -f
".deps/ppmtest.Tpo"; exit 1; fi
make[2]: *** No rule to make target `../libvncclient/libvncclient.la', needed by
`ppmtest'.  Stop.
make[2]: *** Waiting for unfinished jobs....
ppmtest.c: In function 'SaveFramebufferAsPPM':
ppmtest.c:43: warning: pointer targets in initialization differ in signedness
make[2]: Leaving directory
`/builddir/build/BUILD/LibVNCServer-0.9.1/client_examples'

Comment 18 Hans de Goede 2008-04-13 16:18:24 EDT
You should be specifying just "-lminilzo" and not as CFLAGs but as LDFLAGS /
LIBS argument
Comment 19 manuel wolfshant 2008-04-13 17:59:43 EDT
Thanks Hans, that was it.
Even I still wonder why are CFLAGS=-I/usr/include/lzo and LDFLAGS=-lminilzo
needed., I have uploaded to http://wolfy.fedorapeople.org/x11vnc/ the libvnc*
related source stuff (patch, spec, src.rpm).
Since I might have missed something, I would appreciate a critical eye over 
  http://wolfy.fedorapeople.org/x11vnc/libvncserver.spec
(and over all the libvncserver related files from the above mentioned URL)

Anyway, Hans, could you please update lzo in rawhide ? AFAICS, packages from #1
seem OK.

Assuming my patch is correct, libvncserver should also be updated (Rex, if this
is OK with you I can do it, I've noticed that cvs access is open)
Comment 20 Hans de Goede 2008-04-14 03:14:39 EDT
(In reply to comment #19)
> Thanks Hans, that was it.
> Even I still wonder why are CFLAGS=-I/usr/include/lzo and LDFLAGS=-lminilzo
> needed.

Thats normal when you manually modify a package to build against a system
version of some lib.

> Anyway, Hans, could you please update lzo in rawhide ? AFAICS, packages from #1
> seem OK.
> 

Its building for rawhide inclusion now, but won't show up there until after the
freeze, if you want a fixed version of vncserver to be included in F-9, someone
should mail rel-eng to ask them to tag the new lzo for F-9 inclusion.
Comment 21 Rex Dieter 2008-04-14 07:33:51 EDT
> Rex, if this is OK with you I can do it

go for it, but I don't think it's worth breaking f9 freeze for.  I'd like to see
a little more testing for this.
Comment 22 manuel wolfshant 2008-04-14 16:34:32 EDT
Understood. I will upload to CVS (for the case someone wants to use the modified
code) but I will postpone build till after F9 release.
Comment 23 manuel wolfshant 2008-04-27 08:53:48 EDT
sucessfully built in rawhide. thanks for support to all those involved.
Comment 24 Axel Thimm 2008-09-19 03:32:28 EDT
libvncserver-devel still needs some work for other projects like x11vnc to build against. I patched up x11vnc to use a shared minilzo, but using the system libvncserver breaks the build.

Maybe it makes more sense to stick with a static build of minilzo? That was minilzo's purpose after all, and if a shared lib is desired it should probably be lzo and not minilzo.

See the stalled bug 439772, that would have made it into Fedora half a year ago if it were not for building against a shared minilzo both from x11vnc and libvncserver.

At any rate this package needs some adjustments to be able to build against libvncserver-devel. It is either sticking to shared minilzo and fixing *-devel or reversing the shared minilzo setup.

Note: this is about not sharing minilzo, but sharing libvncserver. The irony is that by over interpreting the guidelines this has made it actually more difficult to adhere to them. Upstream makes it easy to use static minilzo and shared libvncserver, we now have the opposite.
Comment 25 Rex Dieter 2008-09-19 08:43:19 EDT
> libvncserver-devel still needs some work

details?
Comment 26 Axel Thimm 2008-09-19 13:26:25 EDT
See the blocking bug for some. I managed to remove all traces of the internal minilzo from x11vnc only to find that libvncserver(-devel) would bring some back in.

But please take the bird's eye approach: Is it worth to work against upstream to create a maintenance issue for every minilzo consuming package there is out there? The idea with minilzo was to use it only as an internal copy. If one wants the shared lib one should use lzo directly. We are now bastardizing things, and by design lzo;s author may change minilzo's ABI at any time w/o any warning, as it was not intended to have one in the first place.
Comment 27 Rex Dieter 2008-09-19 14:04:26 EDT
> See the blocking bug for some.

All I see is a single pkg not building, but no details how/why.  I was hoping to avoid having to grok build.log's.
Comment 28 Bug Zapper 2008-11-25 21:11:31 EST
This bug appears to have been reported against 'rawhide' during the Fedora 10 development cycle.
Changing version to '10'.

More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 29 Rex Dieter 2009-04-08 10:11:18 EDT
->rawhide, needs to be fixed there first.
Comment 30 Bug Zapper 2009-06-09 05:31:10 EDT
This bug appears to have been reported against 'rawhide' during the Fedora 11 development cycle.
Changing version to '11'.

More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 31 Pavel Alexeev 2009-07-22 13:39:47 EDT
Created attachment 354753 [details]
x11vnc-0.9.8-use-system-minilzo.patch

I think in you you cut links to bundled minilzo (for insurance I also delete this files too), patch missed only part where system one com in.

Please see this patch from x11vnc current build. In it libvncserver built correctly with system (mini)lzo.
Comment 32 Axel Thimm 2009-07-23 10:54:35 EDT
How difficult would it be to use lzo proper instead of the made-system-shared minilzo?
Comment 33 Pavel Alexeev 2009-07-23 13:50:02 EDT
What reason again use static anything if it present in system already?
Comment 34 Bug Zapper 2009-11-16 03:03:26 EST
This bug appears to have been reported against 'rawhide' during the Fedora 12 development cycle.
Changing version to '12'.

More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 35 Bug Zapper 2010-11-04 07:58:28 EDT
This message is a reminder that Fedora 12 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 12.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '12'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 12's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 12 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 36 Bug Zapper 2010-12-05 02:12:25 EST
Fedora 12 changed to end-of-life (EOL) status on 2010-12-02. Fedora 12 is 
no longer maintained, which means that it will not receive any further 
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of 
Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.
Comment 37 Pavel Alexeev 2010-12-05 07:34:36 EST
Is it problem fixed in Fedora 14?
Comment 38 Rex Dieter 2011-12-13 09:40:09 EST
Yep,looks like we just forgot to close this out:

* Thu Apr 10 2008 Manuel Wolfshant <wolfy@fedoraproject.org> 0.9.1-3
- do not use bundled copy of minilzo (#439979)

Note You need to log in before you can comment on or make changes to this bug.