On 01/07/2013 12:16 AM, Vincent Danjean wrote: > Here are two more patches that you might want to consider: > - one for the ICD file. In the Debian package, I wont use the full > libdir path but instead let the linker find the library throught the > standard library paths. This allows to use the same icd file on all > architectures (important for Debian multiarch). > I do not think that this part of the patch must be applied > upstream (there would be problems if libdir is not a standard path) > However, this patch also set the library name to the full SONAME > and not to the solink for development. Ie, I think that it would be > better to put @libdir@/libpocl.so.1 instead of @libdir@/libpocl.so > in pocl.icd.in upstream.
I committed this as is. We need to remember to update the file when the library version is increased. > - the second patch try to remove superfluous linkage for various > libraries and binaries. These have been detected by debian build > tools (libraries and binaries link to libraries without using > any of there symbols). > Note that at several places, "llvm-config --ldflags" was used > instead of linking to libllvm. "llvm-config --ldflags" are the > flags used to build libllvm itself, not what you want to use > when to want to link *to* libllvm. > Note also that I only checked/looked at what is currently used > in the Debian package (ie not tce, ...) Also this. I'll fix the possible issues with TCE separately. >>> For each of them: >>> - is it intended that the user run them directly ? >> >> Only the pocl-standalone which can be used to build kernels offline. >> This is used by TCE to build standalone OpenCL programs fully offline. > > Then pocl-standalone will need a manpage in the Debian package. > If you can give me some text, I will create the manpage itself. "pocl-standalone can be used to compile OpenCL C kernels to work group functions outside from any OpenCL host program. It relies on the reqd_work_group_size attribute to figure out the local size for the work group function. The output is an LLVM bitcode with the work group function generated from the kernels in the given input .cl file. Usage: pocl-standalone [-t target] -h <header> -o <output_file> <input_file> -t target can be used to set the target CPU architecture for the compilation -h header the filename where to store a C header with kernel metadata -o output the filename of the target bitcode for the work group function input_file the OpenCL C kernel description (.cl)" >>> - are they invoked by libpocl ? >> >> Others than pocl-standalone are. > > They would be better placed into (a subdirectory of) pkglibdir > >> This causes a known unsolved problem with the search paths. You, as >> a more experienced packager, might actually know the proper solution. >> >> https://bugs.launchpad.net/pocl/+bug/1037932 > > I just added a comment. > >> Also, Kalle has been working on a branch which avoids using the >> scripts by using the LLVM through its C++ APIs instead, but it >> didn't make it to the 0.7 release: >> >> https://code.launchpad.net/~kraiskil/pocl/api > > So, I will try to see if I can improve the scripts situation a > little bit but I wont do lots of things as it will be better fixed > later with Kalle work. Do you mean that you are working on https://bugs.launchpad.net/pocl/+bug/1037932? I agree that minimal should be done for that as it hopefully will be resolved properly by the LLVM API call work. -- Pekka ------------------------------------------------------------------------------ Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft MVPs and experts. SALE $99.99 this month only -- learn more at: http://p.sf.net/sfu/learnmore_122412 _______________________________________________ pocl-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/pocl-devel
