<fray>
tlwoerner: well at least for my AMD/Xilinx use-case, no adverse effects..
Thorn has quit [Ping timeout: 255 seconds]
<tlwoerner>
fray: great! thank you
<fray>
(we've got a funky qemu fork, it starts a multi-process QEMU that combined emulate the system as whole. For ZynqMP it needs to emulate a microblaze system and a cortex-a system.... we've got other CPUs that may have multiple microblazes...etc
<fray>
so all of that requires a custom runqemu helper, but we've got everything working through the standard runqemu interface (for the most part)
<fray>
the thing that is really funky thought, it uses shared disk file(s) as the system memory.. both processes mmap the files to where they would look like on the actual SoC.. upside works really well, downside.. when you have 16 GB of DDR, you need a 16 GB mmap'd file.. :P
<fray>
and the files have an overall path limit, so effectively they HAVE to be in /tmp, and we've seen some IT departments seem to limit the size of /tmp to the point that there ay not be enough room.. :|
sakoman has joined #yocto
jclsn has quit [Ping timeout: 246 seconds]
jclsn has joined #yocto
zkrx has quit [Ping timeout: 255 seconds]
linkpan has quit [Quit: Client closed]
zkrx has joined #yocto
invalidopcode1 has quit [Remote host closed the connection]
invalidopcode1 has joined #yocto
camus has quit [Remote host closed the connection]
camus has joined #yocto
rfs613 has quit [Ping timeout: 252 seconds]
rfs613 has joined #yocto
old_guy has joined #yocto
Estrella has joined #yocto
<old_guy>
ERROR: Nothing RPROVIDES 'gcc-symlinks' (but /abc/meta/recipes-devtools/elfutils/elfutils_0.186.bb RDEPENDS on or otherwise requires it)
<old_guy>
gcc RPROVIDES gcc-symlinks but was skipped: it has incompatible license(s): GPL-3.0-only
<Marian>
I'm trying to build a separate archive with additional packages that will be used at runtime to add additional functionality.
<Marian>
For example, the basic sysroot will not contain he following: gdb, top, lsof, etc.
<Marian>
But this additional IMAGE will contain them and if we need them, we can extract them.
<Marian>
The problem that I have is that Yocto will add in this image all dependencies like glibc, openssl, ssl, etc beside of what we I need gdb, top, lsof etc
<Marian>
I need to have this archive as small as posible.
<Marian>
I tried to remove them with the bellow without any luck:
<Marian>
I tried to look on the bitbake -e output, but I didn't find something that it will help.
<fray>
Do you want two images, or just a package of the differences?
<Marian>
I already have the sysroot package
<Marian>
I need an additional package that will contain only what the features needs and are not in the sysroot package
<fray>
The normal way this is done in the YP is you define different full images..
<Marian>
This is what I did
<Marian>
and I have the sysroot and devtools
<fray>
there (afaik) isn't a standard way to do a 'difference', but I know people who have done this outside of the YP by comparing the tarballs for the two images and only packaging the differences
<Marian>
in devtools I add gdb
<Marian>
and I see that I have the glibc libraries
<fray>
Yes, you will always get dependencies
<fray>
If gdb reuqires libc, it will install libc
<Marian>
Yes, the question is how can I get only what I don't have in a provided Image
<Marian>
or, I can specify what libraries to not include, usually the problem is with openssl, ssl and glibc
<fray>
there is no standard way, that I know of. You need to do it externally..
<fray>
Easiest way is to build two images. One with your minimum set, one with the additional items. Make sure they both output "tar.gz" (or equivalent). Then external, extract them both, and diff them.. Then create a new tar.gz (or equivalent) with just the differences
<fray>
there is an inbuilt system to allow for a special development filesystem (overlay) for debugging (adding symbol files) and that is essential what it does, but it's automated
<Marian>
It's any way to do that from a bitbake step of the "additional items" reciepe
<Marian>
?
<fray>
no
<fray>
(well not that I know of)
alessioigor has quit [Quit: alessioigor]
<Marian>
Thank you very much for the help, I will try to do it externally
<geoffhp>
You see to set up a package feed website to host your packages from a build system and setup your packaging tool on the target to point to your build host containing the pacakge files. We do this to to create a packagegroup-debug.bb recipe that adds tools like gdb and strace to a target system
<geoffhp>
For example wit an ipkg system. You would run 'opkg update ; opkg install packagegroup-debug' to install all the debug tools and dependencies in one go from the opkg server you have set up.