Re: [gentoo-sparc] Official SPARC64 Port

[Mike Frysinger]

On 01 Feb 2016 15:34, Alex McWhirter wrote:
> On 02/01/2016 03:24 PM, Mike Frysinger wrote:
> > On 01 Feb 2016 14:29, Alex McWhirter wrote:
> >> On 02/01/2016 12:44 PM, Mike Frysinger wrote:
> >>> On 29 Jan 2016 19:55, Alex McWhirter wrote:
> >>>> On 01/29/2016 07:44 PM, Mike Frysinger wrote:
> >>>>> On 29 Jan 2016 19:28, Alex McWhirter wrote:
> >>>>>> Regarding the issue with pcitutils, it is indeed and issue with gold. It
> >>>>>> turns out udev is broken as well, as in it wont start.
> >>>>>>
> >>>>>> binutils has supposedly fixed this issue upstream, i may try to emerge
> >>>>>> 9999 later tonight. perhaps eudev fairs a bit better than udev? Would
> >>>>>> there be any issue with moving to eudev as a default?
> >>>>> arches should not be picking any defaults like udev.  we should be using
> >>>>> the same default across all linux systems.  especially if the only point
> >>>>> is to workaround a bug in gold.
> >>>>>
> >>>>> is the fix in binutils-2.26 ?  that's going into the tree in a bit ...
> >>>>> i'm waiting for some feedback from upstream before i push it.
> >>>> I can check to see if the fix is in .26, but eudev does work without
> >>>> issue for what it's worth. pciutils is also compiling without issue with
> >>>> eudev.
> >>>>
> >>>> I will try pulling 9999 and see if the issue is no longer there, if it's
> >>>> been resolved there then ill check into .26
> >>>>
> >>>> Without that fix, sparc64 is probably a no-go. I suppose we could always
> >>>> patch .25 if needed.
> >>> why ?  as i said, gold is not the default, and we don't hold up issues
> >>> because of gold compatibility.  if sparc64 w/ld.bfd works fine, then
> >>> that's all we need.
> >> It looks like udev is hard coded to use gold, i may have to hack around
> >> with configure.ac to get it to compile with bfd.
> > OK, that's an important point :).  yes, we'll want to deploy a hack for
> > `use sparc` to the udev ebuild to disable the usage of gold.  should be
> > as simple as:
> > 	if use sparc ; then
> > 		sed -i 's:-Wl,-fuse-ld=gold::' configure.ac || die
> > 	fi
>
> The systemd mailing list makes it look like this may not be a sparc only
> problem, it looks like it can also happen to 64 bit mips. What about
> patching configure.ac to have an --disable-lto option?

in cases like this, the preference would be to get any patches merged
upstream, and then add that to our ebuild.  but if upstream won't pick
up a patch that'll help, just minimize the sed/patch hackary.  generally
the whole point of doing a "clean" patch is to get it merged upstream.
-mike