Work at SourceForge, help us to make it a better place! We have an immediate need for a Support Technician in our San Francisco or Denver office.

Close

Why is a 32-bit build occuring w/make install

Help
2010-12-16
2013-11-26
  • Steven Peckins
    Steven Peckins
    2010-12-16

    I'm still having issues building VirtualGL from source on amd64 Linux 2.6.36, gcc x86_64-pc-linux-gnu-4.5.1.

    I'm keeping default install paths and configuring libjpeg-turbo -with-pic, which seems to solve an issue with VirtualGL's compile complaints about "-fPIC."  Up to "make install" everything seems to go smoothly.  However, "make install" appears to recompile everything with "-m32."  Why?

    Output here: Configure, compile, and install libjpeg-turbo
    Output here: Compile VirtualGL
    Output here: Install VirtualGL

    It's also looking for 32-bit libjpeg-turbo ("g++: /opt/libjpeg-turbo/lib32/libjpeg.a: No such file or directory").  (The error at the end of the "Install VirtualGL" is because I'm not running the install as root.)

     
  • DRC
    DRC
    2010-12-16

    I realize that this is a bit different from the way most other OSS projects work, but it is the way VirtualGL has worked since the beginning.  The 64-bit version is always accompanied by a 32-bit faker library and a 32-bit test program.  This is to ensure that 32-bit applications can be used with VirtualGL on 64-bit systems.  The 32-bit library is considered part of the 64-bit install.  This is to ensure that there are no conflicts.  Otherwise, how would you install both 32-bit and 64-bit versions of VirtualGL in the same directory without some of the files overwriting each other?  At some point, I would like to overhaul the build system to use CMake (seeking funding for this project), and it would make sense to revisit the way the 64-bit version is built/installed at that point.  Until then, what I can do is add an undocumented "install64" line to the Makefile that installs just the 64-bit components.

    As far as libjpeg-turbo, that is a known issue with building the 1.0.x versions from source.  It has been fixed in the SVN trunk (which will soon be 1.1 beta), or you can use one of the libjpeg-turbo binary packages, which also contain the lib32 and lib64 sym links.  This is again a mechanism to avoid conflicts between 32-bit and 64-bit versions that are installed under the same directory.

     
  • Steven Peckins
    Steven Peckins
    2010-12-16

    Even when building libjpeg-turbo from the SVN trunk, It's not just a matter of symlinks; I still need to explicitly build and install the 32-bit libs for VirtualGL to correctly build against libjpeg-turbo, right?  I do this (in this case using SVN sources):

    $ autoreconf -fiv
    $ ./configure -host i686-pc-linux-gnu CFLAGS='-O3 -m32' CXXFLAGS='-O3 -m32' LDFLAGS=-m32
    $ make
    $ sudo make install libdir=/opt/libjpeg-turbo/lib32
    $ make clean
    $ ./configure -with-pic
    $ make
    $ sudo make install

    …then VirtualGL will build without errors.

    Okay, I think I've got it now; it just seemed odd that there was essentially a full build in the make install target.  The only other question I have is why is "-with-pic" required for building libjpeg-turbo on amd64?  Or if it is, why isn't it either automatic or documented?

    (I don't typically get much fancier than ./configure && make, so I apologize if I am a bit slow with this stuff.)

     
  • DRC
    DRC
    2010-12-17

    PIC code is required when building a shared library, which is why libjpeg-turbo has to be built with -with-pic in order to link it into VirtualGL (VirtualGL is a shared library.)

    Really, all of this is taken care of if you use the libjpeg-turbo distribution packages instead of trying to build it yourself from source.

     
  • DRC
    DRC
    2011-07-24

    Just FYI- the new CMake-based build system in CVS HEAD now addresses 32-bit and 64-bit as separate builds.