I'm trying to compile the new toolchain using tool/tool_chain x86. However, it gives the following error:
configuring bootstrap gcc... The following languages will be built: c,ada,c++,lto *** This configuration is not supported in the following subdirectories: target-libquadmath gotools target-libgfortran target-libgo target-libffi target-zlib target-libjava target-libobjc target-libgomp target-libcilkrts target-liboffloadmic target-libatomic target-libitm target-libsanitizer target-libmpx target-libssp target-boehm-gc (Any other directories should still work fine.) /home/boris/projects/l2-17.05/build/bootstrap/install/bin/ld: cannot find crt1.o: No such file or directory /home/boris/projects/l2-17.05/build/bootstrap/install/bin/ld: cannot find crti.o: No such file or directory /home/boris/projects/l2-17.05/build/bootstrap/install/bin/ld: skipping incompatible /usr/lib/gcc/x86_64-linux-gnu/4.8/libgcc.a when searching for -lgcc /home/boris/projects/l2-17.05/build/bootstrap/install/bin/ld: cannot find -lgcc /home/boris/projects/l2-17.05/build/bootstrap/install/bin/ld: skipping incompatible /usr/lib/gcc/x86_64-linux-gnu/4.8/libgcc_s.so when searching for -lgcc_s /home/boris/projects/l2-17.05/build/bootstrap/install/bin/ld: cannot find -lgcc_s /home/boris/projects/l2-17.05/build/bootstrap/install/bin/ld: cannot find -lc /home/boris/projects/l2-17.05/build/bootstrap/install/bin/ld: skipping incompatible /usr/lib/gcc/x86_64-linux-gnu/4.8/libgcc.a when searching for -lgcc /home/boris/projects/l2-17.05/build/bootstrap/install/bin/ld: cannot find -lgcc /home/boris/projects/l2-17.05/build/bootstrap/install/bin/ld: skipping incompatible /usr/lib/gcc/x86_64-linux-gnu/4.8/libgcc_s.so when searching for -lgcc_s /home/boris/projects/l2-17.05/build/bootstrap/install/bin/ld: cannot find -lgcc_s /home/boris/projects/l2-17.05/build/bootstrap/install/bin/ld: cannot find crtn.o: No such file or directory collect2: error: ld returned 1 exit status configure: error: I suspect your system does not have 32-bit development libraries (libc and headers). If you have them, rerun configure with --enable-multilib. If you do not have them, and want to build a 64-bit-only compiler, rerun configure with --disable-multilib.
I don't need the 32 bit stuff. However, I have no idea in which configure scripts this should be put. What do I need to do to build the toolchain for 64 bit?
Hi Boris,
On 22.05.2017 12:07, Boris Mulder wrote:
I'm trying to compile the new toolchain using tool/tool_chain x86. However, it gives the following error:
does the attached patch help?
It might be necessary to delete the tool chain build directory before running the tool_chain script again.
Christian
This does it, thanks!
On 22-05-17 14:11, Christian Prochaska wrote:
Hi Boris,
On 22.05.2017 12:07, Boris Mulder wrote:
I'm trying to compile the new toolchain using tool/tool_chain x86. However, it gives the following error:
does the attached patch help?
It might be necessary to delete the tool chain build directory before running the tool_chain script again.
Christian
tool_chain_bootstrap_disable_multilib.patch
disable multilib support for the bootstrap tool chain
From: Christian Prochaska <christian.prochaska@...1...>
tool/tool_chain | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/tool/tool_chain b/tool/tool_chain index 4b466c1..dc5ebed 100755 --- a/tool/tool_chain +++ b/tool/tool_chain @@ -184,7 +184,8 @@ export MAKEFLAGS endif
COMMON_BOOTSTRAP_CONFIG = $(CONFIG_QUIET) \
--prefix=$(LOCAL_BOOTSTRAP_INSTALL_LOCATION)
--prefix=$(LOCAL_BOOTSTRAP_INSTALL_LOCATION) \--disable-multilibBINUTILS_BOOTSTRAP_CONFIG += $(COMMON_BOOTSTRAP_CONFIG)
Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot
genode-main mailing list genode-main@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/genode-main
Hi,
we want to create a virtual keyboard for touch screen devices. This shall be done by letting the keyboard provide an input service. The problem here is that Nitpicker only provides input to the currently active client. Since the keyboard needs to receive input events from the touch screen, with this policy it would also receive its own sent keys. We need a way to send these keys to another client while still receiving further touch input. How can this be done without compromising current security mechanism or creating unnecessary large pieces of trusted code?
Regards JK
Hi Johannes,
we want to create a virtual keyboard for touch screen devices. This shall be done by letting the keyboard provide an input service. The problem here is that Nitpicker only provides input to the currently active client. Since the keyboard needs to receive input events from the touch screen, with this policy it would also receive its own sent keys. We need a way to send these keys to another client while still receiving further touch input. How can this be done without compromising current security mechanism or creating unnecessary large pieces of trusted code?
that's an interesting problem. Thanks for bringing it up!
I guess that you are already using the input filter to feed the virtual keyboard's events back to nitpicker?
Nitpicker's focus policy can be configured depending on the client's label. Usually, the "click" policy is in effect, which means that a click event implicitly changes the focus to the clicked-on client. However, this policy is not always desired, like in your case or when implementing a global menu. In the latter case, one wants to let the menu handle a click yet retain the original focus. To accommodate such scenarios, nitpicker supports the so-called "transient" focus policy (documentation at [1]). If such a client is clicked-on, it receives the press event and all subsequent events until all buttons/keys are released.
[1] https://github.com/genodelabs/genode/blob/staging/repos/os/src/server/nitpic...
I think that the transient focus policy is the right tool for your use case if your virtual keyboards delivers its artificial events after the release event (otherwise, nitpicker would send the artificial event to the virtual keyboard which still has the transient focus).
For a practical example for configuring the transient focus feature, please have a look at the gems/run/launcher.run script.
I'd be very interested in how this approach works for you. We previously discussed on the list [2] that nitpicker's focus handling is still somewhat limited. So your experience may give me valuable input for possibly refining it.
[2] https://sourceforge.net/p/genode/mailman/genode-main/thread/1a5cd577-1e4c-ba...
Cheers Norman
Hi Norman,
thanks for your answer!
I guess that you are already using the input filter to feed the virtual keyboard's events back to nitpicker?
We have not yet implemented the input service as we're yet thinking about the overall architecture but that would have been our approach.
Nitpicker's focus policy can be configured depending on the client's label. Usually, the "click" policy is in effect, which means that a click event implicitly changes the focus to the clicked-on client. However, this policy is not always desired, like in your case or when implementing a global menu. In the latter case, one wants to let the menu handle a click yet retain the original focus. To accommodate such scenarios, nitpicker supports the so-called "transient" focus policy (documentation at [1]). If such a client is clicked-on, it receives the press event and all subsequent events until all buttons/keys are released.
[1] https://github.com/genodelabs/genode/blob/staging/repos/os/src/server/nitpic...
I think that the transient focus policy is the right tool for your use case if your virtual keyboards delivers its artificial events after the release event (otherwise, nitpicker would send the artificial event to the virtual keyboard which still has the transient focus).
For a practical example for configuring the transient focus feature, please have a look at the gems/run/launcher.run script.
I'd be very interested in how this approach works for you. We previously discussed on the list [2] that nitpicker's focus handling is still somewhat limited. So your experience may give me valuable input for possibly refining it.
[2] https://sourceforge.net/p/genode/mailman/genode-main/thread/1a5cd577-1e4c-ba...
Thanks for these sources. The transient policy sounds right for what we want to do. Sending input events after release might be necessary anyways if we want to handle longer presses. I will give feedback when we are in progress with the implementation.
Regards, JK
-
Boris Mulder -
Christian Prochaska -
Johannes Kliemann -
Norman Feske