On 20/06/2012 2:32 PM, Daniel D. Daugherty wrote:
That all said, it still seems to me that the logic for GENERATED is
not correct if you have done a cd into the 64 subdirectory.
Exactly the opposite is true. Without the TOPDIR/GENERATED combo,
when you "cd 64", the "../generated" that the GENERATED variable
resolves to no longer works. When GENERATED is set to
"$(TOPDIR)/../generated", then it becomes an absolute path that
can be used anywhere...
Yes but "pwd" changes which in turn changes the path to generated. So I
don't see how this works - I assume generated is not moving and that we
don't have multiple generated directories.
Anyway let's defer further discussion to the updated webrev.
David
However, I think where this is going to end up is something like:
- add TOPDIR only to add_gnu_debuglink.make
- set the ADD_GNU_DEBUGLINK variable using TOPDIR and a
literal "../generated/add_gnu_debuglink"
- don't set GENERATED in add_gnu_debuglink.make at all
- drop the changes to fix_empty_sec_hdr_flags.make
I think that'll reduce the risk since this fix needs to
go back to HSX23.2 and HSX24.
Dan
Cheers,
David
Dan
David
-----
On 20/06/2012 11:21 AM, Daniel D. Daugherty wrote:
Greetings,
This is an URGENT code review request for a Solaris specific Full
Debug
Symbols (FDS) fix. Due to a Makefile logic error, the full debug
symbol
files and related '_g' symlinks are created in the wrong sub-directory
for a couple of the dtrace libraries. The incorrect paths have a
double
"64/" sub-directory, e.g.:
solaris-<arch>/jre/lib/<arch>/client/64/64/libjvm_db.debuginfo
These are the correct symlink paths:
solaris-<arch>/fastdebug/jre/lib/<arch>/client/64/libjvm_g_db.debuginfo
solaris-<arch>/fastdebug/jre/lib/<arch>/client/64/libjvm_g_dtrace.debuginfo
solaris-<arch>/fastdebug/jre/lib/<arch>/server/64/libjvm_g_db.debuginfo
solaris-<arch>/fastdebug/jre/lib/<arch>/server/64/libjvm_g_dtrace.debuginfo
and these are the correct debug info file paths:
solaris-<arch>/jre/lib/<arch>/client/64/libjvm_db.debuginfo
solaris-<arch>/jre/lib/<arch>/client/64/libjvm_dtrace.debuginfo
solaris-<arch>/jre/lib/<arch>/server/64/libjvm_db.debuginfo
solaris-<arch>/jre/lib/<arch>/server/64/libjvm_dtrace.debuginfo
solaris-<arch>/fastdebug/jre/lib/<arch>/client/64/libjvm_db.debuginfo
solaris-<arch>/fastdebug/jre/lib/<arch>/client/64/libjvm_dtrace.debuginfo
solaris-<arch>/fastdebug/jre/lib/<arch>/server/64/libjvm_db.debuginfo
solaris-<arch>/fastdebug/jre/lib/<arch>/server/64/libjvm_dtrace.debuginfo
where "<arch>" is "i586" or "sparc". The 64-bit Solaris platforms
("amd64"
and "sparcv9") don't have this issue because they don't have the "64/"
sub-directories.
This fix is targeted at HSX-24/JDK8 and HSX-23.2/JDK7u6 and will
resolve
an issue that is preventing Oracle's Release Engineering scripts from
running properly.
Here is the webrev URL for the HSX-24/JDK8 version:
http://cr.openjdk.java.net/~dcubed/fds_revamp/7175255-webrev/0/
The HSX23.3/JDK7u6 version is the same except for the changes to
make/solaris/makefiles/defs.make which are not needed in HSX23.2.
Thanks, in advance, for any reviews!
Dan
