Hi,
When building gcc 5.1 rpm (based on f22 spec) to a different prefix I get a list of .so unpackaged files: /opt/gnu/gcc/5.1.0/lib64/libasan.so /opt/gnu/gcc/5.1.0/lib64/libatomic.so /opt/gnu/gcc/5.1.0/lib64/libcilkrts.so /opt/gnu/gcc/5.1.0/lib64/libgcc_s.so /opt/gnu/gcc/5.1.0/lib64/libgfortran.so /opt/gnu/gcc/5.1.0/lib64/libgomp-plugin-host_nonshm.so /opt/gnu/gcc/5.1.0/lib64/libgomp.so /opt/gnu/gcc/5.1.0/lib64/libitm.so /opt/gnu/gcc/5.1.0/lib64/liblsan.so /opt/gnu/gcc/5.1.0/lib64/libmpx.so /opt/gnu/gcc/5.1.0/lib64/libmpxwrappers.so /opt/gnu/gcc/5.1.0/lib64/libobjc.so /opt/gnu/gcc/5.1.0/lib64/libquadmath.so /opt/gnu/gcc/5.1.0/lib64/libstdc++.so /opt/gnu/gcc/5.1.0/lib64/libtsan.so /opt/gnu/gcc/5.1.0/lib64/libubsan.so
I know the usual solution is to place such symlinks in the <lib>-devel package, but for most of those libs there is no devel counterpart, so I'm wondering what are best practices in this case.
I figure I can 1. Just ignore them (I have %global _unpackaged_files_terminate_build 0) 2. Remove them in %install 3. Add them to their respective %files lib 4. Create an %files lib-devel for each one
Which is preferred, if at all? As a potential follow-up: If 1 or 3, why bother creating them in the first place?
On Mon, 27 Apr 2015 19:18:15 +0300, Daniel Letai wrote:
Hi,
When building gcc 5.1 rpm (based on f22 spec) to a different prefix I get a list of .so unpackaged files:
How did you modify the gcc.spec to relocate the files? Where are those files installed without your modification? You can use rpmls or repoquery to find out. Perhaps your %files sections don't match the changed location?
I know the usual solution is to place such symlinks in the <lib>-devel package,
There is _no_ such "solution". The guidelines have been updated a few times, because some packagers have put all .so files into -devel packages without a second thought.
There is only one real solution: Put .so files into the (sub-)packages they belong into. Where they belong into depends on *when* they are needed? At run-time? At build-time? Both?
but for most of those libs there is no devel counterpart,
GCC is a development tool in a development package that doesn't have -devel in its name. With a bit of fantasy one could make it depend on lots of -devel packages just to be explicit for some of the libs, but some of the build-time libs may be needed always, so they are not in separate packages (except for runtime libs).
so I'm wondering what are best practices in this case.
Put them where they belong.
I figure I can
- Just ignore them (I have %global _unpackaged_files_terminate_build 0)
- Remove them in %install
That sounds much as if you don't know what you're doing.
- Add them to their respective %files lib
- Create an %files lib-devel for each one
Which is preferred, if at all? As a potential follow-up: If 1 or 3, why bother creating them in the first place?
Sent from my iPhone
On Apr 28, 2015, at 00:42, Michael Schwendt mschwendt@gmail.com wrote:
On Mon, 27 Apr 2015 19:18:15 +0300, Daniel Letai wrote:
Hi,
When building gcc 5.1 rpm (based on f22 spec) to a different prefix I get a list of .so unpackaged files:
How did you modify the gcc.spec to relocate the files?
I can paste the spec but basically hard-coded _prefix and friends, and corrected errors as they popped up.
Where are those files installed without your modification? You can use rpmls or repoquery to find out.
They're not installed. Well, that's not entirely true. The files are installed both in origin and my fork in the prefix/lib/gcc/... path, but a duplicate also exists in the prefix/%_lib/ path which never gets packaged. I'm asking about this duplicate
Perhaps your %files sections don't match the changed location?
It did at first. I modified it to include more installed but not packaged files
I know the usual solution is to place such symlinks in the <lib>-devel package,
There is _no_ such "solution". The guidelines have been updated a few times, because some packagers have put all .so files into -devel packages without a second thought.
That makes sense. Can you provide a link to the best practice of handling .so files?
There is only one real solution: Put .so files into the (sub-)packages they belong into.
Ok, that's what I did.
Where they belong into depends on *when* they are needed? At run-time? At build-time? Both?
They are unversioned. Not sure when they are ever used in preference of the versioned ones.
but for most of those libs there is no devel counterpart,
GCC is a development tool in a development package that doesn't have -devel in its name. With a bit of fantasy one could make it depend on lots of -devel packages just to be explicit for some of the libs, but some of the build-time libs may be needed always, so they are not in separate packages (except for runtime libs).
Yet the gcc src rpm does produce a few devel packages (e.g libgccjit, libitm...)
so I'm wondering what are best practices in this case.
Put them where they belong.
I figure I can
- Just ignore them (I have %global _unpackaged_files_terminate_build 0)
- Remove them in %install
That sounds much as if you don't know what you're doing.
Or possibly the gcc package maintainer doesn't? I'm not a developer. OTOH I know that gcc rpm does some things that seem wrong to hard core developers (like ignore all the include-fixed headers except limits and syslimits). I was just trying to be thorough and cover all possibilities.
- Add them to their respective %files lib
- Create an %files lib-devel for each one
Which is preferred, if at all? As a potential follow-up: If 1 or 3, why bother creating them in the first place?
-- packaging mailing list packaging@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/packaging
packaging@lists.fedoraproject.org