Bug 420087

Summary:	allow emerging dev-libs/libiconv for mingw
Product:	Gentoo/Alt	Reporter:	Maciej S. Szmigiero <mail>
Component:	Other	Assignee:	Gentoo/BSD Team <bsd+disabled>
Status:	RESOLVED DUPLICATE
Severity:	normal
Priority:	Normal
Version:	unspecified
Hardware:	x86
OS:	Other
Whiteboard:
Package list:		Runtime testing required:	---

Description Maciej S. Szmigiero 2012-06-07 10:50:52 UTC

dev-libs/libiconv is useful in a mingw environment. Currently it is keyworded only for FreeBSD, so it should to be keyworded for x86 (and possibly amd64, too).
The ebuild already has blocker for glibc, so it should be no problem that somebody emerges this package by mistake on a GNU system.

Also, libiconv-1.14 ebuild calls "gen_usr_ldscript -a". This invokes scanelf on built libraries to extract their SONAME, which obviously won't work on a DLL.
The libiconv-1.13.1 uses "gen_usr_ldscript" without "-a", which has no such problem.


Reproducible: Always

Comment 1 Jeroen Roovers (RETIRED) gentoo-dev

2012-06-07 12:35:07 UTC

I don't think anything is stopping you from emerging it in a mingw environment. And AFAIK we do not have such a keyword. Maybe x86-winnt or x86-interix?

Comment 2 Maciej S. Szmigiero 2012-06-07 12:41:05 UTC

Yes they can be emerged in mingw environment (I assume you mean mingw32-emerge by this), but not before manually keywording this package (otherwise emerge stops with "All ebuilds that could satisfy "dev-libs/libiconv" for /usr/mingw32/ have been masked") and changing this "gen_usr_ldscript" line.

Comment 3 Jeremy Olexa (darkside) (RETIRED) archtester

2012-06-12 21:37:17 UTC

Assigning to dev-libs/libiconv maintainer

Comment 4 Naohiro Aota gentoo-dev

2012-06-16 00:18:49 UTC


*** This bug has been marked as a duplicate of bug 417451 ***