[Bug 173053] Review Request: perl-Readonly-XS
by Red Hat Bugzilla
Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug report.
Summary: Review Request: perl-Readonly-XS
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=173053
paul(a)city-fan.org changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |ASSIGNED
AssignedTo|gdk(a)redhat.com |paul(a)city-fan.org
OtherBugsDependingO|163776 |163778
nThis| |
------- Additional Comments From paul(a)city-fan.org 2005-12-08 06:26 EST -------
Review:
- rpmlint clean
- package and spec naming OK
- spec file written in English and is legible
- sources match upstream
- package builds OK on FC4 (i386) and in mock for rawhide (i386)
- no locales, libraries, subpackages or pkgconfigs to worry about
- not relocatable
- no directory ownership or permissions problems
- no duplicate files
- code, not content
- %clean section present and correct
- macro usage is consistent
- no large docs
- docs don't affect runtime
- no desktop entry needed
- no scriptlets
Needswork:
- license is same as perl (i.e. GPL or Artistic), not just Artistic
- redundant BR perl (listed in exceptions section of packaging guidelines)
Suggestions:
- minor change to %description:
Readonly::XS is a companion module for Readonly, to speed up read-only
scalar variables.
Note:
- version 1.04 of this module is now available, and presents a couple of issues
if you're considering updating this package:
* The "Requires: perl-Readonly = %{version}" won't be satisfied because there is
no 1.04 version of perl-Readonly
* The Makefile.PL introduces a buildreq on Readonly, which will be a circular
dependency since your perl-Readonly package requires perl-Readonly-XS
--
Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.
18 years, 4 months
[Bug 172677] Review Request: perl-Readonly
by Red Hat Bugzilla
Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug report.
Summary: Review Request: perl-Readonly
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=172677
paul(a)city-fan.org changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |ASSIGNED
AssignedTo|gdk(a)redhat.com |paul(a)city-fan.org
OtherBugsDependingO|163776 |163778
nThis| |
------- Additional Comments From paul(a)city-fan.org 2005-12-08 06:25 EST -------
Review:
- rpmlint clean
- package and spec naming OK
- spec file written in English and is legible
- sources match upstream
- package builds OK on FC4 (i386) and in mock for rawhide (i386)
- no locales, libraries, subpackages or pkgconfigs to worry about
- not relocatable
- no directory ownership or permissions problems
- no duplicate files
- code, not content
- %clean section present and correct
- macro usage is consistent
- no large docs
- docs don't affect runtime
- no desktop entry needed
- no scriptlets
Needswork:
- license is same as perl (i.e. GPL or Artistic), not just Artistic
- redundant BR perl (listed in exceptions section of packaging guidelines)
- redundant BR's perl(Test::More) and perl(Test::Harness) - both modules are
bundled with perl
Suggestions:
- use %{?_smp_mflags} with make in %build
- "find $RPM_BUILD_ROOT -type f -name '*.bs' -a -size 0 -exec rm -f {} ';'" not
needed for noarch packages
--
Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.
18 years, 4 months
[Bug 136009] MakeMaker::MM_Unix doesn't honor LD_RUN_PATH requirements
by Red Hat Bugzilla
Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug report.
Summary: MakeMaker::MM_Unix doesn't honor LD_RUN_PATH requirements
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=136009
------- Additional Comments From jvdias(a)redhat.com 2005-12-06 19:04 EST -------
(In reply to comment #13)
> ld does not search LD_LIBRARY_PATH at compile time, that's not feasible.
>
Yes, ld DOES use LD_LIBRARY_PATH if no LD_RUN_PATH or -rpath option is supplied:
>From man ld(1):
"
The linker uses the following search paths to locate required shared libraries.
1. Any directories specified by -rpath-link options.
2. Any directories specified by -rpath options. The difference between
-rpath and -rpath-link is that directories specified by -rpath options
are included in the executable and used at runtime, whereas the -rpath-link
option is only effective at link time. It is for the native linker
only.
3. On an ELF system, if the -rpath and "rpath-link" options were not used,
search the contents of the environment variable "LD_RUN_PATH". It is
for the native linker only.
"(
And then an RPATH header is inserted in the object !
)"
4. On SunOS, if the -rpath option was not used, search any directories
specified using -L options.
5. For a native linker, the contents of the environment variable
"LD_LIBRARY_PATH".
6. For a native ELF linker, the directories in "DT_RUNPATH" or "DT_RPATH"
of a shared library are searched for shared libraries needed by it.
The "DT_RPATH" entries are ignored if "DT_RUNPATH" entries exist.
"
There are thus many ways to avoid specifying absolute paths to libraries in
LIBS and getting an RPATH inserted by MakeMaker generating LD_RUN_PATH .
> It seems entirely broken to assume that an RPATH is needed for every library
> search path specified in any case.
Well, this is the way the upstream MakeMaker is designed and documented to work.
It's not really unreasonable to those programmers less familiar with the guts
of C program building - if you specify a fully qualified absolute path to
a library in LIBS, MakeMaker will try to ensure that the path is stored in the
resultant object with LD_RUN_PATH / RPATH . There are many ways to avoid using
full paths to libraries, eg. by using only '-l' options and LD_LIBRARY_PATH.
--
Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.
18 years, 4 months
[Bug 136009] MakeMaker::MM_Unix doesn't honor LD_RUN_PATH requirements
by Red Hat Bugzilla
Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug report.
Summary: MakeMaker::MM_Unix doesn't honor LD_RUN_PATH requirements
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=136009
------- Additional Comments From jvdias(a)redhat.com 2005-12-06 18:50 EST -------
This is very strange. I also have an FC5test1 system updated to latest everything,
and I've tried the Compress::Zlib build, both inside and out of CPAN shell, both
as root and a non-root user, and I get no RPATH .
Aha! I just noticed you are building from the SRPM - I was building the
upstream CPAN module tarball .
I see now the answer: the perl-Compress-Zlib.spec file explicitly sets the
ZLIB_LIB environment variable to the full /usr/lib (on i386) path . This is
presumably to stop builds on certain 64-bit platforms from picking up
/usr/lib64/libz* .
So because of the LD_RUN_PATH feature now being enabled in perl, this setting
is now able to have the intended effect : the Zlib.so will explicitly link
to /usr/lib/libz.so* instead of /usr/lib64/libz.so*, even if /usr/lib64 precedes
/usr/lib in a LD_LIBRARY_PATH setting in the link-time environment - this
would not have been the case with only the perl-5.8.3-empty-rpath.patch applied
to perl, meaning that no RPATH would have been inserted in Zlib.so .
--
Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.
18 years, 4 months
[Bug 136009] MakeMaker::MM_Unix doesn't honor LD_RUN_PATH requirements
by Red Hat Bugzilla
Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug report.
Summary: MakeMaker::MM_Unix doesn't honor LD_RUN_PATH requirements
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=136009
------- Additional Comments From ville.skytta(a)iki.fi 2005-12-06 17:51 EST -------
(In reply to comment #12)
> > Another example would be to rebuild perl-Compress-Zlib with the new perl and
> > witness how /usr/lib, a standard system dir, is unnecessarily stuffed into a
> > rpath.
> I don't see this problem when building with the latest perl on
> FC-3, FC-4, FC-5, or RHEL-4: [...]
I get different results, this is with FC5test1 updated to latest everything from
Rawhide, in a FC devel CVS tree checkout:
[scop@gk012 perl-Compress-Zlib]$ make compile
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 148k 100 148k 0 0 78862 0 0:00:01 0:00:01 --:--:-- 100k
-rw-r--r-- 1 scop scop 151972 Dec 7 00:53 Compress-Zlib-1.41.tar.gz
rpmbuild --define [...]
[...]
+ exit 0
[scop@gk012 perl-Compress-Zlib]$ objdump -x
Compress-Zlib-1.41/blib/arch/auto/Compress/Zlib/Zlib.so | grep RPATH
RPATH /usr/lib
$ rpm -q perl
perl-5.8.7-0.8.fc5
--
Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.
18 years, 4 months