[RSB] port graphic libraries into rsb
QIAO YANG
yangqiao0505 at me.com
Sat Jul 25 13:54:53 UTC 2015
Hi Pavel Pisa,
I've fixed the leak. Please checkout my github.
https://github.com/yangqiao/rtems-source-builder/tree/graphics
Best wishes
On Jul 21, 2015, at 09:51 PM, Pavel Pisa <pisa at cmp.felk.cvut.cz> wrote:
> Hello Qiao Yang
>
> On Tuesday 21 of July 2015 14:21:07 QIAO YANG wrote:
>> Hi Pavel Pisa,
>>
>> On Jul 19, 2015, at 10:35 PM, Pavel Pisa <pisa at cmp.felk.cvut.cz> wrote:
>> > Hello Chris and Qiao Yang,
>> >
>> > On Monday 20 of July 2015 01:12:33 Chris Johns wrote:
>> >> On 20/07/2015 6:55 am, QIAO YANG wrote:
>> >> > I've ported the graphic libraries into rsb so that we can build them
>> >> > much easier. All Build passed, tested on arm with raspberrypi and i386
>> >> > with pc386.
>> >>
>> >> Fantastic and thank you.
> ....
>> >
>> > I use system wide prefix for my RTEMS install. When I specified that
>> >
>> > --prefix=/opt/rtems4.11
>> >
>> > When I specified that to sb-set-builder then it silently skips install
>> > steps. This leads not only to problem that I have not received resulting
>> > binaries (even not found them in temporary RSB trees) but even build of
>> > later packages dependant on previous ones failed.
>> >
>> > I resolved that by use of RSB option
>> >
>> > --pkg-tar-files
>> >
>> > tar files has been generated and I could extract content to the right
>> > directory and continue build with followup with sucesfull Microwindows
>> > package build. I have been able to use that (after tar extraction)
>> > to build and run my graphic application in QEMU then.
>>
>> So the library works if I've got it right. No problem with the build
>> process.
>
> The libraries are configured properly. Only thing to solve for you
> is to find way how to limit all/as most as possible files installed
> in improper directories. It is not fatal but can make troubles
> and is misleading. Look for packages options --disable-test, samples
> and some related options to direct install of support files to BSP
> specific directories. Documentation can go to RTEMS prefix and shared
> area. But includes, libraries, binaries and configs should not.
>
>
> The other issues are for discussion with Chris Johns
> and he woks on these. So rebase of your work onto
> his newer RSB versions should help.
>
> I have some more things for Microwindows. It seems that
> Microwindows mainline (https://github.com/ghaerr/microwindows)
> moves forward (commits by georgp24).
>
> You are using alex-sever-h fork. I do not expect that he returns
> to the project. We should consolidate code. I have his changes
> in my fork. Some of these are not appropriate for mainline
> some needs cheanup. But we should move closer to mainline.
> As I find time, I try to prepare branch with changes suitable
> for mainline. I would like to change Microwindows RTEMS config
> and makefiles such way that NOKBD and NOMOUSE can be selected
> for RTEMS by config. Same for some screen variants.
>
> So the patches removing keyboard and mouse in Makefiles would
> not be required. All things should be controlled by config.
>
>> > Because libraries build is specific than I expect that all build
>> > results should be installed in BSP directory, i.e.
>> > /opt/rtems4.11/i386-rtems4.11/pc686/{lib,bin,lib/include} in my case.
>> > It seems that JPEG library is configured right. But there are significant
>> > leakages from freetype, libpng, t1lib and libtiff to
>> > "/opt/rtems4.11/bin" and "/opt/rtems4.11/share" directories.
>> > t1lib even installs to /share/t1lib directly.
>>
>> Do you mean that the libraries are not installed in the bsp dir?
>
> Yes and no, libraries required to build RTEMS applications are installed
> in the right place but there is significant level of noise - tools,
> scripts etc installed in inappropriate places.
>
> Add --pkg-tar-files RSB option and then you can easily see what
> is content of each installed package - I hope, that it is 1:1 to what
> is really installed/copied to the filesystem.
>
>> In fact,
>> I've got all libraries installed in the right place. Firstly, I doubt if
>> the bsp pc686 exists in arch i386. I can only find pc386 in mainline. Make
>> sure that the bsp name is correct. Secondly, verify the path you passed is
>> what the builder expects as chris explained. I haven't found out why the
>> JPEG works while others can't, but I do use the paths to determin where to
>> install.
>
> RTEMS supports boards variants. This means that there are more boards
> supported than only these seen as individual subdirectory of each
> CPU architecture (these subdirectories are more or less equivalent to
> machine or platform on Linux). The varinats usually differ in the compiler
> flags and some defines which control source builds.
>
> See
>
> rtems/c/src/lib/libbsp/i386/pc386/make/custom
>
> There are varinats
> edison.cfg pc386.cfg pc486.cfg pc586.cfg pc586-sse.cfg
> pc686.cfg pcp4.cfg
>
> where pc686.cfg includes common pc386.cfg base but selects
> pentium generation corresponding optimization
> CPU_CFLAGS = -mtune=pentiumpro
>
> and variant name for RTEMS
> RTEMS_CPU_MODEL=pentiumpro
>
>> I followed alan's blog to setup my environment.
>>
>> alias i386-kernel-configuer='cd $HOME/development/rtems-386/rtems-git/; \
>> ./bootstrap; \
>> mkdir $HOME/development/rtems-386/build-rtems-386/; \
>> cd $HOME/development/rtems-386/build-rtems-386/; \
>> ../rtems-git/configure --target=i386-rtems4.11 \
>> --enable-rtemsbsp=pc386 \
>> --enable-tests=samples \
>> --enable-networking \
>> --enable-posix \
>> --prefix=$HOME/development/rtems-386/bsps/4.11'
>>
>> So in my case I've got a directory 'build-rtems-386' and a directory 'bsp'
>> . What I passed to sb-set-builder is the directory:
>> --prefix=$HOME/development/rtems-386/bsps/4.11, the same path used for
>> kernel configure.
>>
>> The libraries should be finally installed into directories
>> $HOME/development/rtems-386/bsps/4.11/pc386/lib
>> $HOME/development/rtems-386/bsps/4.11/pc386/lib/include
>> $HOME/development/rtems-386/bsps/4.11/pc386/bin
>>
>> I hope this may help. Tell me if I misunderstood anything.
>
> Great to document for others but there should not be and most
> probably is not difference for my setup. So I think that
> you should see utils spread to the same places as I have noticed.
>
> Best wishes,
>
> Pavel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20150725/67af9af1/attachment-0002.html>
More information about the devel
mailing list