I built all this yesterday

[GoogleCodeExporter]

Everything worked,I ran examples,everyone of them. today I got 12.4 ,so I 
figured i would rebuild it all.I also updates my headers 1.2, from the debian 
repo
I redownloaded svn checkout http://aparapi.googlecode.com/svn/trunk aparapi
I ran ant to see if i got the same error ,I did yesterday to make sure it was 
the same code. I did not get the error, so I knew something had been changed on 
your end. I went to edit the build file, like I did ,the first time.
It appears to no longer be reading that build file, no matter what I put in 
there it will not even throw and error now.It just keeps telling me it needs a 
path to the SDK.

Someone broke the build files, please put them back the way they were. I can 
not understand why people shoot themselves in the foot making changes like that
when you have working code and and pretty good directions how to build.Changing 
build files just pisses people off and makes your directions not work,which 
pisses them off more, they then go download CUDA.AMD started this GPU code long 
before the other people even got started, I used folding at home,but all the 
shooting themselves in the foot have now put them way behind,please stop the 
foot shooting and move forward,it should be a given at this point the software 
will build.

While it was working it was super fast! Thanks for your your time !

Original issue reported on code.google.com by johnmont...@hotmail.com on 10 May 2012 at 6:22

[GoogleCodeExporter]

Johnmont

I suspect this was me.  I am trying to remove the dependency on 
build.properties.  I test built on Linux (Ubuntu) 64 and 32 bit.  Can you tell 
me more about your platform. 

Are you using AMD APP SDK for the OpenCL headers?

Can you tell me what errors you get when you try to build.

Try pulling an earlier version of build.xml and build.properties out of SVN 
(try R#432 it still has references to build.properties)  so we can isolate 
this.  I did add a bunch of cpp code to the project (as part of the extension 
merge) and these files need to be compiled now. 

Apologies for breaking your build, I really did think that I had covered all 
bases when I checked in this code. 

Gary

Original comment by frost.g...@gmail.com on 10 May 2012 at 2:33

[GoogleCodeExporter]

Johnmont

On linux the current build does assume that your SDK is located at /opt/AMDAPP

Could it be that your SDK is somewhere else?  Is this an NVidia/Intel OpenCL  
platform?

If so then I apologize.

You will need to add a stanza to the build.xml, actually if you do this this 
will make the build.xml 'just work' for others.

Note in the top of build.xml there are a bunch of stanza's which are trying to 
find the right compiler and SDK to use.  For Linux it is only checking for 
AMD's APP SDK (/opt/AMDAPP) if your SDK is somewhere else then you will need to 
add a new one.

The pattern is

      <available property="linux.amd.app.sdk.exists" file="<your proposed path>" type="dir"/>
      <condition property="amd.app.sdk.dir" value="<your proposed path>">
         <and>
            <os family="unix" />
            <not>
               <os family="mac" />
            </not>
            <isset property="linux.amd.app.sdk.exists" />
            <not>
               <isset property="win32.amd.app.sdk.exists" />
            </not>
            <not>
               <isset property="win64.amd.app.sdk.exists" />
            </not>
         </and>
      </condition>

So add your new stanza below the current one (looking for /opt/AMDAPP) and 
above :-

      <echo message=" amd.app.sdk.dir ${amd.app.sdk.dir}"/>

Also send whatever you end up adding to me and i will include it in the trunk.  

Again, apologies for breaking this.

Gary

Original comment by frost.g...@gmail.com on 10 May 2012 at 2:49

[GoogleCodeExporter]

Sometimes the Trunk is unstable, it happens, even for CUDA. If you require a 
stable release, then you should download the bundles available at 
http://code.google.com/p/aparapi/downloads/detail?name=aparapi-2012-05-06.zip

Otherwise, if you update to a broken SVN Trunk revision, then you can always 
revert to a previous revision, politely file the issue and wait a resolution.

Original comment by ryan.lam...@gmail.com on 11 May 2012 at 8:34

[GoogleCodeExporter]

OK I wanted to test this all before I made this statement On Debian I have 
everything I need from them to run and compile opencl stuff, Debian does not 
need the AMD SDK. I also saw that at one time Ubuntu had these same packages 
but they removed them from their repo.I downloaded the SDK unzipped it, I did 
not install. I compiled and ran samples HelloCL ect with out any issues. I do 
not have an /opt/AMDAPP dir. None of the samples from the SDK need that 
directory and frankly I would much rather type apt-get update apt-get upgrade 
and not have to deal with the SDK from AMD at all, and since the distro has all 
the file,why should I. I hope this info helped ,Thanks again Gary for your time.

Original comment by johnmont...@hotmail.com on 13 May 2012 at 1:10

[GoogleCodeExporter]

making an empty dir /opt/AMDAPP let aparapi build, it was happy just to see 
that dir even though it is empty,because Debian put the files in the path I 
would guess.Thanks again Gary for your time.

Original comment by johnmont...@hotmail.com on 13 May 2012 at 1:20

[GoogleCodeExporter]

last update it built but none of the examples will run in gpu mode. It makes me 
sad when an idea like AMD's opencl gets support from a major distro like debian 
and people don't make things work nice together,even more sad when it all 
worked a few days ago.
WARNING: Check your environment. Failed to load aparapi native library 
aparapi_x86_64 or possibly failed to locate opencl native library 
(opencl.dll/opencl.so). Ensure that both are in your PATH (windows) or in 
LD_LIBRARY_PATH (linux).

debian:~/amd/AMD-APP-SDK-v2.6-lnx64/AMD-APP-SDK-v2.6-RC3-lnx64/bin/x86_64$ 
./clinfo
Number of platforms:                             1
  Platform Profile:                              FULL_PROFILE
  Platform Version:                              OpenCL 1.2 AMD-APP (923.1)
  Platform Name:                                 AMD Accelerated Parallel Processing
  Platform Vendor:                               Advanced Micro Devices, Inc.
  Platform Extensions:                           cl_khr_icd cl_amd_event_callback cl_amd_offline_devices
the SDK is not install,but as we can see AMD examples run fine.

Good luck Gary Ill come back in a few weeks and try again
This is debian testing BTW they could have broken something

Original comment by johnmont...@hotmail.com on 13 May 2012 at 3:22

[GoogleCodeExporter]

I will also point out that there are many distro's some are going to include 
AMD stuff some are not, as per normal with linux they will not agree where to 
put the files and each distro that includes them will put them a different 
place, leaving your software flexible to deal with that would probably be a 
good idea. I understand wanting to standardize it this may work for windows 
but,nothing with linux is that way,each distro is different, then think maybe 
someone running freebsd wants to try and run it, a whole new can of worms is 
created.If it is left flexible even the freebsd guy will be able to make it run 
or openindiana for that matter.

Original comment by johnmont...@hotmail.com on 13 May 2012 at 3:35

[GoogleCodeExporter]

Thanks for bringing this info back to the list. 

The fact that clinfo works for you is good.  My guess is we just need to sort 
out the dynamic library loading. 

So you have an empty /opt/AMDAPP dir?  

The AMD install will normally add the directory containing the opencl shared 
lib to your LD_LIBRARY_PATH ( I think it edits /etc/profile to do this ), if 
you can find out where clinfo is finding opencl.so and add it to 
LD_LIBRARY_PATH (as well as add the aparapi_x86_64.so to the java command line 
via -Djava.library.path=youraparapidir) then you should be good to go. 

So Linux has a tool for listing the dll's loaded by an executable I think it is 
ldd?

So if you use ldd clinfo and then note where it picks up it's shared libs from 
and add these dirs to the LD_LIBRARY_PATH you should be good to go. 

I did not realize that debian attempted to include OpenCL headers/libs. 

Gary 

Original comment by frost.g...@gmail.com on 14 May 2012 at 12:09

[GoogleCodeExporter]

Original comment by ryan.lam...@gmail.com on 11 Aug 2012 at 12:54

• Changed state: WontFix