First, I did not search yet for issues showing this. It is just a ... "hey, that's seems wrong, anyone knows about this?".
After my "make run/demo" on Linux Ubuntu 64 bits, I got a big black window, that was empty so I closed it.
The log after compilation shows: Program app/launchpad/launchpad COMPILE launcher.o COMPILE launchpad_window.o COMPILE main.o LINK launchpad make[1]: Leaving directory `/home/paul/Bureau/Genode/genode-12.11/build.lx' genode build completed spawn ./core int main(): --- create local services --- int main(): --- start init --- int main(): transferred 79 MB to init int main(): --- init created, waiting for exit condition --- [init] Could not open file "ld.lib.so" [init -> launchpad] Could not open file "ld.lib.so" [init -> launchpad] Could not open file "config" [init -> launchpad] Could not obtain config file ^Cint main(): --- destroying init --- virtual void Genode::Core_parent::close(Genode::Session_capability): implement me, please destroy_server_socket_pair called for IPC server which should never happen context area detach from 0x2fe000 - not implemented int main(): --- core main says good bye --- virtual void Genode::Core_parent::close(Genode::Session_capability): implement me, please virtual void Genode::Core_parent::close(Genode::Session_capability): implement me, please expect: spawn id exp6 not open while executing "expect { -re $wait_for_re { } timeout { puts stderr "Error: Test execution timed out"; exit -2 } }" (procedure "run_genode_until" line 8) invoked from within "run_genode_until forever" (file "/home/paul/Bureau/Genode/genode-12.11/os/run/demo.run" line 129) invoked from within "source $include_name" ("foreach" body line 3) invoked from within "foreach include_name [get_cmd_arg --include ""] { puts "using run script $include_name" source $include_name }" (file "/home/paul/Bureau/Genode/genode-12.11/tool/run" line 508) make: *** [run/demo] Error 1
paul@...162...:~/Bureau/Genode/genode-12.11/build.lx$ paul@...162...:~/Bureau/Genode/genode-12.11/build.lx$ locate ld.lib paul@...162...:~/Bureau/Genode/genode-12.11/build.lx$
Hello,
On 14.01.2013 23:49, Paul Dufresne wrote:
First, I did not search yet for issues showing this. It is just a ... "hey, that's seems wrong, anyone knows about this?".
After my "make run/demo" on Linux Ubuntu 64 bits, I got a big black window, that was empty so I closed it.
if your Ubuntu GCC version is 4.7.x, you need to apply the patch from this bugtracker issue: https://github.com/genodelabs/genode/issues/550
Christian
if your Ubuntu GCC version is 4.7.x, you need to apply the patch from this bugtracker issue: https://github.com/genodelabs/genode/issues/550
Yep, manually applying the patch make the launchpad window to work. Thanks!
That said, I was using the Genode toolchain which is gcc 4.7.2 from: genode-toolchain-12.11-x86_64.tar.bz2 by using "$ export PATH=/usr/local/genode-gcc/bin:$PATH" after extracting it in /
And I was merely following the doc: README suggesting to read doc/getting_started.txt which was suggesting to: ! cd <genode-dir> ! ./tool/create_builddir linux_x86 BUILD_DIR=build.lx
The new build directory is called 'build.lx' and configured for the 'linux_x86' platform. To give Genode a try, build and execute a simple demo scenario via:
! cd build.lx ! make run/demo
I believed that this bug would be encounter by almost every new people using the current version. And that a 12.11.1 new release file should have been put on Sourceforge for people to avoid it.
BTW, I would have liked it to be more clear that I needed to extract the toolchain in / (which seems a bit weird to me, would have expected to put it in the same directory as Genode).
I begin to doubt that the: $ export PATH=/usr/local/genode-gcc/bin:$PATH since the toolchain have it's own name: genode-x86-g++ genode-x86-gcc
Also, notre that the : [init] Could not open file "ld.lib.so" is still there in the now working version: spawn ./core int main(): --- create local services --- int main(): --- start init --- int main(): transferred 79 MB to init int main(): --- init created, waiting for exit condition --- [init] Could not open file "ld.lib.so" [init -> launchpad] Could not open file "ld.lib.so" [init -> launchpad] Could not open file "config" [init -> launchpad] Could not obtain config file [init -> fb_sdl] creating virtual framebuffer for mode 1024x768@...64... [init -> nitpicker] framebuffer is 1024x768@...23... [init -> nitpicker] create session with args: fb_format=1, label="launchpad", ram_quota=1646592 [init -> nitpicker] Could not open file "config" [init -> nitpicker] Could not obtain config file [init -> nitpicker] create session with args: fb_width=400, fb_height=1504, fb_format=1, label="launchpad", ram_quota=1211392 [init -> launchpad] --- entering main loop --- [init -> launchpad] starting liquid_fb with quota 7340032 [init -> launchpad] using unique child name "liquid_fb" [init -> launchpad -> liquid_fb] Could not open file "config" [init -> launchpad -> liquid_fb] Could not obtain config file
Hi Paul,
welcome to the list and thanks for the valuable feedback!
if your Ubuntu GCC version is 4.7.x, you need to apply the patch from this bugtracker issue: https://github.com/genodelabs/genode/issues/550
Yep, manually applying the patch make the launchpad window to work. Thanks!
That said, I was using the Genode toolchain which is gcc 4.7.2 from: genode-toolchain-12.11-x86_64.tar.bz2 by using "$ export PATH=/usr/local/genode-gcc/bin:$PATH" after extracting it in /
And I was merely following the doc: README suggesting to read doc/getting_started.txt which was suggesting to: ! cd <genode-dir> ! ./tool/create_builddir linux_x86 BUILD_DIR=build.lx
The new build directory is called 'build.lx' and configured for the 'linux_x86' platform. To give Genode a try, build and execute a simple demo scenario via:
! cd build.lx ! make run/demo
I believed that this bug would be encounter by almost every new people using the current version. And that a 12.11.1 new release file should have been put on Sourceforge for people to avoid it.
It is unfortunate that this issue was resolved just after the release. For each release, we test Genode on various Linux systems, but apparently, none of the regular developers and testers had switched to the just released Ubuntu version at that time.
We haven't backported bug fixes to release snapshots, yet. So I'm a bit hesitant to start doing this.
As far as I know, most people use Genode from the Git repository where this issue is fixed. if you like to engage more with Genode, I'd highly recommend you to use the current master branch of Genode instead of a downloaded tarball:
https://github.com/genodelabs/genode/
Maybe we should make this point more clear in the documentation?
BTW, I would have liked it to be more clear that I needed to extract the toolchain in / (which seems a bit weird to me, would have expected to put it in the same directory as Genode).
That's a good point. I have slightly changed the paragraph about installing the prebuilt tool chain:
https://github.com/genodelabs/genode/commit/d27cb94702b7eb9dc623b41555663ef3...
I begin to doubt that the: $ export PATH=/usr/local/genode-gcc/bin:$PATH since the toolchain have it's own name: genode-x86-g++ genode-x86-gcc
Setting the PATH variable is not needed because the build system uses the tool prefix "/usr/local/genode-gcc/bin/genode-x86-" by default. (see 'base/etc/tools.conf'). If you like to place the tool chain somewhere else, the 'CROSS_DEV_PREFIX' can be overridden a local version of a 'tools.conf' file in your '<build-dir>/etc/' directory.
Can you give me the pointer where you picked up the information to add the tool-chain location to your PATH? I'd like to fix that.
Also, notre that the : [init] Could not open file "ld.lib.so" is still there in the now working version:
Even though this looks like an error, it is just a diagnostic message. Because the demo scenario does not use any dynamically linked binaries, a dynamic linker is not needed. So the message is not critical here. I agree that it would be nice to not print the message in this case. However, at the point where init prints the message, it does not yet know, whether or not there is any dynamically linked binary present. So it cannot decide about suppressing the message. Sorry for the confusion. If you have a good idea how to deal with it in a better way, this would be welcome. :-)
Cheers Norman
he he, I wish I would have read tool_chain.txt before.
I was merely following instructions in getting_started.txt that is not very clear: "Furthermore, you will need to install the official Genode toolchain, which you can download at [http://genode.org/download/tool-chain]." That's probably where I would add a comment to read tool_chain.txt (probably replacing the link).
So I was quite a bit on my own on how to install it. When I open it in preview I saw it was like a root, so I tried to extract it on /. But I was not remembering what was the bzip2 flag to use rather than the slightly more usual gzip one. I finally did a 'sudo file-roller'. I then did add the PATH merely because I tought it was a new gcc that was overriding the system one by being in the PATH. It was not something I did read.
Would it be possible to replace (or add) the too terse readme in http://sourceforge.net/projects/genode/files/genode-toolchain/ by an extract of/or tool_chain.txt?
Hi Paul,
he he, I wish I would have read tool_chain.txt before.
this is actually the text as found at our website (the website is generated from the text files found in the genode repository:
http://genode.org/download/tool-chain
I was merely following instructions in getting_started.txt that is not very clear: "Furthermore, you will need to install the official Genode toolchain, which you can download at [http://genode.org/download/tool-chain]." That's probably where I would add a comment to read tool_chain.txt (probably replacing the link).
See above. ;-)
So I was quite a bit on my own on how to install it. When I open it in preview I saw it was like a root, so I tried to extract it on /. But I was not remembering what was the bzip2 flag to use rather than the slightly more usual gzip one. I finally did a 'sudo file-roller'. I then did add the PATH merely because I tought it was a new gcc that was overriding the system one by being in the PATH. It was not something I did read.
Would it be possible to replace (or add) the too terse readme in http://sourceforge.net/projects/genode/files/genode-toolchain/ by an extract of/or tool_chain.txt?
I think the best would be to just provide a link to http://genode.org/download/tool-chain. Otherwise, we would need to remember keeping those texts consistent in the future. I just changed the readme text at the sourceforge download page accordingly:
https://sourceforge.net/projects/genode/files/genode-toolchain/12.11/
Cheers Norman