| Summary: | dev-libs/libiconv - static archives (*.a) and libtool library files (*.la) do not belong in / | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | René Berber <r.berber> |
| Component: | [OLD] Core system | Assignee: | Portage team <dev-portage> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | bsd+disabled, embedded, prefix |
| Priority: | Normal | ||
| Version: | unspecified | ||
| Hardware: | AMD64 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Attachments: |
emerge --info
Log file of the build emerge -pqv (of the full .ebuild path since it is masked) |
||
|
Description
René Berber
2011-12-21 00:12:41 UTC
Created attachment 296505 [details]
emerge --info
Created attachment 296507 [details]
Log file of the build
Created attachment 296509 [details]
emerge -pqv (of the full .ebuild path since it is masked)
(In reply to comment #0) > * ERROR: dev-libs/libiconv-1.14 failed: > * static archives (*.a) and libtool library files (*.la) do not > belong in / The reason for this error is that Gentoo's policy is to install *.a and *.la in /usr/lib/ rather than /lib/. > The messages are confused, first it complains about the .dll.a which are > then wrongly deleted, then it complains about .a and .la files. > > There is no problem having .a, .dll.a, and .la files together, they are > different things used for different purpose (one is the real static > library, the other is just the symbol definitions used when linking to > the dynamic library). Would it make any sense to re-locate them to /usr/lib/? If they really belong in /lib/, then we could provide a way to allow this in environments such as yours where it is appropriate. The code that would need to be modified is located in /usr/lib/portage/bin/misc-functions.sh. (In reply to comment #4) > The reason for this error is that Gentoo's policy is to install *.a and *.la in > /usr/lib/ rather than /lib/. The log at the end shows 2 things (line 2312 in the log): 1. The .a and .la files are installed to the temporary usr/lib; 2. The .dll.a files apparently where in lib, and they where deleted (I couldn't find them in the work directory); but see comments below. > Would it make any sense to re-locate them to /usr/lib/? If they really belong > in /lib/, then we could provide a way to allow this in environments such as > yours where it is appropriate. The code that would need to be modified is > located in /usr/lib/portage/bin/misc-functions.sh. Configure has a "--prefix=/usr" (line 25 on the log), but... Later (line 549) there is a "make install-lib libdir=\"$builddir/lib\" includedir=\"$builddir/lib\"" which appears to change things to lib, but I'm not sure if this is an intermediary step. The .dll.a file (line 2167) is installed in usr/lib, same for the static libraries. Looking at what the QA message is complaining: libcharset.dll.a the log at line 2167 shows it was installed to the correct directory, i.e. " libtool: install: /usr/bin/install -c -m 644 .libs/libcharset.dll.a /usr/x86_64-w64-mingw32/tmp/portage/dev-libs/libiconv-1.14/image//usr/lib/libcharset.dll.a libtool: install: base_file=`basename libcharset.la` " So the message at the end makes no sense to me. That's why it looks like a bug, not a new feature that needs to be supported (for the package I was trying to build). (In reply to comment #5) > 2. The .dll.a files apparently where in lib, and they where deleted (I couldn't > find them in the work directory); but see comments below. I don't know how they could have been deleted. The code that triggers the message calls die immediately after it finds them, and it doesn't remove them: # Make sure people don't store libtool files or static libs in /lib f=$(ls "${ED}"lib*/*.{a,la} 2>/dev/null) if [[ -n ${f} ]] ; then vecho -ne '\n' eqawarn "QA Notice: Excessive files found in the / partition" eqawarn "${f}" vecho -ne '\n' die "static archives (*.a) and libtool library files (*.la) do not belong in /" fi (In reply to comment #6) > I don't know how they could have been deleted. The code that triggers the > message calls die immediately after it finds them, and it doesn't remove them: My mistake, they are there, not deleted. I was probably looking at the wrong place. Back to the problem, as I said in the log line 2167 the installation of those files is made to usr/lib... unless the double slash has side effects I don't know about (i.e. //usr/lib is treated as /lib). I don't see anything else in the log. Testing by hand the install command works as expected. No idea how those files ended in lib instead of usr/lib. not sure if this is a larger problem with static-only targets (such as mint or mingw (ignoring dll's which are not a tree-wide solution)), or if this could be fixed with the simple:
- # Move static libs and creates ldscripts into /usr/lib
- dodir /$(get_libdir)
- mv "${D}"/usr/$(get_libdir)/lib{iconv,charset}*$(get_libname)* "${D}/$(get_libdir)" || die
- gen_usr_ldscript libiconv$(get_libname)
- gen_usr_ldscript libcharset$(get_libname)
+ gen_usr_ldscript -a iconv charset
(In reply to SpanKY from comment #8) > not sure if this is a larger problem with static-only targets (such as mint > or mingw (ignoring dll's which are not a tree-wide solution)), or if this > could be fixed with the simple: > > - # Move static libs and creates ldscripts into /usr/lib > - dodir /$(get_libdir) > - mv "${D}"/usr/$(get_libdir)/lib{iconv,charset}*$(get_libname)* > "${D}/$(get_libdir)" || die > - gen_usr_ldscript libiconv$(get_libname) > - gen_usr_ldscript libcharset$(get_libname) > + gen_usr_ldscript -a iconv charset this is what current ebuilds have and seem not to be an issue anymore -> closing |
