hjm168168 / libmv

Automatically exported from code.google.com/p/libmv
MIT License
0 stars 0 forks source link

Recent change in makefiles make image_io test failed #19

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago
What steps will reproduce the problem?
1. Download the last version of libmv on the svn
2. Compile the code
3. Run test

What is the expected output? 
Test run fine...

What do you see instead?
image_io test failed :
From log files :
"
Wrong JPEG library version: library is 70, caller expects 62
E0629 11:00:03.951437 25703 image_io.cc:126] Error: Couldn't open 
hopefully_unexisting_file fopen returned 0
Wrong JPEG library version: library is 70, caller expects 62
E0629 11:00:03.951493 25703 image_io.cc:126] Error: Couldn't open 
hopefully_unexisting_file fopen returned 0
Wrong JPEG library version: library is 70, caller expects 62
"

Please use labels and text to provide additional information.

Original issue reported on code.google.com by pmou...@gmail.com on 29 Jun 2010 at 2:07

GoogleCodeExporter commented 9 years ago
Libjpeg is not yet included in the linux build. Your system must have a 
different version of libjpeg installed, so we'll need to fix and include the 
libjpeg (which is distributed with libmv) in the makefile.

Original comment by errant...@gmail.com on 29 Jun 2010 at 2:32

GoogleCodeExporter commented 9 years ago
Test run fines before the recent change in the CMakeLists.

Original comment by pmou...@gmail.com on 29 Jun 2010 at 2:47

GoogleCodeExporter commented 9 years ago
http://code.google.com/p/libmv/source/diff?spec=svn888&r=888&format=side&path=/t
runk/src/third_party/CMakeLists.txt

Original comment by pmou...@gmail.com on 29 Jun 2010 at 2:50

GoogleCodeExporter commented 9 years ago
Basically added libpng and zlib to the unix configuration... Don't know if 
there's somehow a dependency on a specific version libjpeg in there? If you 
haven't fixed it by then I'll also try running the tests on my system tonight.

Original comment by errant...@gmail.com on 29 Jun 2010 at 2:54

GoogleCodeExporter commented 9 years ago
Perhaps the problem is image_io referring to libjpeg being compiled, but 
actually linking against the library installed on the system...

Original comment by errant...@gmail.com on 29 Jun 2010 at 2:59

GoogleCodeExporter commented 9 years ago
If I comment jpeg-7 on the CMakeLists of thirdParty all the image_io test run 
fines. It uses my local jpeg lib.

I have tried to add the jpeg-7 path in the general CMakeLists but it gives me 
compilation error, because I think the linux header for JPEG lib is not present 
in our jpeg-7 version.

Original comment by pmou...@gmail.com on 29 Jun 2010 at 3:02

GoogleCodeExporter commented 9 years ago
Current fix for the problem could be :
12  IF(WIN32 OR APPLE OR UNIX)
13        #ADD_SUBDIRECTORY(jpeg-7)
14    ADD_SUBDIRECTORY(zlib)
15    ADD_SUBDIRECTORY(png)
16  ENDIF(WIN32 OR APPLE OR UNIX)
    IF(WIN32 OR APPLE)
      ADD_SUBDIRECTORY(jpeg-7)
    ENDIF(WIN32 OR APPLE)

Original comment by pmou...@gmail.com on 29 Jun 2010 at 3:05

GoogleCodeExporter commented 9 years ago
Yes that sounds about right to me. It should solve the problem until libjpeg 
can be properly included in the build.

Original comment by errant...@gmail.com on 29 Jun 2010 at 3:08

GoogleCodeExporter commented 9 years ago
We will wait the test on your machine before any commit. If the test failed 
also on your machine, so we will commit the fix (only add_subdirectory jpeg-7 
on win32 and apple).

Original comment by pmou...@gmail.com on 29 Jun 2010 at 3:13

GoogleCodeExporter commented 9 years ago
Same test fails on my machine. Makes sense since ubuntu has jpeg version 6.2. 
In future I'll try and remember to run the test suite first, thanks!

Original comment by errant...@gmail.com on 29 Jun 2010 at 6:08

GoogleCodeExporter commented 9 years ago
Fixed.
See commit : http://code.google.com/p/libmv/source/detail?r=898

Original comment by pmou...@gmail.com on 3 Jul 2010 at 8:52