<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<META NAME="Generator" CONTENT="MS Exchange Server version 6.5.7652.24">
<TITLE>RE: [CMake] Nonstandard architectures.</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/plain format -->
<P><FONT SIZE=2>If you want to check without actually compiling. There is the file command which can tell you about a shared library or any other file on your filesystem.<BR>
<BR>
~> file /opt/firefox/libfreebl3.so<BR>
/opt/firefox/libfreebl3.so: ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), stripped<BR>
~> file /usr/lib64/nss/libfreebl3.so<BR>
/usr/lib64/nss/libfreebl3.so: symbolic link to `libfreebl3.so.11'<BR>
~> file /usr/lib64/nss/libfreebl3.so.11<BR>
/usr/lib64/nss/libfreebl3.so.11: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), stripped<BR>
<BR>
Barring that, I've seen people use chroot jails to contain their 32 bit compile environments.<BR>
<BR>
Juan<BR>
<BR>
-----Original Message-----<BR>
From: cmake-bounces+juan.sanchez=amd.com@cmake.org on behalf of Mathias Froehlich<BR>
Sent: Thu 9/27/2007 4:12 AM<BR>
To: cmake@cmake.org<BR>
Subject: [CMake] Nonstandard architectures.<BR>
<BR>
<BR>
Hi,<BR>
<BR>
I have problems with nonstandard architectures.<BR>
<BR>
cmakes mechanism to see if some package is installed usually just looks if<BR>
some files are present. That is good as long as you just compile for the<BR>
standard architecture on a specific operating system.<BR>
<BR>
But if I build for some non default architecture (for example for 64 bit pa<BR>
risc instead of the 32 bit default one). Most configury checks will not find<BR>
the truth.<BR>
For example, In my amd64 linux system we have a /usr/local/lib/libglut.so. so<BR>
the FIND_PACKAGE(GLUT) will see: 'ah we have glut available!'. But when I<BR>
build for emt64, this is just wrong, because I do not have the<BR>
equivalent /usr/local/lib64/libglut.so installed ...<BR>
<BR>
Old autoconf used to check existence of libraries by compiling a small test<BR>
example with the configured compiler and link against that library in<BR>
question. In contrast to cmake that just looks for the existence of files.<BR>
This way one could be sure that this fits together.<BR>
This would be for sure one solution to that problem.<BR>
<BR>
An other one would be to use the 'correct' standard librarie paths for<BR>
different architectures. But that means that cmake will need to know more<BR>
about the ABI in use. Currently this is not required to know.<BR>
<BR>
What to do here?<BR>
<BR>
Greetings<BR>
<BR>
Mathias<BR>
<BR>
--<BR>
Dr. Mathias Fröhlich, science + computing ag, Software Solutions<BR>
Hagellocher Weg 71-75, D-72070 Tuebingen, Germany<BR>
Phone: +49 7071 9457-268, Fax: +49 7071 9457-511<BR>
--<BR>
Vorstand/Board of Management:<BR>
Dr. Bernd Finkbeiner, Dr. Florian Geyer,<BR>
Dr. Roland Niemeier, Dr. Arno Steitz, Dr. Ingrid Zech<BR>
Vorsitzender des Aufsichtsrats/<BR>
Chairman of the Supervisory Board:<BR>
Prof. Dr. Hanns Ruder<BR>
Sitz/Registered Office: Tuebingen<BR>
Registergericht/Registration Court: Stuttgart<BR>
Registernummer/Commercial Register No.: HRB 382196<BR>
<BR>
_______________________________________________<BR>
CMake mailing list<BR>
CMake@cmake.org<BR>
<A HREF="http://www.cmake.org/mailman/listinfo/cmake">http://www.cmake.org/mailman/listinfo/cmake</A><BR>
<BR>
<BR>
<BR>
</FONT>
</P>
</BODY>
</HTML>