From: Maynard J. <may...@us...> - 2008-06-26 16:51:10
|
William Cohen wrote: > Maynard Johnson wrote: >> William Cohen wrote: >>> Maynard Johnson wrote: >>>> William Cohen wrote: >>>>> Maynard Johnson wrote: >>>>>> OProfile 0.9.4 Release Candidate 2 is now available and can be >>>>>> found at: >>>>>> >>>>>> http://sourceforge.net/project/showfiles.php?group_id=16191 >>>>>> >>>>>> The major difference between this release candidate and rc1 >>>>>> (released on >>>>>> May 21) is how we handle whether or not the special 'oprofile' user >>>>>> account exists on the system. This release candidate addresses the >>>>>> concern (brought to our attention by Will Cohen) that RPM build >>>>>> machines >>>>>> should not be required to have the special user account. The 'make >>>>>> install' will now just print a warning if the user account does not >>>>>> exist instead of an error. >>>>>> >>>>>> Please test and provide feedback. >>>>>> >>>>>> Thanks. >>>>>> -Maynard Johnson >>>>> >>>>> Hi Maynard, >>>>> >>>>> Thanks for respinning the 0.9.4 release candidate. I was able to >>>>> package the oprofile tar ball the source rpm is at: >>>>> >>>>> http://people.redhat.com/wcohen/oprofile-0.9.4rc2-1.fc9.src.rpm >>>>> >>>>> I built the rpm on a local x86_64 machine, installed the resulting >>>>> RPM, and then ran some simple smoke tests. The results of the tests >>>>> are attached to this email. The tests didn't show any problems on >>>>> this machine. >>>> Will, thanks for testing the new rc. I pulled down your src rpm and >>>> tested it out, too. I noticed that the configure command in your >>>> spec file did not include the '--with-java' option, so the Java >>>> agent libraries were not being configured to build. I'm sure this >>>> is because we didn't give enough guidance to packagers about the new >>>> JIT support. I added a couple paragraphs in the README_PACKAGERS >>>> file (attached) to describe the above steps. Could you have a look >>>> and let me know if it's understandable? >>>> >>>> I made a few changes to the spec file and then built a binary rpm >>>> with which I verified the JIT support. The changes to the spec file >>>> were as follows: >>>> >>>> 1. Added >>>> '--with-java=/usr/lib/jvm/java-1.7.0-icedtea-1.7.0.0.x86_64' to the >>>> configure statement (obviously, this jdk path is dependent on what >>>> jdk package is normally installed for the distro) >>>> 2. Removed the %{_libdir}/oprofile/libopagent* from the '%files >>>> devel' section >>>> 3. Added %{_libdir}/oprofile in the default '%files' section >>> >>> I don't have much experience with the oprofile java support. That >>> --with-java is an install dependency? If so it might be worthwhile to >>> split the oprofile stuff that needs the java support into a separate >>> sub package like oprofile-gui package. People complained about too >>> much stuff being pulled in by the oprof_start, so oprofile-gui >>> subpackage was created. I suspect that some people are going to make >>> similar complaints if a bunch of java support needs to be pulled in. >> Will, >> Yes, you're right, there is no reason the Java agent libraries could >> not be pulled out into a separate package. I've updated the >> README_PACKAGERS file (attached) to reflect that choice. By the way, >> I noticed that your spec file does not pull in the opreport.xsd schema >> file. You might want to add that to your devel package since tool >> developers who want to leverage the xml output would need to see that >> schema. I added a note about this schema file in README_PACKAGERS, too. > > For the next release of oprofile it would be nice to package the > libraries as shared libraries (.so) rather than static (.a). This would > allow easier access to the oprofile data by other programs (e.g. eclipse > and AMD Code Analyst). Changing to shared libraries would also reduce > the need to rebuild those dependent packages if there is a bug fix in > the shared library. hmmm . . . my builds result in both static and shared libraries. > >> I modified your spec file to put the JIT support in a separate >> package, as well as adding the opreport.xsd file to your devel >> package. The binary RPMs tested good. I've attached a diff of your >> spec file and mine just FYI. Please let me know if the >> README_PACKAGERS file provides you with enough info now. > > Thanks for the suggested changes for JIT package. I will be taking a > closer look at that today. Need to make it something that is available > in Fedora. > > What happens when someone has multiple JITs on the machine and oprofile > is configured for a particular one? Oprofile is always going to use the > one used for the build? Might be an issue if someone puts in a newer > version on the machine and oprofile isn't rebuilt. The Java agent libraries support a particular API. So, if you specify a JDK version 1.5 via the '--with-java' configure option, both JVMPI and JVMTI agent libraries are built. (JVMPI was deprecated in Java 1.5 and removed in 1.6.) During profiling, you can use any JVM version that supports the API of the agent library, as long as that JVM is the same bitness as the agent library. On bi-arch machines, there may be both bitness versions of the JVM that can be installed by the user. So it would be recommended to build oprofile both ways (e.g., 32-bit and 64-bit). This is another reason for putting the libopagent and the Java agent libraries in a separate package, since it's only the libraries (which are used by the JVM) that need both bitness versions. (I think that's another tip I should put in the README_PACKAGERS file.) Thanks! -Maynard > > -Will > |