On Monday 09 July 2007 14:34, Alexander Neundorf wrote:
> On Monday 09 July 2007 08:10, Mathias Froehlich wrote:
> > Hi,
> >
> > I need to do no default binary type builds with a cmake based build
> > system (OpenSceneGraph's cmake build system).
> > With non default binary type, I am talking about 64 bit builds on hp-ux
> > or sparc solaris for example.
> > On hp-ux I have 64 bit libs in .../lib/pa20_64 or on sparc solaris they
> > are located in .../lib/sparcv9 instead of the usual .../lib directory.
> >
> > The first problem that bites me is the FindOpenGL.cmake module.
> > On hp-ux it will find the /opt/graphics/lib/libGL.sl hppa1.1 32 bit
> > library (note that the 64 bit hppa2.0 library is available
> > in /opt/graphics/lib/pa20_64/libGL.sl). My object files are compiled with
> > CMAKE_CFLAGS='+DA2.0 ...' which will tell the compiler that it should
> > build hppa2.0 64 bit objects.
> >
> > At link time the cmake based gnu makefiles will try to glue the 64 bit
> > objects to the 32 bit libGL. Obviously this will not work.
> >
> > Now my question:
> > How can I make cmake look into the lib/pa20_64 or lib/sparcv9 directory
> > instead of the plain lib directory?
>
> So the problem is that it picks up not the libraries you want, because they
> are in a special directory ? Everything else (include dirs etc.) is correct
> ?
>
> You could set the CMAKE_LIBRARY_PATH cmake/environment variable to point
> the lib/pa20_64 and lib/sparcv9 directories to get it working.
Ok, thanks, that will probably solve my short term problem.
But wouldn't it be better if cmake knows about such path extensions?
It already knows about the change from lib to lib64 for EMT64 binaries on
linux.
Wouldn't it be better to generalize that abi dependent library directory name?
gcc for example knows that multilib direcectory that is relative to the
library directory. For
EMT64 linux: <libdir>/../lib64
64 bit sparc: <libdir>/sparcv9
hp-ux pa risc 64 bit: <libdir>/pa20_64
hp-ux ia64 bit: <libdir>/hpux64
irix 64 bit: <libdir>/../lib64
....
Wouldn't it make sense to generalize the hard coded 64 bit linux library
search path to something configurable.
Say we invent a new CMAKE_MULTILIB_PATH variable that can be set.
For EMT64 linux this would replace the hardcoded c++ code and would read:
CMAKE_MULTILIB_PATH=../lib64:.
For that pa20_64 hp-ux stuff this would then read:
CMAKE_MULTILIB_PATH=pa20_64
....
Any chance to get something like that in cmake?
Greetings
Mathais
--
Dr. Mathias Fröhlich, science + computing ag, Software Solutions
Hagellocher Weg 71-75, D-72070 Tuebingen, Germany
Phone: +49 7071 9457-268, Fax: +49 7071 9457-511
--
Vorstand/Board of Management:
Dr. Bernd Finkbeiner, Dr. Florian Geyer,
Dr. Roland Niemeier, Dr. Arno Steitz, Dr. Ingrid Zech
Vorsitzender des Aufsichtsrats/
Chairman of the Supervisory Board:
Prof. Dr. Hanns Ruder
Sitz/Registered Office: Tuebingen
Registergericht/Registration Court: Stuttgart
Registernummer/Commercial Register No.: HRB 382196
_______________________________________________
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
