[PREFIX] linker_XXX?

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

[PREFIX] linker_XXX?

Fabian Groffen-2
I've hit this thought a few times now, but every time hacked around it
with assumptions.  However, maybe it is a good idea to make the linker
(and perhaps also the compiler?) visible from ebuilds?  Many "Darwin"
patches are linker patches.

I was thinking of things like

linker_GNU
linker_Darwin
linker_Solaris

or?

[[ ${LINKER} == binutils-2.17* ]]
[[ ${LINKER} == odcctools* ]]

or any other mix inbetween?  Does it make sense to anyone?  Thoughts?


--
Fabian Groffen
Gentoo on a different level
--
[hidden email] mailing list

Reply | Threaded
Open this post in threaded view
|

Re: [PREFIX] linker_XXX?

Michael Haubenwallner
On Tue, 2007-06-12 at 11:27 +0200, Fabian Groffen wrote:

> I've hit this thought a few times now, but every time hacked around it
> with assumptions.  However, maybe it is a good idea to make the linker
> (and perhaps also the compiler?) visible from ebuilds?  Many "Darwin"
> patches are linker patches.
>
> I was thinking of things like
>
> linker_GNU
> linker_Darwin
> linker_Solaris
>
> or?
>
> [[ ${LINKER} == binutils-2.17* ]]
> [[ ${LINKER} == odcctools* ]]
>
> or any other mix inbetween?  Does it make sense to anyone?  Thoughts?

What about having some intelligent functions in toolchain-funcs.eclass ?

Because when GNU ld once works on platforms it does currently not, we
might want to switch...

I'm thinking of somewhat like that:

tc-have-soname() {
    if [[ $($($(tc-getCC) -print-prog-name=ld) --version 2>/dev/null) == *GNU* ]]; then
        # ld used by CC is GNU ld, thus we have -soname
        return 0      
    fi
    case "${CHOST}" in
    *-hpux*) return 0 ;; # assume ldwrapper maps -soname to +h
    esac
    return 1
}

and/or eventually:

tc-soname() {
    if [[ $($(tc-getCC) -print-prog-name=ld) --version 2>/dev/null) == *GNU* ]]; then
        # ld used by CC is GNU ld, thus we have -soname
        echo "-soname=${1}"
    else
        case "${CHOST}" in
        *-hpux*) echo "+h ${1}" ;; # no mapping of -soname to +h in ldwrapper
        esac
    fi
    true
}
       
/haubi/

--
[hidden email] mailing list

Reply | Threaded
Open this post in threaded view
|

Re: [PREFIX] linker_XXX?

Fabrizio Listello
Some time ago I used a sun-ld keyword for chosing between GNU linker
or Sun Solaris native linker. This can be useful for debugging
pourpose.
I'ld prefer to have somewhere an explicit choice of the linker, if I
can. This can be useful in the future where, for example, one can try
to compile ebuild using Sun Studio Compilers instead of GCC...
Does this make sense?

On 6/13/07, Michael Haubenwallner <[hidden email]> wrote:

> On Tue, 2007-06-12 at 11:27 +0200, Fabian Groffen wrote:
> > I've hit this thought a few times now, but every time hacked around it
> > with assumptions.  However, maybe it is a good idea to make the linker
> > (and perhaps also the compiler?) visible from ebuilds?  Many "Darwin"
> > patches are linker patches.
> >
> > I was thinking of things like
> >
> > linker_GNU
> > linker_Darwin
> > linker_Solaris
> >
> > or?
> >
> > [[ ${LINKER} == binutils-2.17* ]]
> > [[ ${LINKER} == odcctools* ]]
> >
> > or any other mix inbetween?  Does it make sense to anyone?  Thoughts?
>
> What about having some intelligent functions in toolchain-funcs.eclass ?
>
> Because when GNU ld once works on platforms it does currently not, we
> might want to switch...
>
> I'm thinking of somewhat like that:
>
> tc-have-soname() {
>     if [[ $($($(tc-getCC) -print-prog-name=ld) --version 2>/dev/null) == *GNU* ]]; then
>         # ld used by CC is GNU ld, thus we have -soname
>         return 0
>     fi
>     case "${CHOST}" in
>     *-hpux*) return 0 ;; # assume ldwrapper maps -soname to +h
>     esac
>     return 1
> }
>
> and/or eventually:
>
> tc-soname() {
>     if [[ $($(tc-getCC) -print-prog-name=ld) --version 2>/dev/null) == *GNU* ]]; then
>         # ld used by CC is GNU ld, thus we have -soname
>         echo "-soname=${1}"
>     else
>         case "${CHOST}" in
>         *-hpux*) echo "+h ${1}" ;; # no mapping of -soname to +h in ldwrapper
>         esac
>     fi
>     true
> }
>
> /haubi/
>
> --
> [hidden email] mailing list
>
>


--

FList
--
[hidden email] mailing list

Reply | Threaded
Open this post in threaded view
|

Re: [PREFIX] linker_XXX?

Fabian Groffen-2
On 20-06-2007 18:14:55 +0200, Fabrizio Listello wrote:
> Some time ago I used a sun-ld keyword for chosing between GNU linker
> or Sun Solaris native linker. This can be useful for debugging
> pourpose.
> I'ld prefer to have somewhere an explicit choice of the linker, if I
> can. This can be useful in the future where, for example, one can try
> to compile ebuild using Sun Studio Compilers instead of GCC...
> Does this make sense?

To me it does make sense, though it makes me wonder if not we open up a
big can of worms in the possibilities we create we just cannot maintain.
Preferably I make it possibly, but keep it for the experts to use it,
and advertise anything but what we expect to work.

--
Fabian Groffen
Gentoo on a different level

--
[hidden email] mailing list

Reply | Threaded
Open this post in threaded view
|

Re: [PREFIX] linker_XXX?

Michael Haubenwallner
On Wed, 2007-06-20 at 22:25 +0200, Fabian Groffen wrote:

> On 20-06-2007 18:14:55 +0200, Fabrizio Listello wrote:
> > Some time ago I used a sun-ld keyword for chosing between GNU linker
> > or Sun Solaris native linker. This can be useful for debugging
> > pourpose.
> > I'ld prefer to have somewhere an explicit choice of the linker, if I
> > can. This can be useful in the future where, for example, one can try
> > to compile ebuild using Sun Studio Compilers instead of GCC...
> > Does this make sense?
>
> To me it does make sense, though it makes me wonder if not we open up a
> big can of worms in the possibilities we create we just cannot maintain.
> Preferably I make it possibly, but keep it for the experts to use it,
> and advertise anything but what we expect to work.

Agreed.
We might want to allow somewhat-easy switching to a non-default
toolchain (gnu in most cases), but fully support the default one only
because of maintenance issues.

But I'm unsure if USE flags are the right way - maybe use more virtuals
instead (virtual/gcc, virtual/binutils, virtual/libc), and let the
default-virtuals be the supported ones ?

/haubi/

--
[hidden email] mailing list

Reply | Threaded
Open this post in threaded view
|

Re: [PREFIX] linker_XXX?

Fabrizio Listello
On 6/20/07, Michael Haubenwallner <[hidden email]> wrote:

> On Wed, 2007-06-20 at 22:25 +0200, Fabian Groffen wrote:
> > On 20-06-2007 18:14:55 +0200, Fabrizio Listello wrote:
> > > Some time ago I used a sun-ld keyword for chosing between GNU linker
> > > or Sun Solaris native linker. This can be useful for debugging
> > > pourpose.
> > > I'ld prefer to have somewhere an explicit choice of the linker, if I
> > > can. This can be useful in the future where, for example, one can try
> > > to compile ebuild using Sun Studio Compilers instead of GCC...
> > > Does this make sense?
> >
> > To me it does make sense, though it makes me wonder if not we open up a
> > big can of worms in the possibilities we create we just cannot maintain.
> > Preferably I make it possibly, but keep it for the experts to use it,
> > and advertise anything but what we expect to work.
>
> Agreed.
> We might want to allow somewhat-easy switching to a non-default
> toolchain (gnu in most cases), but fully support the default one only
> because of maintenance issues.
>
> But I'm unsure if USE flags are the right way - maybe use more virtuals
> instead (virtual/gcc, virtual/binutils, virtual/libc), and let the
> default-virtuals be the supported ones ?

Doesn't using virtual led us to have the whole packages use the same
toolchain? This is good for supportability, but it's not optimal for
hacking. Maybe I want starting trying to compile single packages with
alternative toolchains (this is not a Capital Sin, IMHO).
Anyway I agree with Fabian that this can lead to a lost of focus.

(I'ld not give to supportability a so high value... sadly, actually we
are 3 people using gentoo-alt/prefix/sunos... and we are all
developing on that...)

>
> /haubi/
>
> --
> [hidden email] mailing list
>
>


--

FList
--
[hidden email] mailing list