At 3:19 AM -0800 1/9/10, Paul D. Buck wrote: >ONe question, you note that .27 adds both the slot and project dir >to the path variables, are those local to the specific session >launched from the slot?
The code is in ACTIVE_TASK::start() in app_start.cpp. It sets the environment variables after the fork() but before the execv(), so yes, it is local to the project application. But I suppose it wouldn't hurt to put some debugging code in an application to make sure that the LD_LIBRARY_PATH and DYLD_LIBRARY_PATH environment variables are preserved after the switcher helper application changes the user and group to boinc_project. >Collatz did for a day or so deliver the libs as part of the >application but I wonder if that is the best way or not... could we >get into a lib version colision issue if they reverted to this mode? I would think this would not be a problem as long as usr/local/cuda/lib/ was not in the library search path. And I think the less you require volunteers to install, the more people you are likely have to participate. But there is a possible complication in that NVIDIA has two different installers: CUDA Driver 2.3.1a is for use with Quadro FX 4800 or GeForce GTX 285 on MacOS X 10.5.2 or later (pre-SnowLeopard), and any NVIDIA GPU on SnowLeopard. CUDA Driver 2.3.0a for all other NVIDIA GPUs on MacOS X 10.5.2 or later (pre-SnowLeopard). It is not clear whether the difference is only in the CUDA.kext driver or if the libraries are also different. The two versions of libcuda.dylib have slightly different sizes. Cheers, --Charlie >On Jan 9, 2010, at 12:59 AM, Charlie Fenton wrote: > >> This seems to imply that you expect libcudart.dylib to be installed >> on the target system in the /usr/local/cuda/lib/ directory. The >> current production release of the CUDA driver for OS 10.6 Snow > > Leopard is version 2.3.1a. It installs only libcuda.dylib in that >> directory, but not libcudart.dylib. >> >> BOINC 6.10.27 adds the slot and project directory to both the > > LD_LIBRARY_PATH and DYLD_LIBRARY_PATH environment variables. I >> wonder if it would help if we also added the /usr/local/cuda/lib/ >> directory to them. >> >> But that would still not take care of the missing libcudart.dylib. >> >> Cheers, >> --Charlie >> >> At 12:49 AM -0600 1/9/10, Jon Sonntag wrote: >>> I tried using -rpath when compiling, but without any success so >>>far. None of >>> the following seemed to work: >>> >>> -rpath=/usr/local/cuda/lib >>> -rpath /usr/local/cuda/lib >>> -W1,-rpath,/usr/local/cuda/lib >>> >>> I did find a work-around though... It is a one-time setup that should work >>> for all BOINC OS X CUDA projects. >>> >>> cd /usr/lib >>> sudo ln -s /usr/local/cuda/lib/libcuda.dylib libcuda.dylib >>> sudu ln -s /usr/local/cuda/lib/libcudart.dylib libcudart.dylib >>> >>> The above takes advantage of the DYLD_FALLBACK_LIBRARY_PATH variable which >>> is not displayed via printenv but does exist and defaults to >>> $HOME/lib:/usr/local/lib:/usr/lib >>> More info can be found about it at >>> https://wiki.ucar.edu/display/dasg/Building+with+shared+libs >>> >>> Jon Sonntag >>> >>> -----Original Message----- >>> From: [email protected] >>> [mailto:[email protected]] On Behalf Of Paul D. Buck >>> Sent: Saturday, January 09, 2010 12:01 AM >>> To: BOINC Developers Mailing List >>> Subject: Re: [boinc_dev] MAC OS X CUDA App in BOINC >>> >>> Did you try that alteration to the path suggested on the Collatz board? >>> >>> Were you using the downloaded application? >>> >>> I have been wondering if the downloaded application is compiled >>>as 64 bit or >>> not... too many questions and to this point not enough answers... > >> >>> And I noticed that I "fat-fingered" *NOW* as *NOT* in my post. Collatz is >>> downloading the application and the libraries but the slots cannot seem to >>> "see" the libraries in the base project direcotry (should they be copied to > >> the slot directories?) ... >>> >>> On Jan 8, 2010, at 9:43 PM, zombie67 wrote: >>> >>>> Same here. Just tell me what I can do to help. >>>> >>>> I have the machine was was able to run the collatz CUDA app stand alone > >> with a GT 120. >>>> >>>> >>>> On Jan 8, 2010, at 7:34 PM, Paul D. Buck wrote: >>>> >>>>> Collatz is not sending down the libs with the application but they cannot >>> be found yet. I suggested adding the links to the application using the >>> standard BOINC mechanisms. >>>>> >>>>> If I knew how to fake this locally by editing config files I would see if >>> it works. Shipping only the 32-bit BOINC application has allowed the >>> discovery of the GPU for CUDA. I still wonder if the application is being >>> compiled in the 64-bit space and so it is not finding the 32-bit libraries >>> regardless. >>>>> >>>>> As always, willing to lend a hand if someone tells me what they want me >>> to try ... though my 8800 card is going to suck swamp water for doing work >>> ... >>>>> >>>>> >>>>> On Jan 8, 2010, at 2:47 PM, Charlie Fenton wrote: >>>>> >>>>>> This is the same problem that einst...@home is having with their beta >>> CUDA application on the Mac. We will be investigating next week when they >>> return from vacation. >>>>>> >>>>>> Cheers, >>>>>> --Charlie >>>>>> >>>>>> At 12:07 AM -0800 1/8/10, Paul D. Buck wrote: >>>>>>> Collatz has an application ready to go also. Though it is currently >>> compiled as a 64-bit version. >>>>>>> >>>>>>> I am not sure if this is the cause of the issue where even with an app >>> info file I cannot get work or there is something going on with the system >>> still... >>>>>>> >>>>>>> Hmm, am getting work now, but also getting this error: >>>>>>> >>>>>>> dyld: Library not loaded: @rpath/libcudart.dylib >>>>>>> Referenced from: /Library/Application Support/BOINC >>> >>>Data/slots/5/../../projects/boinc.thesonntags.com_collatz/collatz_2.01_i686- >>> apple-darwin__cuda >>>>>>> Reason: image not found >>>>>>> >>>>>>> >>>>>>> On Jan 7, 2010, at 5:35 PM, Charlie Fenton wrote: >>>>>>> >>>>>>>> That is what einst...@home is doing, though they don't have that >>>>>>>> working yet. You might want to collaborate with them. They are >>>>>>>> setting environment variables DYLD_LIBRARY_PATH and LD_LIBRARY_PATH >>>>>>>> in their application, and using the @rpath macro. >>>>>>>> >>>>>>>> The standard installation of the CUDA driver on the Mac includes only >>>>>>>> libcuda.dylib. and this is the only one used or checked by the BOINC >>>>>>>> client. You cannot assume that the runtime and other libraries have >>>>>>>> be installed on the system. >>>>>>>> >>>>>>>> At 9:24 AM -0600 1/7/10, Jon Sonntag wrote: >>>>>>>> >>>>>>>>> I assume I will need to include the cuda runtime library along with >>> the cuda >>>>>>>>> >>>>>>>>> app so that the MAC user doesn't have to set any environment >>>>>>>>> >>>>>>>>> variables or create symbolic links. >>>>>>>>> >>>>>> >>>>> >>>>> _______________________________________________ >>>>> boinc_dev mailing list >>>>> [email protected] >>>>> http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev >>>>> To unsubscribe, visit the above URL and >>>>> (near bottom of page) enter your email address. >>>> >>>> _______________________________________________ >>>> boinc_dev mailing list >>>> [email protected] >>>> http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev >>>> To unsubscribe, visit the above URL and >>>> (near bottom of page) enter your email address. >>> >>> _______________________________________________ >>> boinc_dev mailing list >>> [email protected] >>> http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev >>> To unsubscribe, visit the above URL and >>> (near bottom of page) enter your email address. >> >> >> -- >> Charlie Fenton [email protected] >> BOINC / s...@home Macintosh & Windows Programmer >> Space Sciences Laboratory > > UC Berkeley >> _______________________________________________ >> boinc_dev mailing list >> [email protected] >> http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev >> To unsubscribe, visit the above URL and >> (near bottom of page) enter your email address. -- Charlie Fenton [email protected] BOINC / s...@home Macintosh & Windows Programmer Space Sciences Laboratory UC Berkeley _______________________________________________ boinc_dev mailing list [email protected] http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev To unsubscribe, visit the above URL and (near bottom of page) enter your email address.
