On 10/05/2012 08:58 PM, Yi Ge wrote: > But I can NOT run the examples, the issue is that inside clCreateKernel > function, it calls the lt_dlopen, but it didn't return any errors, but exit > inside the lt_dlopen, the descriptor_filename was verified correct. Because > there is no error reported, I was baffled by it. Is there any advice for it?
Are you using the latest development branch, BTW? You should as there has been a lots of improvements since 0.6. 'bzr co lp:pocl' is the way to get it. One problem with the dlopen call that loads the compiled kernel dynamic library for execution is that it reports a file not found error even though the reason is something else, e.g., unresolved symbols in the dynamic module. I encountered problems with the dlopen yesterday when I quickly tested porting to the PowerPC of Cell on a Debian Sid installed in a PlayStation 3. The problem there was that in the default powerpc32 compilation mode (of Debian/ppc32) the kernels were still compiled in 64 bit mode and the dlopen failed to load the kernel .so. It's probably because of not finding the correct 64 bit libraries required by the plugin, or perhaps the 32/64 compat of PowerPC64 doesn't work that way around. I got it working to some extent by forcing the 32-bit mode also to the clang/LLVM. Also it seemed to work now in a Debian Sid for ppc64 (installed in a chroot jail) in the PlayStation 3 without pocl modifications. However, there were test failures which I didn't have time to debug yet. You can check if your problem is caused by missing symbols by using 'nm parallel.so' in the final parallel kernel binary (remember the POCL_LEAVE_TEMP_DIRS and POCL_TEMP_DIR envs, doc/envs.txt). Check for symbols marked 'U'. In some cases it might happen that the built-in requires a libm library function which is not linked in for some reason. The place to poke is the 'run' implementation of the pocl-pthread.c device layer implementation. Also I recall problems specific to ARM compilation from the ARM port experiment. They were related to the multiple ways ARM binaries can handle floats, which might make the ABIs incompatible in case the other library is compiled with different float settings (soft float vs. hardware float). This type of ABI incompatiblity might also cause such problems in dlopen(). I think I added some llc/linker switches to configure.ac specific for the arm port which can be enabled with ./configure --enable-arm-cortex-a8. However, as that experiment was almost a year ago things might have outdated. -- --Pekka ------------------------------------------------------------------------------ Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev _______________________________________________ pocl-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/pocl-devel
