latest Pixie 64bit amd deb by Cedric PAILLE

Help
2009-07-06
2013-04-25
  • eric r drayer

    eric r drayer - 2009-07-06

    I am using Ubuntu 9.04.
    I have the repositories and the key from Cedric PAILLE source forge site.
    I downloaded and ran using Gdebi.
    Gdebi says that there is an unresolvable dependency libpng12.
    I checked synaptic and I have these installed: libpng12-0 and libpng12-dev.

     
    • eric r drayer

      eric r drayer - 2009-07-06

      I just tried to use the dev deb and got this error message from Gdebi.
      Error: Dependency is not satisfiable: libpng12

       
    • stfree

      stfree - 2009-08-30

      hi Cedric, same thing for me.
      i have tried  to compile  on amd64,  seems working  alone , but with RIBMOSAIC exporter i am not able to render a simple scene (segfault) (due  perhaps specific shader of RIBMOSAIC? sdrc compiler?)
      As , i am not a programmer ,  i prefer to use this "certified" package  
      do you have  a feedback on ths error ?

       
    • Anonymous - 2009-08-30

      Checkout this post if using Pixie with CVS MOSAIC ;)
      http://sourceforge.net/forum/forum.php?thread_id=3312195&forum_id=200366

       
    • stfree

      stfree - 2009-08-31

      About the  forwarding post , i note :
      - the first  patch isn't included in SVN ( i have made the updating local src) OK, the second is 1208 Ok
      the 3 other points aren't clear for me ...  where are the changes ? any patch included  or file name ?
      i have rebuilt Pixie with above  , same thing ...

      to clarify  my problem :
      system Debian  5.02,
      kernel2.6.29-2-amd64 (#1 SMP Sun May 17 17:15:47 UTC 2009)
      gcc 4.4.1 (x86_64-linux-gnu)

      configuring Pixie 2.2.6 svn 1208, gives :
      @obama:~/dvp/Pixie$ csh makeunix
      libtoolize: putting auxiliary files in `.'.
      libtoolize: copying file `./ltmain.sh'
      libtoolize: Consider adding `AC_CONFIG_MACRO_DIR([m4])' to configure.in and
      libtoolize: rerunning libtoolize, to keep the correct libtool macros in-tree.
      libtoolize: Consider adding `-I m4' to ACLOCAL_AMFLAGS in Makefile.am.
      sl.y: conflits: 1 décalage/réduction
      -> comment : may be a problem . ?

      alaw@obama:~/dvp/Pixie$ ./configure
      checking for a BSD-compatible install... /usr/bin/install -c
      checking whether build environment is sane... yes
      checking for a thread-safe mkdir -p... /bin/mkdir -p
      checking for gawk... no
      checking for mawk... mawk
      checking whether make sets $(MAKE)... yes
      checking for gcc... gcc
      checking for C compiler default output file name... a.out
      checking whether the C compiler works... yes
      checking whether we are cross compiling... no
      checking for suffix of executables...
      checking for suffix of object files... o
      checking whether we are using the GNU C compiler... yes
      checking whether gcc accepts -g... yes
      checking for gcc option to accept ISO C89... none needed
      checking for style of include used by make... GNU
      checking dependency style of gcc... gcc3
      checking how to run the C preprocessor... gcc -E
      checking for g++... g++
      checking whether we are using the GNU C++ compiler... yes
      checking whether g++ accepts -g... yes
      checking dependency style of g++... gcc3
      checking build system type... x86_64-unknown-linux-gnu
      checking host system type... x86_64-unknown-linux-gnu
      checking for a sed that does not truncate output... /bin/sed
      checking for grep that handles long lines and -e... /bin/grep
      checking for egrep... /bin/grep -E
      checking for fgrep... /bin/grep -F
      checking for ld used by gcc... /usr/bin/ld
      checking if the linker (/usr/bin/ld) is GNU ld... yes
      checking for BSD- or MS-compatible name lister (nm)... /usr/bin/nm -B
      checking the name lister (/usr/bin/nm -B) interface... BSD nm
      checking whether ln -s works... yes
      checking the maximum length of command line arguments... 1572864
      checking whether the shell understands some XSI constructs... yes
      checking whether the shell understands "+="... yes
      checking for /usr/bin/ld option to reload object files... -r
      checking for objdump... objdump
      checking how to recognize dependent libraries... pass_all
      checking for ar... ar
      checking for strip... strip
      checking for ranlib... ranlib
      checking command to parse /usr/bin/nm -B output from gcc object... ok
      checking for ANSI C header files... yes
      checking for sys/types.h... yes
      checking for sys/stat.h... yes
      checking for stdlib.h... yes
      checking for string.h... yes
      checking for memory.h... yes
      checking for strings.h... yes
      checking for inttypes.h... yes
      checking for stdint.h... yes
      checking for unistd.h... yes
      checking for dlfcn.h... yes
      checking whether we are using the GNU C++ compiler... (cached) yes
      checking whether g++ accepts -g... (cached) yes
      checking dependency style of g++... (cached) gcc3
      checking how to run the C++ preprocessor... g++ -E
      checking for objdir... .libs
      checking if gcc supports -fno-rtti -fno-exceptions... no
      checking for gcc option to produce PIC... -fPIC -DPIC
      checking if gcc PIC flag -fPIC -DPIC works... yes
      checking if gcc static flag -static works... yes
      checking if gcc supports -c -o file.o... yes
      checking if gcc supports -c -o file.o... (cached) yes
      checking whether the gcc linker (/usr/bin/ld -m elf_x86_64) supports shared libraries... yes
      checking whether -lc should be explicitly linked in... no
      checking dynamic linker characteristics... GNU/Linux ld.so
      checking how to hardcode library paths into programs... immediate
      checking whether stripping libraries is possible... yes
      checking if libtool supports shared libraries... yes
      checking whether to build shared libraries... yes
      checking whether to build static libraries... no
      checking for ld used by g++... /usr/bin/ld -m elf_x86_64
      checking if the linker (/usr/bin/ld -m elf_x86_64) is GNU ld... yes
      checking whether the g++ linker (/usr/bin/ld -m elf_x86_64) supports shared libraries... yes
      checking for g++ option to produce PIC... -fPIC -DPIC
      checking if g++ PIC flag -fPIC -DPIC works... yes
      checking if g++ static flag -static works... yes
      checking if g++ supports -c -o file.o... yes
      checking if g++ supports -c -o file.o... (cached) yes
      checking whether the g++ linker (/usr/bin/ld -m elf_x86_64) supports shared libraries... yes
      checking dynamic linker characteristics... GNU/Linux ld.so
      checking how to hardcode library paths into programs... immediate
      checking whether make sets $(MAKE)... (cached) yes
      checking for dlopen in -ldl... yes
      checking for sin in -lm... yes
      checking for pthread_create in -lpthread... yes
      checking for acosf in -lm... yes
      checking for asinf in -lm... yes
      checking for atan2f in -lm... yes
      checking for atanf in -lm... yes
      checking for cosf in -lm... yes
      checking for expf in -lm... yes
      checking for fabsf in -lm... yes
      checking for floorf in -lm... yes
      checking for fmodf in -lm... yes
      checking for hypotf in -lm... yes
      checking for logf in -lm... yes
      checking for powf in -lm... yes
      checking for sinf in -lm... yes
      checking for sqrtf in -lm... yes
      checking for tanf in -lm... yes
      checking for X... libraries , headers
      checking for gethostbyname... yes
      checking for connect... yes
      checking for remove... yes
      checking for shmat... yes
      checking for IceConnectionNumber in -lICE... yes
      checking for XOpenDisplay in -lX11... yes
      checking for XShmAttach in -lXext... yes
      checking for fltk-config... /usr/bin/fltk-config
      checking for FLTK with GL support... yes
      checking tiffio.h usability... yes
      checking tiffio.h presence... yes
      checking for tiffio.h... yes
      checking for TIFFOpen in -ltiff... yes
      checking png.h usability... yes
      checking png.h presence... yes
      checking for png.h... yes
      checking for png_create_write_struct in -lpng... yes
      checking for OpenEXR... yes
      checking for gzopen in -lz... yes
      checking for ANSI C header files... (cached) yes
      checking fcntl.h usability... yes
      checking fcntl.h presence... yes
      checking for fcntl.h... yes
      checking limits.h usability... yes
      checking limits.h presence... yes
      checking for limits.h... yes
      checking malloc.h usability... yes
      checking malloc.h presence... yes
      checking for malloc.h... yes
      checking sys/time.h usability... yes
      checking sys/time.h presence... yes
      checking for sys/time.h... yes
      checking for unistd.h... (cached) yes
      checking for an ANSI C-conforming const... yes
      checking for inline... inline
      checking for size_t... yes
      checking whether time.h and sys/time.h may both be included... yes
      checking for working alloca.h... yes
      checking for alloca... yes
      checking for vprintf... yes
      checking for _doprnt... no
      checking for gethostname... yes
      checking for gettimeofday... yes
      checking for mkdir... yes
      checking for rmdir... yes
      checking for socket... yes
      checking for strdup... yes
      checking for strstr... yes
      checking for strtod... yes
      checking for strtol... yes
      checking for random... yes
      checking for flex... /usr/bin/flex
      checking for bison... /usr/bin/bison
      checking for Mac OS X Carbon support... no
      configure: creating ./config.status
      config.status: creating Makefile
      config.status: creating doc/Makefile
      config.status: creating src/Makefile
      config.status: creating src/common/Makefile
      config.status: creating src/file/Makefile
      config.status: creating src/framebuffer/Makefile
      config.status: creating src/openexr/Makefile
      config.status: creating src/gui/Makefile
      config.status: creating src/precomp/Makefile
      config.status: creating src/rgbe/Makefile
      config.status: creating src/sdr/Makefile
      config.status: creating src/sdrc/Makefile
      config.status: creating src/ri/Makefile
      config.status: creating src/rndr/Makefile
      config.status: creating src/texmake/Makefile
      config.status: creating src/sdrinfo/Makefile
      config.status: creating src/show/Makefile
      config.status: creating config.h
      config.status: executing depfiles commands
      config.status: executing libtool commands
      ------------------------------------------------
      Installation info:
           PIXIEHOME:  /opt/pixie
      Documentation:  /opt/pixie/doc
             Shaders:  /opt/pixie/shaders
                RIBs:  /opt/pixie/ribs
            Textures:  /opt/pixie/textures
            Displays:  /opt/pixie/displays
         Procedurals:  /opt/pixie/procedurals
             Modules:  /opt/pixie/modules
      ------------------------------------------------
      To build Pixie:
      >make
      >make install
                    Terminus Est

      --> make and make install give  no warning no error

      Using :
      -Blender 2.49a + Python 2.6.2 
      -Mosaic 0.43 cvs 1.56
      scene is from template,+ a plane + material, + a lamp, render .... segfault
      trying :
      -materials setup displacement shader to NONE , segfault
      - +dice binary set 1 render OK
      - add materials setup displacement shader to ds_MOSAICdisplace + dice = 1 , segfault
      - materials setup  plastic2 + dice = DEFAULT or 1, rendering  OK
      - + ds_MOSAICdisplace shader , rendering OK

      If i use the   sample  scene  like sss.rib of suzanne  OK

      on winxp32 i haven't this problem, only a remark,  i have used the 2.2.5 sdrc.exe due problem of the availability of the new download  2.2.6 win.exe .(dll problem)

      it seems more a MOSAIC than  Pixie, i need your  expert comment ...

       
    • Anonymous - 2009-09-01

      Sorry, I mentioned that post as it has know problems between SVN Pixie and CVS MOSAIC, I was assuming your problems may be connected. It seems however the most critical problem has been patched in Pixie's trunk so is no long necessary (http://sourceforge.net/tracker/?func=detail&aid=2722418&group_id=59462&atid=491094). The other issues are not critical so would not cause your problem.

      As reference I am developing MOSAIC under a similar environment running 32bit Debian testing compiling latest SVN Pixie with the following patches:

      http://sourceforge.net/tracker/?func=detail&aid=2811709&group_id=59462&atid=491094
      This one allows MOSAIC's surface and displace shader to blend up to 10 textures like Blender materials.

      http://sourceforge.net/tracker/?func=detail&aid=2802398&group_id=59462&atid=491094
      This one fixes add substring match() which MOSAIC uses to know when to load a reflection map as texture or cube map (planar or cube mapping).

      Not sure what else to say without looking at a .blend to see whats wrong, I'm currently testing MOSAIC and its shaders against 3Delight, Air, PRMan, SVN Pixie and git Aqsis under 32bit Linux and WindowsXP. To date there are a number of small bugs that need to be resolved in Pixie and Aqsis but none of them critical errors.

      Eric Back (WHiTeRaBBiT)

       
    • stfree

      stfree - 2009-09-01

      Eric, I made the changes requested, even result. I would have wished to be able to install the software under Debian to be sure of  64bits Pixie  installation, Cédric,  if you can answer,(libpng)  thank you in advance.
      In fact I understand complexity well to test a stacking of software, api blender + mosaic + python + pixie + c++ + system…. . I suggest to test according to the following procedure:
      the version 32bits of the software chain runs on winxp and Debian, i join the file test .blend and the files exported by Mosaic in order to test in 32bits.
      the download link
      http://www.easy-share.com/1907585040/stpixie.tar.gz

      1) if nok, to compare export 32bits starting from the file blend and 64bits (joined), to search the differences.
      1a) if difference => to analyze why?
      1b) if no difference ==> 1a) in more complicated
      2) if ok, export 64bits is running in 32bits, the problem is located more towards compilation of Pixie in versiont 64bits, obviously not implicitly a defect of Pixie,  but one of chain,  software or librairy that it used or compiled  on my system ....
      Sorry for the delay of the answer,  but i am busy in this moment.

       
    • Anonymous - 2009-09-02

      Thanks for the test case, unfortunately I can see nothing wrong with the blend setup.
      I've tested both the supplied RIB and blend and have had no problems. I also tried the scenarios you mentioned above, changing the displacement shader, surface shader and trying various options (such as dice) all with no problems. This was tested in 32bit Linux and WinXP both compiled from source with mentioned patches.

      At this point I can only assume its your build or your build environment :(
      The only thing that comes to mind is to try different compiler options to see if anything helps. For myself I run a Intel Core2 Quad with the following GCC options -march=core2 -mfpmath=sse. I will get random segfaults without these options, but I've never compiled Pixie for 64bit so it may be very different.

      Anyway I'm sure someone else here has more qualified suggestions then myself (I'm mostly into Python not C). Sorry.

       
    • stfree

      stfree - 2009-09-05

      Hello everyone
      while trying to progress I made the following test in 64bits, to make a preview of surfaces shaders, some are not returned (obviously ss_MOSAICsurface) but also a simple surface shader like filament.sl
      and gdb gives

      (gdb) run
      Starting program: /opt/pixie/bin/rndr ShaderPreview.rib
      [Thread debugging using libthread_db enabled]
      [New Thread 0x7ffff5185910 (LWP 13649)]
      [New Thread 0x7ffff3a34910 (LWP 13650)]
      [New Thread 0x7ffff3233910 (LWP 13651)]
      [New Thread 0x7ffff2a32910 (LWP 13652)]
      [New Thread 0x7ffff2231910 (LWP 13653)]

      Program received signal SIGSEGV, Segmentation fault.
      [Switching to Thread 0x7ffff3233910 (LWP 13651)]
      0x00007ffff6610e50 in strcmp () from /lib/libc.so.6
      (gdb) bt
      #0  0x00007ffff6610e50 in strcmp () from /lib/libc.so.6
      #1  0x00007ffff7756615 in CShadingContext::execute (
          this=<value optimized out>, cInstance=<value optimized out>,
          locals=<value optimized out>) at scriptOpcodes.h:345
      #2  0x00007ffff78329c0 in CShadingContext::shade (this=<value optimized out>,
          object=<value optimized out>, uVertices=<value optimized out>,
          vVertices=<value optimized out>, dim=<value optimized out>,
          usedParameters=3999156339, displaceOnly=0) at shading.cpp:1079
      #3  0x00007ffff7813073 in CReyes::shadeGrid (this=0x6972e0,
          grid=0x7fffe40821e0, Ponly=0) at reyes.cpp:1045
      #4  0x00007ffff784c2b7 in CStochastic::drawQuadGridZminUnshaded (
          this=0x6972e0, grid=<value optimized out>) at stochasticQuad.h:617
      #5  0x00007ffff7811adb in CReyes::render (this=0x6972e0) at reyes.cpp:373
      #6  0x00007ffff78125a4 in CReyes::renderingLoop (this=0x6972e0)
          at reyes.cpp:308
      #7  0x00007ffff77e9998 in rendererDispatchThread (w=<value optimized out>)
          at renderer.cpp:1105
      #8  0x00007ffff729f73a in start_thread () from /lib/libpthread.so.0
      #9  0x00007ffff666343d in clone () from /lib/libc.so.6
      #10 0x0000000000000000 in ?? ()
      (gdb)

       
    • stfree

      stfree - 2009-09-06

      in fact my comment above has an error, the shader MOSAICsurface is called in the preview.
      Why does the preview function for some shaders and not for others? (conditions identical of scene)
      I noticed another topic with segfault:

      http://sourceforge.net/forum/forum.php?thread_id=2955003&forum_id=200367

      I note the line which call strcmp (I think)
      scriptOpcodes.h: 352 DEFOPCODE (Sneql2, “sneql”

      and in my case:
      scriptOpcodes.h: 345 DEFOPCODE (Seql2, “seql”

      in fact I modified the MOSAIC shader to remove part of the code not used as occlusion
      that shifts the problem on breakpoints  passed, in a normal case 72 in the other 92 calls
      my knowledge in gdb is weak, how to trace:

      Breakpoint 1, CShadingContext:: carry out (this=0x65da20, cInstance=0x697590, locals=0x7ffff380f010)
          At scriptOpcodes.h: 352
      352 DEFOPCODE (Sneql2, “sneql”, 3, OPERANDS3EXPR_PRE (float *, const char **, const char **), SNEQLEXPR, OPERANDS3EXPR_UPDATE (1,1,1), NULL_EXPR, 0)
      (gdb) n
      Program received signal SIGSEGV, Segmentation fault.
      0x00007ffff64f7e50 in strcmp () from /lib/libc.so.

       
    • stfree

      stfree - 2009-09-11

      hello,
      can be a bug, using  valgrind :
      ==24128== Invalid read of size 1
      ==24128== At 0x4C24371: strcmp (mc_replace_strmem.c: 337)
      ==24128== by 0x4EB03BE: CShadingContext:: carry out (CProgrammableShaderInstance*, float **) (scriptOpcodes.h: 343) ==24128== by 0x4FE268E: CProgrammableShaderInstance:: carry out (CShadingContext*, float **) (shader.cpp: 606) ==24128== by 0x4FE9F8E: CShadingContext:: shade (CSurface*, int, int, EShadingDim, unsigned int, int) (shading.cpp: 1079) ==24128== by 0x4FBF966: CReyes:: shadeGrid (CReyes:: CRasterGrid*, int) (reyes.cpp: 1045)
      ==24128== by 0x50034E6: CStochastic:: drawQuadGridZminUnshaded (CReyes:: CRasterGrid*) (stochasticQuad.h: 597) ==24128== by 0x4FF6D31: CStochastic:: rasterDrawPrimitives (CReyes:: CRasterGrid*) (stochasticPrimitives.h: 31) ==24128== by 0x4FBD0CE: CReyes:: render () (reyes.cpp: 373)
      ==24128== by 0x4FBCE3F: CReyes:: renderingLoop () (reyes.cpp: 308)
      ==24128== by 0x4F97D09: rendererDispatchThread (void*) (renderer.cpp: 1105)
      ==24128== by 0x586B739: start_thread (in /lib/libpthread-2.10.1.so)
      ==24128== by 0x64FA43C: clones (in /lib/libc-2.10.1.so)
      ==24128== Address 0x41480000089fef38 is not stack' D, malloc' D gold (recently) free' D

      thus when I compare the rendertype, I have a nophysical address of the 0x41800000…
      there is a problem of assignment of string, I modified the code
      according to in scripOpcodes.h: 744:
      - DEFOPCODE (Movess, “movess”, 2, OPERANDS2EXPR_PRE (float *, const float *), SUNARYEXPR, OPERANDS2EXPR_UPDATE (1.1), NULL_EXPR, 0) +DEFOPCODE (Movess, “movess”, 2, OPERANDS2EXPR_PRE (tank **, tank **), SUNARYEXPR, OPERANDS2EXPR_UPDATE (1.1), NULL_EXPR, 0)

      didn't I have a problem any more… that think about it?

       
    • stfree

      stfree - 2009-09-11

      comment above, a small problem of translation, sorry :

      in scriptOpcodes.h: 744:
      - DEFOPCODE (Movess, “movess”, 2, OPERANDS2EXPR_PRE (float *, const float *), SUNARYEXPR, OPERANDS2EXPR_UPDATE (1.1), NULL_EXPR, 0)
      +DEFOPCODE (Movess, “movess”, 2, OPERANDS2EXPR_PRE (char **, char **), SUNARYEXPR, OPERANDS2EXPR_UPDATE (1.1), NULL_EXPR, 0)

       

Log in to post a comment.

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:





No, thanks