Re: [OE-core] [PATCH 1/2] tune-riscv: Add support for hard and soft float

[Richard Purdie]

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

[Adrian Bunk]

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

[Seebs]

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

[Richard Purdie]

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

[Seebs]

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

[Alexander Kanavin]

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

[Richard Purdie]

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