RE: [CMake] Nonstandard architectures.
> -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On > Bill Hoffman wrote: > Mathias Froehlich wrote: > > Hi, > > That is way too croase and will even bring the wrong results. > > > It produces good results on linux x64 and itanium platforms. I have > tested and used > it on both. As understand, for this case saying "it works on linux" is not that meaningful as the problem is between different linux distributions; the distribution developers' choice of how to designate the location of 64 bit and 32 bit libraries differs. It may also differ depending upon the system builder's choices, I observe that one of our College system (SGI Atrix) has /lib only but it's got 64 bits object in there, even though it identifies itself as Suse. I seem to recall on our old Irix system (now defunct so I cannot check) that it had /lib and /lib32 ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Nonstandard architectures.
On Friday 28 September 2007 16:36:00 Mathias Froehlich wrote: > > Mathias Froehlich wrote: > > to time. I am not sure that FIND_LIBRARY should do a try_compile, but > > maybe it should > > Probably yes. > IMO, better test what you need rather than test something that is more or > less closely related but not the same than what you need. So it all depends on what you need. If you need FIND_LIBRARY to find compilable libaries ok, I don't, hence I would prefer something simpler and faster. On my projects I consider it a user error if the library is found by file location and doesn't work on compilation (plus I can try-compile if that is needed, currently CMake allows you to do both, making FIND_LIBRARY try-compile always would remove one of the options). -- Mihai RUSU Email: [EMAIL PROTECTED] "Linux is obsolete" -- AST ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Nonstandard architectures.
On Friday 28 September 2007 14:56, you wrote: > Mathias Froehlich wrote: > > Hi, > > > > On Thursday 27 September 2007 16:31, Bill Hoffman wrote: > >>> I think there's a way to tell CMake to either use lib or lib64, > >>> something like LIB_SUFFIX. > >> > >> CMake does a test for sizeof void* if it is 8 bytes then lib64 is > >> searched before lib in all FIND_* stuff. > > > > That is way too croase and will even bring the wrong results. > > It produces good results on linux x64 and itanium platforms. I have > tested and used > it on both. > There maybe issues with other platforms. > Right now the code does this: > > if(is64bit) >1. try this: cmSystemTools::ReplaceString(s, "lib/", "lib64/"); >2. try this: add 64 to the name of the path. I am not sure about that, since even on such platforms files in /usr/lib are still found. For example on IRIX I see with building openscenegraph that even with 'CC -64' producing mips4 64 bits abi object, cmake thinks that it can make use of /usr/lib/libInventor.so - a 32 bit default abi file, even if ther is no /usr/lib64/libInventor.* avaliable. And yes on irix the path conventions match the ones from linux. So there is a /usr/lib64. So cmake still tries to look in lib rather than just only in lib64. The build then fails because the 64 bit linker tries to link -lInventor and does not have one that matches the abi ... > I suppose the lib64 thing could be and the path extension could be > changed to be > variables that are set in the Platform files. Yep, and i think that it should be overwritable from outside. There are too many platforms with too different abis out there that you can in the best case do an educated default guess. > It also checks to see if > the above > paths exist before adding them to the search paths. However, finding a > library > without testing it with a try_compile will produce incorrect results > from time > to time. I am not sure that FIND_LIBRARY should do a try_compile, but > maybe it should Probably yes. IMO, better test what you need rather than test something that is more or less closely related but not the same than what you need. And in the final build stage you will need to link with a library. The test if there is a file just tells you that there is a file - not that you can link with that file. Greetings Mathias -- 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
Re: [CMake] Nonstandard architectures.
Mathias Froehlich wrote: Hi, On Thursday 27 September 2007 16:31, Bill Hoffman wrote: I think there's a way to tell CMake to either use lib or lib64, something like LIB_SUFFIX. CMake does a test for sizeof void* if it is 8 bytes then lib64 is searched before lib in all FIND_* stuff. That is way too croase and will even bring the wrong results. It produces good results on linux x64 and itanium platforms. I have tested and used it on both. There maybe issues with other platforms. Right now the code does this: if(is64bit) 1. try this: cmSystemTools::ReplaceString(s, "lib/", "lib64/"); 2. try this: add 64 to the name of the path. I suppose the lib64 thing could be and the path extension could be changed to be variables that are set in the Platform files. It also checks to see if the above paths exist before adding them to the search paths. However, finding a library without testing it with a try_compile will produce incorrect results from time to time. I am not sure that FIND_LIBRARY should do a try_compile, but maybe it should For win64, the compiler provides an environment for 64 bit building. On windows finding system libraries is not done as much, as there is no /usr/lib. -Bill ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Nonstandard architectures.
On 28.09.07 07:47:50, Mathias Froehlich wrote: > > Hi, > > On Thursday 27 September 2007 15:53, Andreas Pakulat wrote: > > Just to state the obvious: Thats backwards compared to what distro's > > have these days. */lib is always the native libs and then you have > > either lib64 or lib32 (at least AFAIK, don't have any 64-bit system) > No. > On a redhat or suse linux - probably that Linux distros with most > installations on this blue marble - 32 bit i386 libs are in 'lib' and emt64 > libs in 'lib64'. > Well debian does it 'right' from that point of view, but Hmm, ok. I thought otherwise, but I don't have anything except debian around :) > > > But cmake looks in */lib > > > directories where some x86 libs are present that are not present for the > > > x86-64 case. > > > The question here is even worse - which one is the native one?? lib or > > > lib64?? And which ones should cmake accept? > > > > I think there's a way to tell CMake to either use lib or lib64, > > something like LIB_SUFFIX. > I could not find such a thing. > Can you give me a more concrete hint? It seems I remembered wrong :( Its only used to set the install dir here.. Andreas -- Don't get to bragging. ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Nonstandard architectures.
Hi, On Thursday 27 September 2007 16:31, Bill Hoffman wrote: > > I think there's a way to tell CMake to either use lib or lib64, > > something like LIB_SUFFIX. > > CMake does a test for sizeof void* if it is 8 bytes then lib64 is > searched before lib in all FIND_* stuff. That is way too croase and will even bring the wrong results. - On sparc solaris 64 bit libs are in */lib/64/ or */lib/sparcv9/. Currently this is the only 64 bit abi on sparc. Don't currently know solaris amd64 ... - On hpux see the post with the different libc examples we have on the pa risc machine - note even different 32 bit abis. The itanium verison add some more abis. Even different 64 bit abis. All of them in some subdirs in lib ... Also still looking in the plain */lib/ path might test for the wrong libs. The original problem is basically that cmake believes to have some packages availabe because of having libraries for the abi resident in */lib/ that are not available for the abi we compile for. So picking up some files in */lib/ might be just wrong for some cases. To be curious: Does somebody have some experience with win64 in this area? What kind of problems will come up here? Greetings Mathias -- 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
Re: [CMake] Nonstandard architectures.
Hi, On Thursday 27 September 2007 15:53, Andreas Pakulat wrote: > Just to state the obvious: Thats backwards compared to what distro's > have these days. */lib is always the native libs and then you have > either lib64 or lib32 (at least AFAIK, don't have any 64-bit system) No. On a redhat or suse linux - probably that Linux distros with most installations on this blue marble - 32 bit i386 libs are in 'lib' and emt64 libs in 'lib64'. Well debian does it 'right' from that point of view, but > > But cmake looks in */lib > > directories where some x86 libs are present that are not present for the > > x86-64 case. > > The question here is even worse - which one is the native one?? lib or > > lib64?? And which ones should cmake accept? > > I think there's a way to tell CMake to either use lib or lib64, > something like LIB_SUFFIX. I could not find such a thing. Can you give me a more concrete hint? But yes, for most of the platforms (I believe AIX will still fall through), such a path suffix that can be globally configurable would help much. Ok, the problem with AIX: They have archive files that can even einclude object or shared object files for different abis. The linker cares for selecting the correct ones. At least we observed that with some libraries ... Strange, but the real existing world ... Greertings Mathias -- 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
Re: [CMake] Nonstandard architectures.
Andreas Pakulat wrote: But cmake looks in */lib directories where some x86 libs are present that are not present for the x86-64 case. The question here is even worse - which one is the native one?? lib or lib64?? And which ones should cmake accept? I think there's a way to tell CMake to either use lib or lib64, something like LIB_SUFFIX. CMake does a test for sizeof void* if it is 8 bytes then lib64 is searched before lib in all FIND_* stuff. -Bill ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Nonstandard architectures.
On 27.09.07 15:36:11, Mathias Froehlich wrote: > On Thursday 27 September 2007 11:33, Dizzy wrote: > > In your example, the native arch it's x86-64 or x86? And then you are > > compiling for a target x86 or x86-64? > The native arch is x86-64. And I compile for x86-64. The native archs libs > will be in */lib64 instead of the usual */lib paths. Just to state the obvious: Thats backwards compared to what distro's have these days. */lib is always the native libs and then you have either lib64 or lib32 (at least AFAIK, don't have any 64-bit system) > But cmake looks in */lib > directories where some x86 libs are present that are not present for the > x86-64 case. > The question here is even worse - which one is the native one?? lib or lib64?? > And which ones should cmake accept? I think there's a way to tell CMake to either use lib or lib64, something like LIB_SUFFIX. Andreas -- What happened last night can happen again. ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Nonstandard architectures.
Hi, On Thursday 27 September 2007 15:21, Sanchez, Juan wrote: > 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. > > ~> file /opt/firefox/libfreebl3.so > /opt/firefox/libfreebl3.so: ELF 32-bit LSB shared object, Intel 80386, > version 1 (SYSV), stripped ~> file /usr/lib64/nss/libfreebl3.so > /usr/lib64/nss/libfreebl3.so: symbolic link to `libfreebl3.so.11' > ~> file /usr/lib64/nss/libfreebl3.so.11 > /usr/lib64/nss/libfreebl3.so.11: ELF 64-bit LSB shared object, x86-64, > version 1 (SYSV), stripped Ok, but: On hpux for example: $ file /lib/pa*/libc.* /lib/libc.* /lib/pa11_32/libc.2:PA-RISC1.1 shared library -not stripped /lib/pa20_32/libc.2:PA-RISC2.0 shared library -not stripped /lib/pa20_64/libc.2:ELF-64 shared object file - PA-RISC 2.0 (LP64) /lib/pa20_64/libc.a:archive file /lib/pa20_64/libc.sl: ELF-64 shared object file - PA-RISC 2.0 (LP64) /lib/libc.0:PA-RISC1.1 shared library -not stripped /lib/libc.1:PA-RISC1.1 shared library -not stripped /lib/libc.2:PA-RISC2.0 shared library -not stripped /lib/libc.a:archive file -PA-RISC1.1 relocatable library /lib/libc.sl: PA-RISC2.0 shared library -not stripped Which one would you choose? Especially that: /lib/pa20_64/libc.a:archive file You need to recognise that it is an archive you need to unpack one of the files and do a file commmand on such an object. Or that one as seen on opensuse 10.2: $ file /usr/lib*/libc.* /usr/lib64/libc.a: current ar archive /usr/lib64/libc.so: ASCII C program text /usr/lib/libc.a:current ar archive /usr/lib/libc.so: ASCII C program text Ooops, C program text aka gnu ld linker script :) Or think of AIX and its way to pack different so versions of the same library into an archive file ... Greetings Mathias -- 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
Re: [CMake] Nonstandard architectures.
Hi, On Thursday 27 September 2007 11:33, Dizzy wrote: > Also generally, FIND_LIBRARY(), FIND_FILE() (which are generally used in > FindPackage scripts) are both configurable setting some variables for the > paths (see the cmake man page on them). So you can avoid that cmake will look into /lib and /usr/lib for example? What to do then with the OpenGL test for example? It adds its own knowledge about the standard paths where OpenGL is usually installed. But That paths only include the standard abi variants of those paths. I need to make sure that the ones with the correct abi are found. Sure I can do that with CMAKE_LIBRARY_PATH. But I also need to make sure that libs that are present in */lib paths are not found if they do not match the required abi. That is cmake should not just look into */lib paths. Or it must have a way to check if the abi will match. > In your example, the native arch it's x86-64 or x86? And then you are > compiling for a target x86 or x86-64? The native arch is x86-64. And I compile for x86-64. The native archs libs will be in */lib64 instead of the usual */lib paths. But cmake looks in */lib directories where some x86 libs are present that are not present for the x86-64 case. The question here is even worse - which one is the native one?? lib or lib64?? And which ones should cmake accept? > I would not like to have cmake do very strict checks such as autoconf by > default, because then we will get the same speed as with autoconf (which > was very slow) and you generally don't need those strict checks. I would > like to have it both, so you can do both fast checks (checking for > existence of files) and compile-test checks (checking if it actually > compiles) in a configurable way. So maybe there should be a new attribute > to FIND_PACKAGE() (as we have the REQUIRED attribute) say named "STRICT" > and have code in FindPackage modules that when STRICT is present there will > also be a test-compile check done (using CHECK_LIBRARY_EXISTS and such) on > the found library. Having that STRICT flag should not be a per target flag. It would help me if there is a switch to make that the global default. Better correctness then speed. CHECK_LIBRARY_EXISTS is a C implementaiton? May be you want to fiddle with the output of the file command? Well, you need to know what abis are available and compatible and which one is compiled with the configured compiler. Greetings Mathias -- 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
RE: [CMake] Nonstandard architectures.
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. ~> file /opt/firefox/libfreebl3.so /opt/firefox/libfreebl3.so: ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), stripped ~> file /usr/lib64/nss/libfreebl3.so /usr/lib64/nss/libfreebl3.so: symbolic link to `libfreebl3.so.11' ~> file /usr/lib64/nss/libfreebl3.so.11 /usr/lib64/nss/libfreebl3.so.11: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), stripped Barring that, I've seen people use chroot jails to contain their 32 bit compile environments. Juan -Original Message- From: [EMAIL PROTECTED] on behalf of Mathias Froehlich Sent: Thu 9/27/2007 4:12 AM To: cmake@cmake.org Subject: [CMake] Nonstandard architectures. Hi, I have problems with nonstandard architectures. cmakes mechanism to see if some package is installed usually just looks if some files are present. That is good as long as you just compile for the standard architecture on a specific operating system. But if I build for some non default architecture (for example for 64 bit pa risc instead of the 32 bit default one). Most configury checks will not find the truth. For example, In my amd64 linux system we have a /usr/local/lib/libglut.so. so the FIND_PACKAGE(GLUT) will see: 'ah we have glut available!'. But when I build for emt64, this is just wrong, because I do not have the equivalent /usr/local/lib64/libglut.so installed ... Old autoconf used to check existence of libraries by compiling a small test example with the configured compiler and link against that library in question. In contrast to cmake that just looks for the existence of files. This way one could be sure that this fits together. This would be for sure one solution to that problem. An other one would be to use the 'correct' standard librarie paths for different architectures. But that means that cmake will need to know more about the ABI in use. Currently this is not required to know. What to do here? Greetings Mathias -- 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 ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Nonstandard architectures.
On Thursday 27 September 2007 12:12:56 Mathias Froehlich wrote: > Hi, Hello > I have problems with nonstandard architectures. > > cmakes mechanism to see if some package is installed usually just looks if > some files are present. That is good as long as you just compile for the > standard architecture on a specific operating system. > > But if I build for some non default architecture (for example for 64 bit pa > risc instead of the 32 bit default one). Most configury checks will not > find the truth. > For example, In my amd64 linux system we have a /usr/local/lib/libglut.so. > so the FIND_PACKAGE(GLUT) will see: 'ah we have glut available!'. But when > I build for emt64, this is just wrong, because I do not have the > equivalent /usr/local/lib64/libglut.so installed ... FIND_PACKAGE(GLUT) will use FindGLUT.cmake as it's made and it does not have to fit every need, you can provide your own FindGLUT.cmake in a local project cmake modules directory to override the default one (I do that with ZLIB). Also generally, FIND_LIBRARY(), FIND_FILE() (which are generally used in FindPackage scripts) are both configurable setting some variables for the paths (see the cmake man page on them). > Old autoconf used to check existence of libraries by compiling a small test > example with the configured compiler and link against that library in > question. In contrast to cmake that just looks for the existence of files. Yes (but cmake has that too). > This way one could be sure that this fits together. > This would be for sure one solution to that problem. So then use such a check instead of FIND_LIBRARY() (that locates files only). CMake comes with many modules that can be used to test-compile, but there is one specifically for your case, namely CHECK_LIBRARY_EXISTS(). > An other one would be to use the 'correct' standard librarie paths for > different architectures. But that means that cmake will need to know more > about the ABI in use. Currently this is not required to know. In your example, the native arch it's x86-64 or x86? And then you are compiling for a target x86 or x86-64? I would not like to have cmake do very strict checks such as autoconf by default, because then we will get the same speed as with autoconf (which was very slow) and you generally don't need those strict checks. I would like to have it both, so you can do both fast checks (checking for existence of files) and compile-test checks (checking if it actually compiles) in a configurable way. So maybe there should be a new attribute to FIND_PACKAGE() (as we have the REQUIRED attribute) say named "STRICT" and have code in FindPackage modules that when STRICT is present there will also be a test-compile check done (using CHECK_LIBRARY_EXISTS and such) on the found library. -- Mihai RUSU Email: [EMAIL PROTECTED] "Linux is obsolete" -- AST ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
