On Wed, Jul 14, 2021 at 03:40:03PM +0200, Alexander Kanavin wrote:
> On Wed, 14 Jul 2021 at 14:55, Richard Purdie <
> richard.pur...@linuxfoundation.org> wrote:
> 
> > At the very least the GCC variable is well used in other layers as it is
> > hard to
> > remember all the different bits of gcc that are listed here so I think
> > that
> > should stay. Some of these can probably be removed but I'm not sure how far
> > we could/should go. glibc's list of recipes isn't trivial either...
> >
> 
> I used layerindex to check. Alternative gcc versions are provided by
> multiple layers (mostly arm-related), but an alternative older glibc is
> only in meta-debian and that is using neither PREFERRED_VERSION directly
> nor the *LIBCVERSION convenience (so not sure how it's meant to be used). I
> will send a v2 with gcc added back.

Reusing those variables is common in layers dealing with multiple toolchains, 
such as external binary toolchains and such. Might be good to keep them in 
OE-Core for consistency:

GCCVERSION ?= "9.%"
SDKGCCVERSION ?= "${GCCVERSION}"
BINUVERSION ?= "2.34%"
GDBVERSION ?= "9.%"
GLIBCVERSION ?= "2.31%"
LINUXLIBCVERSION ?= "5.4%"


> Anyone else should probably just copy the PREFERRED_VERSION lines for what
> they want to adjust into the layers directly. But let's see what Khem says
> - I do think getting help from AUH/devtool in doing the updates fully, or
> at least using 'devtool upgrade' locally to prepare the git trees for
> manual patch rebasing is valuable.
> 
> Alex

-- 
Regards,
Denys Dmytriyenko <de...@denix.org>
PGP: 0x420902729A92C964 - https://denix.org/0x420902729A92C964
Fingerprint: 25FC E4A5 8A72 2F69 1186  6D76 4209 0272 9A92 C964
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#154008): 
https://lists.openembedded.org/g/openembedded-core/message/154008
Mute This Topic: https://lists.openembedded.org/mt/84200116/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Reply via email to