Problem compiling SpliX on Fedora 13

Help
2010-08-27
2013-05-28
  • I have just got a Samsung CLX-3175FN MFP.  AFAIK the printer element is equivalent to CLP-315.  As I get problems using the Foomatic foo2qpdl driver I am trying to build SpliX 2.0.0 from source. However I get the following errors when running "make":-

    [root@localhost splix-2.0.0]# make
     +---------------------------------------------+
     |      COMPILATION PARAMETERS SUMMARY         |
     +---------------------------------------------+
     |      THREADS     =  enabled                 |
     |      THREADS Nr  =        2                 |
     |      CACHESIZE   =       30                 |
     |      JBIG        =  enabled                 |
     |      BLACK OPTIM =  enabled                 |
     +---------------------------------------------+
     (Do a "make clean" before updating these values)
         CXX               src/rastertoqpdl.cpp
         CXX               src/request.cpp
         CXX               src/printer.cpp
         CXX               src/qpdl.cpp
    src/qpdl.cpp: In function bool _renderBand(const Request&, const Band*, bool):
    src/qpdl.cpp:115: warning: dereferencing type-punned pointer will break strict-aliasing rules
         CXX               src/document.cpp
    src/document.cpp: In member function Page* Document::getNextRawPage(const Request&):
    src/document.cpp:84: warning: unsigned int cupsRasterReadHeader(cups_raster_t*, cups_page_header_t*) is deprecated (declared at /usr/include/cups/raster.h:321)
    src/document.cpp:84: warning: unsigned int cupsRasterReadHeader(cups_raster_t*, cups_page_header_t*) is deprecated (declared at /usr/include/cups/raster.h:321)
         CXX               src/core.cpp
         CXX               src/compress.cpp
         CXX               src/algorithm.cpp
         CXX               src/ppdfile.cpp
         CXX               src/page.cpp
         CXX               src/colors.cpp
         CXX               src/band.cpp
         CXX               src/bandplane.cpp
         CXX               src/cache.cpp
         CXX               src/rendering.cpp
         CXX               src/semaphore.cpp
         CXX               src/algo0x0d.cpp
         CXX               src/algo0x0e.cpp
         CXX               src/algo0x11.cpp
         CXX               src/algo0x13.cpp
         LINK              optimized/rastertoqpdl
    /usr/bin/ld: optimized/src/cache.o: undefined reference to symbol 'pthread_create@@GLIBC_2.2.5'
    /usr/bin/ld: note: 'pthread_create@@GLIBC_2.2.5' is defined in DSO /lib64/libpthread.so.0 so try adding it to the linker command line
    /lib64/libpthread.so.0: could not read symbols: Invalid operation
    collect2: ld returned 1 exit status
    make: *** [optimized/rastertoqpdl] Error 1
    

    /lib64/libpthread.so.0 is in fact a symlink to /lib64/libpthread-2.12.so, both provided by glibc-2.12-3. I have installed the -lib and -devel packages for both cups and jbig - this fixed other earlier errors due to their absence.

    I am running Fedora 13 on x86_64 architecture (kernel 2.6.33.8-149.fc13.x86_64). There doesn't appear to be a Fedora package for SpliX, which is why I am building from source. This is a link to a bugrep with identical error message when building a (different) package on Fedora: http://www.spinics.net/lists/linux-btrace/msg00501.html - maybe the solution here is relevant?

    Any ideas anyone?

    Thanks,
    Andrew

     
  • After a bit of hunting around I managed to fix this. It is due a change in the DSO linking semantics of the gcc compiler, introduced in Fedora 13 (see background info here http://fedoraproject.org/wiki/UnderstandingDSOLinkChange). I understand the principle but am not a C/C++ programmer so cannot claim to understand every detail. However changing line 32 in module.mk from

    rastertoqpdl_LDFLAGS    := `cups-config --ldflags` -L/opt/local/lib
    

    to

    rastertoqpdl_LDFLAGS    := `cups-config --ldflags` -L/opt/local/lib [b]-lpthread[/b]
    

    fixed the linking dependency problem and make runs OK now.

    Notwithstanding this, I still can't get the CLX-3175 to print properly - there isn't a CLX-3175 PDD file and I get an error if I use CLP-300, which seems to be the nearest available.