On November 27, 2010 01:46:36 pm Kornel Benko wrote:
> Am Samstag, 27. November 2010 schrieb Andreas Metzler:
> > Yuval Levy <[email protected]> wrote:
> > > dpkg-shlibdeps: error: no dependency information found for
> > > /usr/lib/libGL.so.1
> > 
> > I am not sure but this might be caused by building on a system
> > with non-free graphic drivers (nvidia or MTI/AMD's fglrx) whose
> > packaging leaves something to be desired.
> 
> Looks like the last upgrade (in ubuntu 10.10) for nvidia made a change from
>       /usr/lib/libGL.so.1
> to
>       /usr/lib/nvidia-173/libGL.so.1
> but our cmake does not find the correct lib. On my system both shared libs
> are still there.

I have a slightly messier situation here.  I am subscribed to the cutting edge 
nvidia-vdpau ppa (it was the only way to get proper H.264 accelerated playback 
of AVCHD video).

/usr/lib/libGL.so.1 is here.

I don't have any /usr/lib/nvidia-173 folder.

I do have an /usr/lib/nvidia and an /usr/lib/nvidia-current folder

In /usr/lib/nvidia is only a root-owned script to prevent the installer from 
overwriting Ubuntu's nvidia packages.

In /usr/lib/nvidia-current there are a few things, including 
libGLcore.so.195.36.24

I need the system to process AVCHD videos.  I won't revert it to the nouveau 
driver, so it won't do for test-building the source package.

I decided to try to push the source package as-is to Ubuntu's build farm.  My 
educated guess is that they don't have the nvidia proprietary driver there.  
The build failed.  My conclusion is that the proprietary driver is unlikely to 
be the (only) problem with my build.

From the build log [0]:

CMake Error: The following variables are used in this project, but they are 
set to NOTFOUND.
Please set them or make sure they are set and tested correctly in the CMake 
files:
GLUT_Xmu_LIBRARY (ADVANCED)
    linked by target "huginbase" in directory 
/build/buildd/hugin-2010.4.0beta1~lucid1/src/hugin_base
    linked by target "align_image_stack" in directory 
/build/buildd/hugin-2010.4.0beta1~lucid1/src/tools
    linked by target "nona" in directory 
/build/buildd/hugin-2010.4.0beta1~lucid1/src/tools
    linked by target "hugin" in directory 
/build/buildd/hugin-2010.4.0beta1~lucid1/src/hugin1/hugin
    linked by target "nona_gui" in directory 
/build/buildd/hugin-2010.4.0beta1~lucid1/src/hugin1/nona_gui

I think this confirms the discrepancy reported by Kornel.

 
> So there is a discrepancy.
> In CMakeCache.txt we are referencing
>       OPENGL_gl_LIBRARY:FILEPATH=/usr/lib/libGL.so
> but later at runtime we have.
>       # ldd /usr/local/bin/hugin | grep libGL.so
>               -> libGL.so.1 => /usr/lib/nvidia-173/libGL.so.1 
> (0x00007f76de6a0000)
> 
> The cmake module FindOpenGL.cmake finds the wrong lib. But removing this
> lib is not an option, because otherwise follows "OpenGL was not found,
> hugin disabled" on subsequent cmake call.
> 
> I am unsure what to do here.

No idea either.  CMake works fine locally, then why not on the build farm?

Maybe there is one step that I am not doing right with the patches, 
specifically the 42_stoplinklibXI_libXmu is not being applied?

I recall reading that if I manually unpack the source tarballs and don't apply 
the patches, later on when building dpkg-buildpackage will take care of 
applying the patches. 

So what I did was simply untar the 2010.4beta1 source package, copy into it a 
working ./debian folder from the previous debian source package (including the 
patches), make my edits inside the ./debian folder, use dch to update the 
debian changelog and then dpkg-buildpackage, assuming it would apply the 
patches.  But now I don't see a ./.pc folder - indication that the patches 
have not been applied?

anyway, while I can't risk too much on my workstation, I have an HTPC which I 
can sacrifice.  I'll see that I install a fresh system there and try to build 
on that one.  The builds will be much slower (atom at work).

Yuv


[0] <http://launchpadlibrarian.net/59714901/buildlog_ubuntu-lucid-
amd64.hugin_2010.4.0beta1~lucid1_FAILEDTOBUILD.txt.gz>

Attachment: signature.asc
Description: This is a digitally signed message part.

Reply via email to