108429 – fall back on DEFAULT_ABI for --libdir if ABI is not set

Bug 108429 - fall back on DEFAULT_ABI for --libdir if ABI is not set

Summary: fall back on DEFAULT_ABI for --libdir if ABI is not set

Status:	RESOLVED WONTFIX

Alias:	None

Product:	Portage Development
Classification:	Unclassified
Component:	Core (show other bugs)
Hardware:	All Linux

Importance:	High normal (vote)
Assignee:	Portage team

URL:
Whiteboard:
Keywords:

Depends on:
Blocks:

Reported:	2005-10-07 14:00 UTC by Jeremy Huddleston (RETIRED)
Modified:	2005-10-07 14:55 UTC (History)
CC List:	1 user (show)

See Also:
Package list:
Runtime testing required:	---

Attachments
ebuild.sh-libdir.patch (portage_libdir.patch,493 bytes, patch) 2005-10-07 14:01 UTC, Jeremy Huddleston (RETIRED)	Details \| Diff
View All Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.

Description Jeremy Huddleston (RETIRED) gentoo-dev

2005-10-07 14:00:29 UTC

This is needed for amd64 2006.0 as we are not exporting ABI unless it is not the
default.  This behavior change is being made now that we can use CHOST to
properly determine the toolchain starting with the new eselect-compiler wrapper.

Comment 1 Jeremy Huddleston (RETIRED) gentoo-dev

2005-10-07 14:01:52 UTC

Created attachment 70116 [details, diff]
ebuild.sh-libdir.patch

trivial change

Comment 2 Brian Harring (RETIRED) gentoo-dev

2005-10-07 14:05:38 UTC

Err... seems dumb to me to _not_ export ABI, and instead have the code
automatically check and pull the default ABI from another var when it could've,
(potentially should've?) been exported via the profile...

Comment 3 Jeremy Huddleston (RETIRED) gentoo-dev

2005-10-07 14:55:28 UTC

Ok, fair enough... just trying to get it to match the multilib.eclass method of
falling back to DEFAULT_ABI if it's set.  I'll setup the profile to still set
ABI and we can look for a more permanent solution down the road.