Re: [CMake] Cross compile + shared libs problem
On Sat, Mar 29, 2008 at 12:25:45AM +0100, Alexander Neundorf wrote: On Tuesday 25 March 2008, you wrote: ... I validated the general approach this morning, should be ready by tomorrow. News ? Sorry, I couldn't quite save time to make a nice platform file. Would you accept the following Rtems.make so that at least CMAKE_SYSTEM_NAME == Rtems works? I'm sorting out some setup problems, so I've not managed to prepare a Rtems.make file that's able to generate executables (There are a few linking flags and objdump magic that seem to be standard in Rtems developemnt). It works for libs now though. Regards, Frederik # Not so useful template file for Rtems projects, see # http://cvs.savannah.nongnu.org/viewvc/*checkout*/tsp/make/Toolchain-rtems-i386.cmake?root=tsp # For an example of working CMAKE_TOOLCHAIN_FILE for Rtems SET_PROPERTY(GLOBAL PROPERTY TARGET_SUPPORTS_SHARED_LIBS FALSE) ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Cross compile + shared libs problem
On Tuesday 01 April 2008, you wrote: On Sat, Mar 29, 2008 at 12:25:45AM +0100, Alexander Neundorf wrote: On Tuesday 25 March 2008, you wrote: ... I validated the general approach this morning, should be ready by tomorrow. News ? Sorry, I couldn't quite save time to make a nice platform file. Would you accept the following Rtems.make so that at least CMAKE_SYSTEM_NAME == Rtems works? Hmm, no, that's a bit too little yet. If this is really enough to have apps and libs build for rtems, yes. If not, we can do that later. If you have questions, just ask :-) I'm sorting out some setup problems, so I've not managed to prepare a Rtems.make file that's able to generate executables (There are a few linking flags and objdump magic that seem to be standard in Rtems developemnt). What do you need to do with objdump ? Bye Alex ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Cross compile + shared libs problem
On Tue, Apr 01, 2008 at 10:12:20PM +0200, Alexander Neundorf wrote: On Tuesday 01 April 2008, you wrote: On Sat, Mar 29, 2008 at 12:25:45AM +0100, Alexander Neundorf wrote: On Tuesday 25 March 2008, you wrote: ... I validated the general approach this morning, should be ready by tomorrow. News ? Sorry, I couldn't quite save time to make a nice platform file. Would you accept the following Rtems.make so that at least CMAKE_SYSTEM_NAME == Rtems works? Hmm, no, that's a bit too little yet. If this is really enough to have apps and libs build for rtems, yes. If not, we can do that later. If you have questions, just ask :-) Well, I didn't figure out what should go to Platform, and what should go to Toolchain. In fact the target is processor + bsp [1]. Should we make a Toolchain per processor + bsp? [1] Board Support Package, for example for sparc: * ERC32 with FPU * SPARC Instruction Simulator (sis) * leon2 * leon3 I'm sorting out some setup problems, so I've not managed to prepare a Rtems.make file that's able to generate executables (There are a few linking flags and objdump magic that seem to be standard in Rtems developemnt). What do you need to do with objdump ? Err, objcopy, my bad. A first pass does a bunch of --remove-section=, and a second one does a -O binary with the resulting elf file. Then a bin2boot utility is used to build the final bootable .exe file. i386-rtems4.7-objcopy -O elf32-i386 --remove-section=.rodata --remove-section=.comment --remove-section=.note --strip-unneeded o-optimize/stub_server.elf o-optimize/stub_server.exe i386-rtems4.7-objcopy -O binary o-optimize/stub_server.elf o-optimize/stub_server.bin /opt/rtems/rtems4.7/i386-rtems4.7/pc386/build-tools/bin2boot -v o-optimize/stub_server.bt 0x00097E00 /opt/rtems/rtems4.7/i386-rtems4.7/pc386/lib/start16.bin 0x00097C00 0 o-optimize/stub_server.bin 0x0010 0 Plus, there are a few magic numbers there which use I need to figure out. Thanks, Frederik ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Cross compile + shared libs problem
On Wednesday 02 April 2008, you wrote: On Tue, Apr 01, 2008 at 10:12:20PM +0200, Alexander Neundorf wrote: On Tuesday 01 April 2008, you wrote: On Sat, Mar 29, 2008 at 12:25:45AM +0100, Alexander Neundorf wrote: On Tuesday 25 March 2008, you wrote: ... I validated the general approach this morning, should be ready by tomorrow. News ? Sorry, I couldn't quite save time to make a nice platform file. Would you accept the following Rtems.make so that at least CMAKE_SYSTEM_NAME == Rtems works? Hmm, no, that's a bit too little yet. If this is really enough to have apps and libs build for rtems, yes. If not, we can do that later. If you have questions, just ask :-) Well, I didn't figure out what should go to Platform, and what should go to Toolchain. In fact the target is processor + bsp [1]. Should we make a Toolchain per processor + bsp? [1] Board Support Package, for example for sparc: * ERC32 with FPU * SPARC Instruction Simulator (sis) * leon2 * leon3 You must have: Rtems.cmake You can have Rtems-GNU-C.cmake Rtems-GNU-CXX.cmake and for different boards you could consider setting CMAKE_SYSTEM_PROCESSOR, e.g. to leon3, then you could have additionally: Rtems-GNU-C-leon2.cmake Rtems-GNU-CXX-leon2.cmake These two files will be loaded before Rtems-GNU-C.cmake and Rtems-GNU-CXX.cmake, so you can adjust variables in Rtems-GNU-[C|CXX]-leon2.cmake which can then be used in Rtems-GNU-[C|CXX].cmake Does this help ? I'm sorting out some setup problems, so I've not managed to prepare a Rtems.make file that's able to generate executables (There are a few linking flags and objdump magic that seem to be standard in Rtems developemnt). What do you need to do with objdump ? Err, objcopy, my bad. A first pass does a bunch of --remove-section=, and a second one does a -O binary with the resulting elf file. Then a bin2boot utility is used to build the final bootable .exe file. i386-rtems4.7-objcopy -O elf32-i386 --remove-section=.rodata --remove-section=.comment --remove-section=.note --strip-unneeded o-optimize/stub_server.elf o-optimize/stub_server.exe i386-rtems4.7-objcopy -O binary o-optimize/stub_server.elf o-optimize/stub_server.bin /opt/rtems/rtems4.7/i386-rtems4.7/pc386/build-tools/bin2boot -v o-optimize/stub_server.bt 0x00097E00 /opt/rtems/rtems4.7/i386-rtems4.7/pc386/lib/start16.bin 0x00097C00 0 o-optimize/stub_server.bin 0x0010 0 Plus, there are a few magic numbers there which use I need to figure out. You can do this using add_custom_command(), you could create a macro for that in Rtems.cmake. Alex ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Cross compile + shared libs problem
On Wed, Apr 02, 2008 at 01:39:11AM +0200, Alexander Neundorf wrote: On Wednesday 02 April 2008, you wrote: On Tue, Apr 01, 2008 at 10:12:20PM +0200, Alexander Neundorf wrote: On Tuesday 01 April 2008, you wrote: On Sat, Mar 29, 2008 at 12:25:45AM +0100, Alexander Neundorf wrote: On Tuesday 25 March 2008, you wrote: ... I validated the general approach this morning, should be ready by tomorrow. News ? Sorry, I couldn't quite save time to make a nice platform file. Would you accept the following Rtems.make so that at least CMAKE_SYSTEM_NAME == Rtems works? Hmm, no, that's a bit too little yet. If this is really enough to have apps and libs build for rtems, yes. If not, we can do that later. If you have questions, just ask :-) Well, I didn't figure out what should go to Platform, and what should go to Toolchain. In fact the target is processor + bsp [1]. Should we make a Toolchain per processor + bsp? [1] Board Support Package, for example for sparc: * ERC32 with FPU * SPARC Instruction Simulator (sis) * leon2 * leon3 You must have: Rtems.cmake You can have Rtems-GNU-C.cmake Rtems-GNU-CXX.cmake and for different boards you could consider setting CMAKE_SYSTEM_PROCESSOR, e.g. to leon3, then you could have additionally: Rtems-GNU-C-leon2.cmake Rtems-GNU-CXX-leon2.cmake These two files will be loaded before Rtems-GNU-C.cmake and Rtems-GNU-CXX.cmake, so you can adjust variables in Rtems-GNU-[C|CXX]-leon2.cmake which can then be used in Rtems-GNU-[C|CXX].cmake Does this help ? It does yes, thanks. Regards, Frederik ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Cross compile + shared libs problem
On Tuesday 25 March 2008, you wrote: ... I validated the general approach this morning, should be ready by tomorrow. News ? Alex ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Cross compile + shared libs problem
On Tuesday 25 March 2008, Frederik Deweerdt wrote: On Tue, Mar 25, 2008 at 01:19:52AM +0100, Alexander Neundorf wrote: On Tuesday 25 March 2008, Frederik Deweerdt wrote: Hi, I'm trying to cross-compile static libraries for RTEMS. Our project's also targets Linux, where we use shared libraries. We declare the libraries with: add_library(libname srcs...). So STATIC or SHARED is omitted. On RTEMS there are no static libraries, so I was expecting that by setting BUILD_SHARED_LIBS to OFF in the toolchain file, I would get static libraries. Does this value end up in the cache ? Is it still OFF in the cmake files of your application ? Hm yes, sorry I missed a trivial set in one of our CMakeLists.txt. So it works now ? In Modules/Platform/ you can find an eCos.cmake. eCos is in general quite similar to RTEMS (also RTOS, also one address space, also no shared libs, etc.). It contains: # eCos doesn't support shared libs SET_PROPERTY(GLOBAL PROPERTY TARGET_SUPPORTS_SHARED_LIBS FALSE) SET(CMAKE_CXX_LINK_SHARED_LIBRARY ) SET(CMAKE_CXX_LINK_MODULE_LIBRARY ) SET(CMAKE_C_LINK_SHARED_LIBRARY ) SET(CMAKE_C_LINK_MODULE_LIBRARY ) You should also create a RTEMS.cmake (if you haven't done so yet) and use these settings there. If you have problems with this let me know. I'd really be happy to add that to cmake cvs. I first did that, but as I need it done for tomorrow, I ended up throwing the four lines (a ripoff of eCos.cmake basically), in the Toolchain file. I'll be able to send you a cleaned-up patch later this week. Yes, please do so :-) Alex ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Cross compile + shared libs problem
On Tue, Mar 25, 2008 at 05:55:00PM +0100, Alexander Neundorf wrote: On Tuesday 25 March 2008, Frederik Deweerdt wrote: On Tue, Mar 25, 2008 at 01:19:52AM +0100, Alexander Neundorf wrote: On Tuesday 25 March 2008, Frederik Deweerdt wrote: Hi, I'm trying to cross-compile static libraries for RTEMS. Our project's also targets Linux, where we use shared libraries. We declare the libraries with: add_library(libname srcs...). So STATIC or SHARED is omitted. On RTEMS there are no static libraries, so I was expecting that by setting BUILD_SHARED_LIBS to OFF in the toolchain file, I would get static libraries. Does this value end up in the cache ? Is it still OFF in the cmake files of your application ? Hm yes, sorry I missed a trivial set in one of our CMakeLists.txt. So it works now ? Yes it does, thanks. In Modules/Platform/ you can find an eCos.cmake. eCos is in general quite similar to RTEMS (also RTOS, also one address space, also no shared libs, etc.). It contains: # eCos doesn't support shared libs SET_PROPERTY(GLOBAL PROPERTY TARGET_SUPPORTS_SHARED_LIBS FALSE) SET(CMAKE_CXX_LINK_SHARED_LIBRARY ) SET(CMAKE_CXX_LINK_MODULE_LIBRARY ) SET(CMAKE_C_LINK_SHARED_LIBRARY ) SET(CMAKE_C_LINK_MODULE_LIBRARY ) You should also create a RTEMS.cmake (if you haven't done so yet) and use these settings there. If you have problems with this let me know. I'd really be happy to add that to cmake cvs. I first did that, but as I need it done for tomorrow, I ended up throwing the four lines (a ripoff of eCos.cmake basically), in the Toolchain file. I'll be able to send you a cleaned-up patch later this week. Yes, please do so :-) I validated the general approach this morning, should be ready by tomorrow. Regards, Frederik ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] Cross compile + shared libs problem
Hi, I'm trying to cross-compile static libraries for RTEMS. Our project's also targets Linux, where we use shared libraries. We declare the libraries with: add_library(libname srcs...). So STATIC or SHARED is omitted. On RTEMS there are no static libraries, so I was expecting that by setting BUILD_SHARED_LIBS to OFF in the toolchain file, I would get static libraries. I do get static libraries for RTEMS, but cmake complains that: ADD_LIBRARY for library tsp_services is used with the SHARED option, but the target platform supports only STATIC libraries. Building it STATIC instead. This may lead to problems. Did I miss something, or is BUILD_SHARED_LIBS not working as expected? I'm using today's cmake CVS. Regards, Frederik ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
