Hi, I've started looking at RHBZ #1211638 [1] on behalf of the secondary architectures team. There are some issues related to /usr/bin/AtoB and /usr/bin/BtoA on ppc64 and ppc64le - due to the hard coding of platform and architecture dependencies. From what I understand, these scripts found in /usr/bin are generated by the base/java-tools/templates/pki_java_command_wrapper.in template. Currently, I only focus on what is inside the Linux OS block. From what I can understand, the Linux block only sets up the LD_LIBRARY_PATH and I wonder why it does that? I know in earlier days (10-15 years ago) such tweaks where needed when ld.so.conf wasn't updated properly or had issues loading the proper libraries. But is that an issue today at all on Linux? I would like to propose a patch which cleans up this behaviour. If it is believed that LD_LIBRARY_PATH is still needed, I will of course respect that. But I'd like to simplify this whole code block to be less "architecture dependent". Like just using the x86_64 LD_LIBRARY_PATH setup for all arches. The general idea is to not need to care about the $ARCHITECTURE variable at all inside the Linux block. Any thoughts or comments? I've done some simple tests on Fedora 21 (x86_64) stripping out the complete LD_LIBRARY_PATH stuff in AtoB and BtoA. Everything worked just fine.

On 17/04/15 20:09, David Sommerseth wrote: > > Hi, > > I've started looking at RHBZ #1211638 [1] on behalf of the > secondary architectures team. There are some issues related to > /usr/bin/AtoB and /usr/bin/BtoA on ppc64 and ppc64le - due to the > hard coding of platform and architecture dependencies. > > From what I understand, these scripts found in /usr/bin are > generated by the > base/java-tools/templates/pki_java_command_wrapper.in template. > > Currently, I only focus on what is inside the Linux OS block. > > From what I can understand, the Linux block only sets up the > LD_LIBRARY_PATH and I wonder why it does that? I know in earlier > days (10-15 years ago) such tweaks where needed when ld.so.conf > wasn't updated properly or had issues loading the proper libraries. > But is that an issue today at all on Linux? > > I would like to propose a patch which cleans up this behaviour. If > it is believed that LD_LIBRARY_PATH is still needed, I will of > course respect that. But I'd like to simplify this whole code > block to be less "architecture dependent". Like just using the > x86_64 LD_LIBRARY_PATH setup for all arches. The general idea is > to not need to care about the $ARCHITECTURE variable at all inside > the Linux block. > > Any thoughts or comments? I've done some simple tests on Fedora > 21 (x86_64) stripping out the complete LD_LIBRARY_PATH stuff in > AtoB and BtoA. Everything worked just fine. Just a follow-up here. There are several other places where there are such architecture checks have been implemented. I would really like to clean-up this so that pki can function well on other platforms than ia32 and x86_64. To solve the open BZ in the very best way, I do need some input to which approach you prefer; to reduce the complexity by unifying the architectures, or to remove the architecture checks completely. -- kind regards, David Sommerseth _______________________________________________ Pki-devel mailing list Pki-devel(a)redhat.com https://www.redhat.com/mailman/listinfo/pki-devel