Re: [OE-core] [PATCH 1/2] tune-riscv: Add support for hard and soft float
On Sat, 2019-11-09 at 22:30 +0200, Adrian Bunk wrote: > On Fri, Nov 08, 2019 at 11:07:04PM +, Richard Purdie wrote: > > On Fri, 2019-11-08 at 22:24 +0200, Adrian Bunk wrote: > > > Especially when looking at the arm64 situation I am wondering > > > whether the best option might be to throw away the tunes mess and > > > let > > > the user write the compiler options directly. > > > > OE once did that. I think anyone who lived through it would say > > that > > the current situation *is* an improvement over a free-for-all. > > > > This is mainly as at least we're now consistent whereas before the > > same > > thing had different names in each BSP. > > The BSPs should not invent names for anything, all a BSP should do > would be to set some kind of > TARGET_CFLAGS += "-mcpu=cortex-a53+crc+crypto+sm4+nosimd" What is the name of the package feed these binaries would go into? > > I don't know what the answer is but I don't want to go back to > > that! > > As of gcc 9 there are for arm64[1]: > > 6 -march= architecture levels (8.0 to 8.5) > 35 -mtune= tune options > 22 modifiers for -march= and -mtune= > 3 different ABIs (aarch64, aarch64-ilp32, armv7) > > Even ignoring the tunes you already have > 6 * 2^22 > different architecture+modifier combinations. > > Not all combinations are valid, but another can of worms are the > definitions what is valid and what is default amd what gets > indirectly > enabled, e.g. > fp16fml > Enable FP16 fmla extension. This also enables FP16 extensions > and > floating-point instructions. This option is enabled by default > for > -march=armv8.4-a. Use of this option with architectures prior to > Armv8.2-A is not supported. > > It can be recursive: > Feature crypto implies aes, sha2, and simd, which implies fp. > Conversely, nofp implies nosimd, which implies nocrypto, noaes and > nosha2. I'd advocate that we add the combinations which people need and use. The tune structure doesn't require every combination be there. Cheers, Richard -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 1/2] tune-riscv: Add support for hard and soft float
On Fri, Nov 08, 2019 at 11:07:04PM +, Richard Purdie wrote: > On Fri, 2019-11-08 at 22:24 +0200, Adrian Bunk wrote: > > Especially when looking at the arm64 situation I am wondering > > whether the best option might be to throw away the tunes mess and let > > the user write the compiler options directly. > > OE once did that. I think anyone who lived through it would say that > the current situation *is* an improvement over a free-for-all. > > This is mainly as at least we're now consistent whereas before the same > thing had different names in each BSP. The BSPs should not invent names for anything, all a BSP should do would be to set some kind of TARGET_CFLAGS += "-mcpu=cortex-a53+crc+crypto+sm4+nosimd" > I don't know what the answer is but I don't want to go back to that! As of gcc 9 there are for arm64[1]: 6 -march= architecture levels (8.0 to 8.5) 35 -mtune= tune options 22 modifiers for -march= and -mtune= 3 different ABIs (aarch64, aarch64-ilp32, armv7) Even ignoring the tunes you already have 6 * 2^22 different architecture+modifier combinations. Not all combinations are valid, but another can of worms are the definitions what is valid and what is default amd what gets indirectly enabled, e.g. fp16fml Enable FP16 fmla extension. This also enables FP16 extensions and floating-point instructions. This option is enabled by default for -march=armv8.4-a. Use of this option with architectures prior to Armv8.2-A is not supported. It can be recursive: Feature crypto implies aes, sha2, and simd, which implies fp. Conversely, nofp implies nosimd, which implies nocrypto, noaes and nosha2. > Cheers, > > Richard cu Adrian [1] https://gcc.gnu.org/onlinedocs/gcc-9.1.0/gcc/AArch64-Options.html -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] pseudo: Drop static linking to sqlite3
On Sat, 09 Nov 2019 16:30:41 + Richard Purdie wrote: > I did talk briefly to Mark (also cc'd) as he wrote the original patch > and he thought it was possibly because the client was also linking > against sqlite3 and due to the other things the client does, that was > problematic. It *shouldn't* link against sqlite3. But! The commit in question refers to RHEL5 and LD_LIBRARY_PATH, and I think that shook loose a memory: I think at one point, we had a Crucial Bug Fix in sqlite3, in our build system, and if we didn't statically link, there was a risk of getting the broken version at runtime. > The client lib doesn't and the server side should behave just like any > other linux binary afaik so we should be ok with a dynamicly linked > sqlite3? Yes. The issue here was, I believe, not "dynamically-linked sqlite3 per se", but "dynamic linking, plus LD_LIBRARY_PATH, picking an sqlite3 which caused us specific problems". In the Yocto environment, I think we're reasonably sure that we always get a clean Yocto-built sqlite3, and that *should* be fine. So I'd say go for it, but if you see weird sqlite3 stuff that happens only very occasionally, look at this first. :P -s -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] pseudo: Drop static linking to sqlite3
On Sat, 2019-11-09 at 10:07 -0600, Seebs wrote: > On Sat, 9 Nov 2019 15:35:59 + > Richard Purdie wrote: > > > Back in 2010[1] we made pseudo statically link against sqlite3. > > Since then the world has changed, pseudo now has separate processes > > for the database in the server and the client and they have > > separate linking commands. > > I'm not sure what that has to do with the reasons for it being > static? Not that I remember exactly anymore, but I think we were > hitting problems caused if pseudo was dynamically linked to sqlite, > but I don't remember what they were. I did talk briefly to Mark (also cc'd) as he wrote the original patch and he thought it was possibly because the client was also linking against sqlite3 and due to the other things the client does, that was problematic. > I'm not entirely sure I know what you mean by "separate processes for > the database in the server and the client". I don't think > libpseudo.so should ever do any database things at all, and it > shouldn't need to link to sqlite. I was under the impression the client may once have linked against it. I admit I didn't dive into history, just checked that it clearly doesn't now. > > which occurs if sqlite3-native was built on a machine with glibc > > 2.28 or later and pseudo-native is being built on glibc before > > that. > > I don't think pseudo's ever been *expected* to work when built linked > against things built against different libc. It is *way* too full of > unholy magics that depend on knowing which libc it's using. That > said, the pseudo server also shouldn't really need to be statically- > linked, the only times it ever runs under pseudo, it just immediately > tries to escape and not run that way. The client lib doesn't and the server side should behave just like any other linux binary afaik so we should be ok with a dynamicly linked sqlite3? > > There appears to be no easy way to avoid this other than adding a > > copy of sqlite3 into the pseudo recipe. Given the static linking > > doesn't seem to be required any longer due to the separate > > processes, > > drop that to fix those issues. > > I don't understand the "separate processes" thing. So far as I know, > pseudo has never talked to sqlite from the client. I think Jason > Wessel had experimental patches at one point to do client-local > sqlite work to avoid the IPC overhead, but I don't think it ever got > merged because it turns out the IPC overhead is insignificant > compared to everything else. If I'm working off incorrect assumptions, is there another reason we need a static sqlite? I have tested this patch before I posted it and it seems fine in our test builds... Cheers, Richard -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] pseudo: Drop static linking to sqlite3
On Sat, 9 Nov 2019 15:35:59 + Richard Purdie wrote: > Back in 2010[1] we made pseudo statically link against sqlite3. Since > then the world has changed, pseudo now has separate processes for the > database in the server and the client and they have separate linking > commands. I'm not sure what that has to do with the reasons for it being static? Not that I remember exactly anymore, but I think we were hitting problems caused if pseudo was dynamically linked to sqlite, but I don't remember what they were. I'm not entirely sure I know what you mean by "separate processes for the database in the server and the client". I don't think libpseudo.so should ever do any database things at all, and it shouldn't need to link to sqlite. > which occurs if sqlite3-native was built on a machine with glibc 2.28 > or later and pseudo-native is being built on glibc before that. I don't think pseudo's ever been *expected* to work when built linked against things built against different libc. It is *way* too full of unholy magics that depend on knowing which libc it's using. That said, the pseudo server also shouldn't really need to be statically-linked, the only times it ever runs under pseudo, it just immediately tries to escape and not run that way. > There appears to be no easy way to avoid this other than adding a > copy of sqlite3 into the pseudo recipe. Given the static linking > doesn't seem to be required any longer due to the separate processes, > drop that to fix those issues. I don't understand the "separate processes" thing. So far as I know, pseudo has never talked to sqlite from the client. I think Jason Wessel had experimental patches at one point to do client-local sqlite work to avoid the IPC overhead, but I don't think it ever got merged because it turns out the IPC overhead is insignificant compared to everything else. -s -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH v6] mesa: Upgrade to 19.2.1
On Sat, 9 Nov 2019 at 00:02, Alistair Francis wrote: > > right this means glx-tls is not working anymore, and it will fail on > > musl at runtime > > see > > https://gitlab.freedesktop.org/mesa/mesa/issues/966 > > So what do we do here? > > There are some patches in that issue, but they don't cleanly apply and > seem hacky anyway. Can we have two versions of mesa? One for musl and > one for others until this is fixed upstream? > Maybe we can silence the warning for musl only, via INSANE_SKIP_..._libc-musl = "textrel"? ffmpeg does the same already. Alex -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] pseudo: Drop static linking to sqlite3
Back in 2010[1] we made pseudo statically link against sqlite3. Since then the world has changed, pseudo now has separate processes for the database in the server and the client and they have separate linking commands. [1] http://git.yoctoproject.org/cgit.cgi/poky/commit/?id=ad0ac0ecd38fc77daf42485489fccc10a5e1e3e7 The static sqlite3-native is causing us problems, in particular: tmp/work/x86_64-linux/pseudo-native/1.9.0+gitAUTOINC+060058bb29-r0/recipe-sysroot-native/usr/lib/libsqlite3.a(sqlite3.o):(.data.rel+0xb0): undefined reference to `fcntl64' which occurs if sqlite3-native was built on a machine with glibc 2.28 or later and pseudo-native is being built on glibc before that. With dyanmical linking, libc is backwards compatible and works but with static linking it does not. There appears to be no easy way to avoid this other than adding a copy of sqlite3 into the pseudo recipe. Given the static linking doesn't seem to be required any longer due to the separate processes, drop that to fix those issues. Signed-off-by: Richard Purdie --- meta/conf/distro/include/no-static-libs.inc | 4 meta/recipes-devtools/pseudo/pseudo.inc | 17 ++--- 2 files changed, 2 insertions(+), 19 deletions(-) diff --git a/meta/conf/distro/include/no-static-libs.inc b/meta/conf/distro/include/no-static-libs.inc index 4141ecb7654..a3a865cac45 100644 --- a/meta/conf/distro/include/no-static-libs.inc +++ b/meta/conf/distro/include/no-static-libs.inc @@ -15,10 +15,6 @@ DISABLE_STATIC_pn-nativesdk-libcap = "" DISABLE_STATIC_pn-libpcap = "" # needed by gdb DISABLE_STATIC_pn-readline = "" -# needed by pseudo -DISABLE_STATIC_pn-sqlite3 = "" -DISABLE_STATIC_pn-sqlite3-native = "" -DISABLE_STATIC_pn-nativesdk-sqlite3 = "" # openjade/sgml-common have build issues without static libs DISABLE_STATIC_pn-sgml-common-native = "" DISABLE_STATIC_pn-openjade-native = "" diff --git a/meta/recipes-devtools/pseudo/pseudo.inc b/meta/recipes-devtools/pseudo/pseudo.inc index 8b349097263..7ff8e449e9a 100644 --- a/meta/recipes-devtools/pseudo/pseudo.inc +++ b/meta/recipes-devtools/pseudo/pseudo.inc @@ -30,23 +30,10 @@ PSEUDO_EXTRA_OPTS ?= "--enable-force-async --without-passwd-fallback --enable-ep # Compile for the local machine arch... do_compile () { -SQLITE_LDADD='$(SQLITE)/$(SQLITE_LIB)/libsqlite3.a' - for sqlite_link_opt in $(pkg-config sqlite3 --libs --static) - do - case "$sqlite_link_opt" in - -lsqlite3) - ;; - -l*) - SQLITE_LDADD="${SQLITE_LDADD} ${sqlite_link_opt}" - ;; - *) - ;; - esac - done if [ "${SITEINFO_BITS}" = "64" ]; then - ${S}/configure ${PSEUDO_EXTRA_OPTS} --prefix=${prefix} --libdir=${prefix}/lib/pseudo/lib${SITEINFO_BITS} --with-sqlite-lib=${baselib} --with-sqlite=${STAGING_DIR_TARGET}${exec_prefix} --cflags="${CFLAGS}" --bits=${SITEINFO_BITS} --with-static-sqlite="$SQLITE_LDADD" --without-rpath + ${S}/configure ${PSEUDO_EXTRA_OPTS} --prefix=${prefix} --libdir=${prefix}/lib/pseudo/lib${SITEINFO_BITS} --with-sqlite-lib=${baselib} --with-sqlite=${STAGING_DIR_TARGET}${exec_prefix} --cflags="${CFLAGS}" --bits=${SITEINFO_BITS} --without-rpath else - ${S}/configure ${PSEUDO_EXTRA_OPTS} --prefix=${prefix} --libdir=${prefix}/lib/pseudo/lib --with-sqlite-lib=${baselib} --with-sqlite=${STAGING_DIR_TARGET}${exec_prefix} --cflags="${CFLAGS}" --bits=${SITEINFO_BITS} --with-static-sqlite="$SQLITE_LDADD" --without-rpath + ${S}/configure ${PSEUDO_EXTRA_OPTS} --prefix=${prefix} --libdir=${prefix}/lib/pseudo/lib --with-sqlite-lib=${baselib} --with-sqlite=${STAGING_DIR_TARGET}${exec_prefix} --cflags="${CFLAGS}" --bits=${SITEINFO_BITS} --without-rpath fi oe_runmake ${MAKEOPTS} } -- 2.20.1 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core