Hey there, I noticed the wiki "latest" links now point to 3.2.0. I haven't seen an announcement for 3.2.0 yet, so perhaps this is all a matter of staging, but the current sel4test manifest points to 3.2.x-compatible tags that don't exist in most of the repos. Just thought I'd mention it as I imagine it's the primary way people acquire new releases. Thanks, Jeff
Hello Jeff, On Mon, 2016-07-18 at 12:59 +1000, Jeff Waugh wrote:
Hey there,
I noticed the wiki "latest" links now point to 3.2.0. I haven't seen an announcement for 3.2.0 yet, so perhaps this is all a matter of staging, We usually make an announcement when significant changes/additions are made(for instance, when realtime kernel release[1]). The bump in the version just denotes a change in API/ABI.
but the current sel4test manifest points to 3.2.x-compatible tags that don't exist in most of the repos.
Just thought I'd mention it as I imagine it's the primary way people acquire new releases. Since we don't announce API/ABI changes(version bumps), our releases are usually monitored by following the Github repo, which has a link to
Sorry about the goof up. I missed out on updating seL4_libs, capdl
and musllibc for 3.2.x. I've fixed this now. Thank you very much for
bringing it to our notice.
the release notes as well[2].
Thanks again!
Cheers,
..Partha
[1] - http://sel4.systems/pipermail/devel/2016-June/000831.html
[2] - https://github.com/seL4/seL4/releases
--
Partha Susarla
On Mon, Jul 18, 2016 at 2:31 PM, Parthasarathi Susarla < Parthasarathi.Susarla@nicta.com.au> wrote:
but the current sel4test manifest points to 3.2.x-compatible tags that don't exist in most of the repos.
Sorry about the goof up. I missed out on updating seL4_libs, capdl and musllibc for 3.2.x. I've fixed this now. Thank you very much for bringing it to our notice.
Beauty, thanks! While doing a fresh build: [libs/libmuslc] building... ln: failed to create symbolic link 'include/bits': File exists /home/jdub/src/sel4test/libs/libmuslc/Makefile:81: recipe for target 'include/bits' failed make[1]: *** [include/bits] Error 1 tools/common/project.mk:306: recipe for target 'libmuslc' failed make: *** [libmuslc] Error 2 Poking around I found: jdub@sel4:~/src/sel4test$ ls ./build/x86/pc99/libmuslc/include/bits -la lrwxrwxrwx 1 jdub jdub 51 Jul 18 15:20 ./build/x86/pc99/libmuslc/include/bits -> /home/jdub/src/sel4test/libs/libmuslc/arch/x86/bits jdub@sel4:~/src/sel4test$ ls libs/libmuslc/arch/x x32/ x86_64/ x86_64_sel4/ Something to do with the ia32 / x86 transition? An x86 -> x32 symlink fixes the build. Thanks, Jeff
On Mon, 2016-07-18 at 15:32 +1000, Jeff Waugh wrote:
While doing a fresh build:
[libs/libmuslc] building... ln: failed to create symbolic link 'include/bits': File exists /home/jdub/src/sel4test/libs/libmuslc/Makefile:81: recipe for target 'include/bits' failed make[1]: *** [include/bits] Error 1 tools/common/project.mk:306: recipe for target 'libmuslc' failed make: *** [libmuslc] Error 2
Poking around I found:
jdub@sel4:~/src/sel4test$ ls ./build/x86/pc99/libmuslc/include/bits -la lrwxrwxrwx 1 jdub jdub 51 Jul 18 15:20 ./build/x86/pc99/libmuslc/include/bits -> /home/jdub/src/sel4test/libs/libmuslc/arch/x86/bits jdub@sel4:~/src/sel4test$ ls libs/libmuslc/arch/x x32/ x86_64/ x86_64_sel4/
Something to do with the ia32 / x86 transition? An x86 -> x32 symlink fixes the build.
That is odd. I tried building for ia32/x86 images, and they did pass without an error. One possible reason could be that a `make clean` didn't clean the artefacts from a previous build. If that isn't the case, can you share your config file, so that I could test it? Although, this error might not show up when cloning and building from scratch. Thanks, ..Partha ________________________________ The information in this e-mail may be confidential and subject to legal professional privilege and/or copyright. National ICT Australia Limited accepts no liability for any damage caused by this email or its attachments.
On Mon, Jul 18, 2016 at 4:20 PM, Parthasarathi Susarla < Parthasarathi.Susarla@nicta.com.au> wrote:
That is odd. I tried building for ia32/x86 images, and they did pass without an error. One possible reason could be that a `make clean` didn't clean the artefacts from a previous build. If that isn't the case, can you share your config file, so that I could test it? Although, this error might not show up when cloning and building from scratch.
It was a fresh clone using ia32_release_xml_defconfig… trying again just in case: $ mkdir sel4test $ cd sel4test $ repo init -u https://github.com/seL4/sel4test-manifest -m 3.2.x.xml $ repo sync $ make ia32_release_xml_defconfig $ make … [GEN_IMAGE] sel4test-driver-image Bah, worked fine. Heisenjerk! If it pops up again, I'll dig further. :-) Thanks, Jeff
participants (2)
-
Jeff Waugh -
Parthasarathi Susarla