On Fri, Jul 31, 2020 at 8:35 AM Ryan Harkin wrote:
>
> Hello,
>
> I'm migrating from Warrior to Dunfell and I'm getting a curious build failure
> in gcc-sanitizers.
>
> Here's the full gory detail:
> https://pastebin.ubuntu.com/p/nh4cDKMvgS/
>
> However, the main error is this:
>
> | In file
Hello,
I'm migrating from Warrior to Dunfell and I'm getting a curious build
failure in gcc-sanitizers.
Here's the full gory detail:
https://pastebin.ubuntu.com/p/nh4cDKMvgS/
However, the main error is this:
| In file included from
../../../../../../../../../work-shared/gcc-arm-8.3-r2019.03
Hello,
thanks for the reply and the useful hints concerning our questions!
After a debug session, it came out, that the *.a archive doesn't contain only
*.o files, but also one *.c file.
That was missed during the first analysis.
Interestingly enough, the error came out only with the Dunfell Up
On 7/21/20 3:45 AM, Jan Hannig wrote:
Hello,
with the upgrade from Yocto Zeus → Dunfell, we observe lots of messages
when building our product which seem heavy to be understood or to debug.
Actually, it's the failure of the "do_package" task of a proprietary
module written in C with follow
Hello,
with the upgrade from Yocto Zeus → Dunfell, we observe lots of messages when
building our product which seem heavy to be understood or to debug.
Actually, it's the failure of the "do_package" task of a proprietary module
written in C with following message:
ERROR: eds-1.0-r0 do_pack
0 at 8:08 PM Joshua Watt
> wrote:
> >>> > > >
> >>> > > > On Tue, Jun 30, 2020 at 4:56 PM MikeB
> wrote:
> >>> > > > >
> >>> > > > > I recently tried upgrading from 3.1.0 to 3.1.1. I'm not sure
>
30, 2020 at 4:56 PM MikeB wrote:
>>> > > > >
>>> > > > > I recently tried upgrading from 3.1.0 to 3.1.1. I'm not sure if
>>> > > > > this is a bug or just my problem. I maintain five different
>>> > > > &g
PM Joshua Watt
>> wrote:
>> > > >
>> > > > On Tue, Jun 30, 2020 at 4:56 PM MikeB wrote:
>> > > > >
>> > > > > I recently tried upgrading from 3.1.0 to 3.1.1. I'm not sure if
>> this is a bug or just my problem. I main
ikeB wrote:
> > > > >
> > > > > I recently tried upgrading from 3.1.0 to 3.1.1. I'm not sure if
> this is a bug or just my problem. I maintain five different architectures
> and all five have the same failure in gcc-sanitizers as I'm trying to buil
gt; > >
> > > > I recently tried upgrading from 3.1.0 to 3.1.1. I'm not sure if this
> > > > is a bug or just my problem. I maintain five different architectures
> > > > and all five have the same failure in gcc-sanitizers as I'm trying to
t; > a bug or just my problem. I maintain five different architectures and
> > > all five have the same failure in gcc-sanitizers as I'm trying to build
> > > the SDK.
> > >
> > > | cat:
> > > /data/mabnhdev/exos-yocto-dunfell/buil
> five have the same failure in gcc-sanitizers as I'm trying to build the SDK.
> >
> > | cat:
> > /data/mabnhdev/exos-yocto-dunfell/build/exos-arm64/tmp/work-shared/gcc-9.3.0-r0/gcc-9.3.0/gcc/defaults.h:
> > No such file or directory
> > | WARNING:
> &
ild the SDK.
>
> | cat:
> /data/mabnhdev/exos-yocto-dunfell/build/exos-arm64/tmp/work-shared/gcc-9.3.0-r0/gcc-9.3.0/gcc/defaults.h:
> No such file or directory
> | WARNING:
> /data/mabnhdev/exos-yocto-dunfell/build/exos-arm64/tmp/work/aarch64-poky-linux/gcc-sanitizers/9.3.0-r0/temp
nhdev/exos-yocto-dunfell/build/exos-arm64/tmp/work-shared/gcc-9.3.0-r0/gcc-9.3.0/gcc/defaults.h:
No such file or directory
| WARNING:
/data/mabnhdev/exos-yocto-dunfell/build/exos-arm64/tmp/work/aarch64-poky-linux/gcc-sanitizers/9.3.0-r0/temp/run.do_configure.31505:1
exit 1 from 'grep -v "\#e
I recently tried upgrading from 3.1.0 to 3.1.1. I'm not sure if this is a bug
or just my problem. I maintain five different architectures and all five have
the same failure in gcc-sanitizers as I'm trying to build the SDK.
| cat:
/data/mabnhdev/exos-yocto-dunfell/build/exos-arm6
Removing the libnsl2 dependency worked for tcp-wrappers, but a similar
situation arose with python3. In the case of python3, removing libnsl2
dependency caused other failures in the build.
However, reading some comments in util-linux/mount.c, the
CONFIG_FEATURE_MOUNT_NFS
seems to only apply to ke
On Saturday, June 13, 2020 4:06:59 PM PDT MikeB wrote:
> I'm trying to build busybox on Dunfell with NFS mount configured
> (CONFIG_FEATURE_MOUNT_NFS). The build fails with the following.
> | util-linux/mount.c:253:11: fatal error: rpc/rpc.h: No such file or
> | directory|
> | 253 | # include
>
I'm trying to build busybox on Dunfell with NFS mount configured
(CONFIG_FEATURE_MOUNT_NFS). The build fails with the following.
| util-linux/mount.c:253:11: fatal error: rpc/rpc.h: No such file or directory
| 253 | # include
Reading online, later versions of glibc no longer install rpc head
Hi, folks.
I'm getting the error below in several packages. Some of then I could fix when
the recipe "do_intall"
has commands like:
"cp -a "
How can I solve this error when the recipe has no "cp" ? What else can cause
this issue ?
Thanks in advance...
WARNING: firefox-38.3.0esr-r0 do_pack
Hi, all.
I created the recipe for grpc package with:
recipetool create "npm://registry.npmjs.org/;package=grpc;version=latest"
The build fails with the error ENOTCACHED.
I could build several other NPM package with the same process in the same build
environment.
Any help on this issue will be
Hi Edson,
You're right. I have seen seen this too. I have already created a bug
to track this issue:
https://bugzilla.yoctoproject.org/show_bug.cgi?id=13901
For now, as a workaround, you can just delete the npmsw:// line in
the generated recipe (and the shrinkwrap file).
Best Regards,
Jean-Mari
Hi, all
I used recipetool to create the recipe for NPM packages
If the npm package has dependence(s) it works great.
But if not, the error below happens.
I just add a fake dependence in npm-shrinkwrap.json then it works
# cat google-protobuf/npm-shrinkwrap.json
{
"name": "google-protobuf",
101 - 122 of 122 matches
Mail list logo
