Dev : OS X libtiff path

2007-03-16
2013-04-25
  • Nicholas Yue
    Nicholas Yue
    2007-03-16

    Hi,

      I am attempting to compile my own version of pixie which does not use Fink's tiff library. I have to fit my deployment into a DarwinPort environment.

      During configure, I provided the path to my copy of libtiff.

      All configuration and compilation was fine.

      When I ran rndr, the file display driver ask about /sw/lib/libtiff.3.dylib. Why?

      Should I compile rndr as a static binary so there is no dependency on external libraries?

    Regards

     
    • Nicholas Yue
      Nicholas Yue
      2007-03-17

      I have got it sorted out. It's the display driver.

      After configure and make install (for Pixie from trunk), the display drivers are not copied (problem with ./configure?) or insalled properly.

      I hand copied the framebuffer.so display driver to the newly created display directory and all is good.

      Now I have a DarwinPort version.

      Would still be good to be able to configure the package to build without dependency so that we don't need to force user to use unstable branch of libtiff and such.

      Regards

       
      • Okan Arikan
        Okan Arikan
        2007-03-17

           Hi Nicholas,

           This is interesting. I just verified that on Linux and OSX(Intel), the files get copied as expected. Can you give some more details on the problem?

           Okan

         
    • Nicholas Yue
      Nicholas Yue
      2007-03-18

      Yup, you are right.

      I just verified that the copy was done to $PIXIEHOME/lib/Pixie/displays

      I do have a older installation of Pixie which puts display drivers in $PIXIEHOME/displays

      There might have been structural changes in how Pixie references stuff.

      I am doing my build from the Pixie-2.0.1 tag from svn

      From the documentation, it mentions that display should be a directory in $PIXIEHOME.

      For now, I am creating a symlink to get things working.

      I have also check that my environement variable for PIXIEHOME is set correctly.

      Let me know if you want me to try additional test with my environment.

      Regards

       
      • Okan Arikan
        Okan Arikan
        2007-03-18

           Hi Nicholas,

           I'm a little confused now. Where do you think is the problem?

           Pixie directory structure is not changed. $PIXIEHOME/displays must contain the display drivers.

           One thing that may create confusion is the --enable-selfcontained flag.

           If you run ./configure --prefix=/tmp/Pixie --enable-selfcontained

           then, after make install, /tmp/Pixie will containe the self contained directory tree and PIXIEHOME must be set to /tmp/Pixie.

           if you do not specify this flag, then the directory structure is separated and everything goes to (usually) /usr/local. For example, the Pixie libs will go to /usr/local/lib and Pixie headers will go to /usr/local/include.

           Making Pixie robust is very important. Please let me know of the problems you have getting it to compile/install.

          Okan

         
    • Nicholas Yue
      Nicholas Yue
      2007-03-18

      Yup, confirmed that --enable-selfcontained is very important.

      I think that should be the default behaviour but there might be a reason for enabling it via a flag.

      All is good now, I render straight out of a install, no more copying/linking.

      Regards

       
      • George Harker
        George Harker
        2007-03-18

        Hi Nicholas,

        Was about to reply also, but Okan got there first.

        The reason --enable-selfcontained is not default is because this matches the default for most unix-style configure install scripts.

        If you just ran ./configure, it would install to /usr/local and would integrate with the normal rules for installing there.

        But for OSX if you want it installed in /Applications/Graphics/Pixie, then selfcontained is the best option.

        Cheers

        George