# 00:09:46 |
smartin |
quits |
# 01:05:50 |
TheHound |
quits : Ping timeout: 265 seconds |
# 02:28:46 |
ben1066 |
quits : Ping timeout: 272 seconds |
# 02:29:31 |
ben1066 |
joins #crosstool-ng |
# 02:29:31 |
ben1066 |
quits : Changing host |
# 02:29:31 |
ben1066 |
joins #crosstool-ng |
# 03:29:39 |
alan_ |
joins #crosstool-ng |
# 03:30:13 |
alan_ |
parts #crosstool-ng |
# 03:32:13 |
alan_o |
joins #crosstool-ng |
# 04:54:34 |
alan_o |
parts #crosstool-ng |
# 08:27:38 |
smartin |
joins #crosstool-ng |
# 09:57:01 |
y_morin |
joins #crosstool-ng |
# 11:44:11 |
smartin |
quits : Ping timeout: 245 seconds |
# 11:54:31 |
gxk |
joins #crosstool-ng |
# 14:06:24 |
kos_tom |
y_morin: hello. Are you still around? |
# 14:10:36 |
y_morin |
kos_tom: I'm here episodaically today. Shoot while I'm on-line! ;-) |
# 14:11:41 |
kos_tom |
I still have the gdbserver build problem :) |
# 14:11:52 |
kos_tom |
(I'm still trying to rebuild all my ct-ng toolchains in the autobuilder) |
# 14:12:19 |
y_morin |
kos_tom: yes, I also stumbled upon the gdbserver issue. Had no time investigate, though... |
# 14:21:46 |
sh4rm4 |
quits : Ping timeout: 276 seconds |
# 14:39:37 |
kos_tom |
y_morin: ok |
# 14:44:42 |
kos_tom |
y_morin: the problem is that the compilation line contains both -shared and -static, which doesn't make sense |
# 14:45:11 |
y_morin |
kos_tom: wrong. It does make sense: create a shared library that has all "dependencies" statically linked into it. |
# 14:46:46 |
y_morin |
kos_tom: but in our specific context, it does indeed not make sense, because we want a static gdbserver, so there is no reason to build a shared library in the first place. |
# 14:48:06 |
kos_tom |
maybe --enable-static would help? |
# 14:48:34 |
y_morin |
kos_tom: in the gdbserver ./configure ? |
# 14:48:50 |
kos_tom |
yeah, but I'm not sure they are using libtool |
# 14:49:16 |
y_morin |
I'll give it a spin... |
# 14:49:26 |
kos_tom |
hum, apparently, the IPA_LIB is always shared, according to Makefile.in |
# 14:51:30 |
y_morin |
kos_tom: building a staticaly-linked gdbserver used to work with previous versions... :-( |
# 14:52:42 |
kos_tom |
y_morin: look at 20.3.4 in http://sourceware.org/gdb/onlinedocs/gdb/Server.html |
# 14:52:53 |
kos_tom |
it's a library that you should LD_PRELOAD on the target |
# 14:54:21 |
y_morin |
kos_tom: OK, so, passing -static is probably wrong in this case. :-( |
# 14:55:47 |
y_morin |
kos_tom: OK, got to go for a while. I'll look at how to solve this later. Thanks for the pointer! :-) |
# 14:57:31 |
kos_tom |
ok --disable-inprocess-agent should do the trick |
# 15:08:53 |
kos_tom |
testing now. |
# 15:38:02 |
kos_tom |
y_morin: I confirm that --disable-inprocess-agent worked around the problem |
# 15:46:53 |
y_morin |
kos_tom: OK, that's a workaround. But I understand that this library is required in some cases, so we'd better find a way to build it, and still be able to build a static gdbserver, no? |
# 15:47:44 |
kos_tom |
y_morin: well, it's not needed to use gdbserver, it's only needed if you want tracepoints, if I understand correctly. |
# 15:48:06 |
y_morin |
kos_tom: yes, that's my understanding, too. |
# 15:49:20 |
kos_tom |
I think it probably doesn't make much sense to build such a library statically. |
# 15:49:20 |
y_morin |
I'll look at how to: build a static gdbserver (handy if one wants to debug shared library loading), and build a shared libinproctrace.so (for tracing). |
# 15:49:30 |
y_morin |
kos_tom: right. |
# 15:49:34 |
kos_tom |
so either you want static build, and you have only gdbserver, or you want shared build, and you get the whole thing. |
# 15:49:47 |
kos_tom |
sounds like we're on the same idea :) |
# 15:52:29 |
y_morin |
kos_tom: not really. You can use a static gdbserver to debug a dynamicaly-linked executable, in which you may want to load the IPA lib. |
# 15:53:12 |
y_morin |
kos_tom: but the IPA lib should not be staticaly linked, indeed. |
# 15:54:01 |
y_morin |
kos_tom: Og course, as a first step, ct-ng can offer this choice: either static gdbserver with no IPA lib, or shared gdbserver with IPA lib. |
# 15:54:05 |
y_morin |
*Of course |
# 15:56:04 |
y_morin |
kos_tom: and libinproctrace appeared in gdb-7.2, which I have not yet used. That's why I never had the issue so far... :-/ |
# 17:37:07 |
alan_o |
joins #crosstool-ng |
# 17:46:03 |
sh4rm4 |
joins #crosstool-ng |
# 18:12:45 |
esbenh |
quits : *.net *.split |
# 18:12:45 |
sh4rm4 |
quits : *.net *.split |
# 18:12:45 |
mnt_real |
quits : *.net *.split |
# 18:12:45 |
kos_tom |
quits : *.net *.split |
# 18:12:45 |
ChanServ |
quits : *.net *.split |
# 18:12:45 |
danderson |
quits : *.net *.split |
# 18:12:45 |
arekinath |
quits : *.net *.split |
# 18:12:45 |
y_morin |
quits : *.net *.split |
# 18:12:45 |
alan_o |
quits : *.net *.split |
# 18:12:45 |
ben1066 |
quits : *.net *.split |
# 18:12:45 |
al` |
quits : *.net *.split |
# 18:12:45 |
imMute |
quits : *.net *.split |
# 18:12:45 |
gotit_ |
quits : *.net *.split |
# 18:12:45 |
gxk |
quits : *.net *.split |
# 18:12:45 |
sh4rm4 |
joins #crosstool-ng |
# 18:12:45 |
alan_o |
joins #crosstool-ng |
# 18:12:45 |
gxk |
joins #crosstool-ng |
# 18:12:45 |
y_morin |
joins #crosstool-ng |
# 18:12:45 |
ben1066 |
joins #crosstool-ng |
# 18:12:45 |
esbenh |
joins #crosstool-ng |
# 18:12:45 |
al` |
joins #crosstool-ng |
# 18:12:45 |
imMute |
joins #crosstool-ng |
# 18:18:38 |
ctngbot |
joins #crosstool-ng |
# 18:42:23 |
smartin |
joins #crosstool-ng |
# 20:21:16 |
smartin |
quits : Ping timeout: 245 seconds |
# 21:27:39 |
y_morin |
kos_tom: I've pushed two new csets for the gdbserver issue, with your --disable-inprocess-agent trick, if you want to give it a spin. |
# 21:34:27 |
kos_tom |
ok, thanks! |
# 21:34:49 |
kos_tom |
I have built a Linaro gcc + uclibc toolchain. The build went fine, but Busybox then fails to link with: |
# 21:34:52 |
kos_tom |
busybox_unstripped uses VFP register arguments, libpwdgrp/lib.a(uidgid_get.o) does not |
# 21:35:17 |
kos_tom |
as if the code was compiled with -mfloat-abi=softfp, but linked with -mfloat-abi=hard |
# 21:42:57 |
kos_tom |
this is a toolchain built with CT_ARCH_FLOAT="hard" |
# 21:54:29 |
kos_tom |
ok, was my fault. |
# 21:55:29 |
y_morin |
kos_tom: what was the reason? |
# 21:56:50 |
kos_tom |
BR was passing -msoft-float |
# 21:57:02 |
kos_tom |
I wasn't seeing it in th build output so I was puzzled |
# 21:57:08 |
y_morin |
Ah. Indeed, linker can get confused! |
# 21:57:13 |
kos_tom |
but it was silently passed by the external toolchain wrapper |
# 21:57:26 |
kos_tom |
basically, BR2_SOFT_FLOAT was selected |
# 21:57:34 |
kos_tom |
maybe I should add an external toolchain check on this |
# 21:57:47 |
kos_tom |
if it's somehow possible to guess whether the toolchain is hard or soft float |
# 21:59:21 |
y_morin |
kos_tom: no easy way to check, afaik... |
# 22:21:29 |
y_morin |
quits : Quit: Night! |