| # 00:02:02 |
pamaury |
quits : Remote host closed the connection |
| # 00:17:09 |
enunes |
quits : Ping timeout: 248 seconds |
| # 02:53:58 |
aneyman |
quits : Ping timeout: 268 seconds |
| # 03:30:28 |
feepbot |
quits : Ping timeout: 256 seconds |
| # 03:44:44 |
qu9 |
joins #crosstool-ng |
| # 03:48:00 |
feepbot |
joins #crosstool-ng |
| # 04:01:33 |
qu9 |
quits : Ping timeout: 260 seconds |
| # 06:23:09 |
aneyman |
joins #crosstool-ng |
| # 07:06:59 |
philenot1ound |
is now known as: philenotfound |
| # 08:40:30 |
pamaury |
joins #crosstool-ng |
| # 08:44:36 |
aneyman |
quits : Ping timeout: 250 seconds |
| # 09:26:37 |
pamaury |
quits : Ping timeout: 260 seconds |
| # 10:24:03 |
enunes |
joins #crosstool-ng |
| # 10:25:53 |
enunes |
quits : Client Quit |
| # 10:26:07 |
enunes |
joins #crosstool-ng |
| # 12:23:40 |
enunes |
quits : Ping timeout: 265 seconds |
| # 12:34:39 |
enunes |
joins #crosstool-ng |
| # 12:47:37 |
blueness_ |
quits : Quit: blueness_ |
| # 13:15:29 |
tony87 |
joins #crosstool-ng |
| # 13:18:04 |
tony87 |
Hi everyone! I have an issue. The build finished successfully, though I had to copy some .h and lib files manually. At the end when I compile the code i get a message like this. |
| # 13:18:12 |
tony87 |
crosstool-NG/builds/xtensa-cv36-elf/lib/gcc/xtensa-cv36-elf/4.8.2/../../../../xtensa-cv36-elf/lib/crt1-sim.o:(.literal+0x0): undefined reference to `__stack' |
| # 13:18:40 |
tony87 |
can someone pinpoint how to fix this ? |
| # 14:40:50 |
blueness_ |
joins #crosstool-ng |
| # 14:59:44 |
pamaury_ |
joins #crosstool-ng |
| # 15:04:48 |
yann-kaelig |
joins #crosstool-ng |
| # 15:40:14 |
blueness_ |
quits : Quit: blueness_ |
| # 15:40:39 |
pamaury_ |
quits : Ping timeout: 244 seconds |
| # 15:40:51 |
blueness_ |
joins #crosstool-ng |
| # 15:58:26 |
aneyman |
joins #crosstool-ng |
| # 16:06:54 |
tony87 |
quits : Read error: Connection reset by peer |
| # 16:23:17 |
blueness_ |
quits : Quit: blueness_ |
| # 16:57:36 |
blueness_ |
joins #crosstool-ng |
| # 17:33:25 |
aneyman |
quits : Ping timeout: 248 seconds |
| # 17:45:51 |
blueness_ |
quits : Quit: blueness_ |
| # 18:00:34 |
enunes |
quits : Ping timeout: 250 seconds |
| # 18:03:44 |
aneyman |
joins #crosstool-ng |
| # 18:12:19 |
enunes |
joins #crosstool-ng |
| # 18:33:24 |
blueness_ |
joins #crosstool-ng |
| # 18:51:01 |
aneyman_ |
wbx: are you here? |
| # 18:51:37 |
aneyman_ |
1.0.20 broke another sample, now xtensa-fsf-linux-uclibc fails to build any target binary with |
| # 18:52:06 |
aneyman_ |
/home/avn/x-tools/xtensa-fsf-linux-uclibc/xtensa-fsf-linux-uclibc/sysroot/usr/lib/libc.a(libdl.os):(.literal+0x74): undefined reference to `_dl_tlsdesc_return' |
| # 18:52:06 |
aneyman_ |
/home/avn/x-tools/xtensa-fsf-linux-uclibc/lib/gcc/xtensa-fsf-linux-uclibc/6.2.0/../../../../xtensa-fsf-linux-uclibc/bin/ld: a.out: hidden symbol `_dl_tlsdesc_return' isn't defined |
| # 18:52:06 |
aneyman_ |
/home/avn/x-tools/xtensa-fsf-linux-uclibc/lib/gcc/xtensa-fsf-linux-uclibc/6.2.0/../../../../xtensa-fsf-linux-uclibc/bin/ld: final link failed: Bad value |
| # 19:01:49 |
pamaury |
joins #crosstool-ng |
| # 20:06:52 |
wbx |
aneyman_: i build xtensa in my test, but for qemu little endian. is this big endian fsf overlay? |
| # 20:09:48 |
aneyman_ |
yes |
| # 20:10:12 |
aneyman_ |
but it is not the build of uClibc that fails |
| # 20:10:24 |
aneyman_ |
rather, an app fails to link with the resulting libc |
| # 20:10:34 |
wbx |
static linking? |
| # 20:13:15 |
wbx |
there is one change we can't avoid since 1.0.18+, when static linking is used, you must be sure to add -static to your linking, as otherwise a circular dependency between libc and libgcc isn't correctly resolved. that's because now libpthread.a is included in libc.a which includes calls to unwind functions from libgcc, which uses functionality from libc.a. okay? |
| # 20:13:38 |
wbx |
looks like this problem... not 100% sure. need to see the complete line of call |
| # 20:14:44 |
aneyman_ |
again, linking static |
| # 20:14:52 |
aneyman_ |
just found that myself too: |
| # 20:14:53 |
aneyman_ |
avn@mistral:~/work/ctng/crosstool-ng$ ~/x-tools/xtensa-fsf-linux-uclibc/bin/xtensa-fsf-linux-uclibc-gcc -o ttt ttt.c -O2 -Wall -static |
| # 20:14:53 |
aneyman_ |
/home/avn/x-tools/xtensa-fsf-linux-uclibc/xtensa-fsf-linux-uclibc/sysroot/usr/lib/libc.a(libdl.os):(.literal+0x74): undefined reference to `_dl_tlsdesc_return' |
| # 20:14:53 |
aneyman_ |
/home/avn/x-tools/xtensa-fsf-linux-uclibc/lib/gcc/xtensa-fsf-linux-uclibc/6.2.0/../../../../xtensa-fsf-linux-uclibc/bin/ld: ttt: hidden symbol `_dl_tlsdesc_return' isn't defined |
| # 20:14:54 |
aneyman_ |
/home/avn/x-tools/xtensa-fsf-linux-uclibc/lib/gcc/xtensa-fsf-linux-uclibc/6.2.0/../../../../xtensa-fsf-linux-uclibc/bin/ld: final link failed: Bad value |
| # 20:14:57 |
aneyman_ |
collect2: error: ld returned 1 exit status |
| # 20:14:59 |
aneyman_ |
avn@mistral:~/work/ctng/crosstool-ng$ cat ttt.c |
| # 20:15:01 |
aneyman_ |
#include |
| # 20:15:05 |
aneyman_ |
int main(void) { return 0; } |
| # 20:15:33 |
aneyman_ |
xtensa uses separate libdl and ldso sources in uClibc, right? |
| # 20:18:15 |
aneyman_ |
and yes, -static is there |
| # 20:20:38 |
wbx |
hmm. then i need to take a look. did this worked with 1.0.19? 1.0.18? 1.0.17? |
| # 20:21:16 |
wbx |
xtensa is special regarding tls descriptors. |
| # 20:22:04 |
wbx |
so the breakage might be xtensa specific. |
| # 20:22:28 |
aneyman_ |
it worked in 1.0.17 |
| # 20:26:42 |
aneyman_ |
1.0.18 had a similar breakage across the board, I don't remember if xtensa failed or not |
| # 20:27:39 |
aneyman_ |
1.0.19, apparently, passed for xtensa - there were only two failures on arm samples while linking libdl statically |
| # 20:28:17 |
aneyman_ |
so this looks like the same kind of breakage 1.0.18 had, but now only for xtensa |
| # 20:29:22 |
wbx |
i will try to reproduce the problem. |
| # 20:33:44 |
aneyman_ |
well, the problem is that LDSO_ELFINTERP (elfinterp.c) is included in both ldso and libdl |
| # 20:33:45 |
aneyman_ |
and elfinterp.c requires __dl_tlsdesc_return, which is provided by dl-tlsdesc.S |
| # 20:33:45 |
aneyman_ |
and that file is only included into ldso, but not into libdl |
| # 20:35:37 |
wbx |
any patch suggestion? but why the behaviour changed after 1.0.17? have I fucked up something there because of duplicate symbols? |
| # 20:38:16 |
aneyman_ |
I don't know yet |
| # 20:44:21 |
wbx |
hmm. i don't see the problem with little endian |
| # 20:45:01 |
wbx |
can you paste somewhere gcc -v from your cross-compiler? |
| # 20:45:31 |
wbx |
is it plain gcc 6.2.0 or some patches? |
| # 20:46:13 |
aneyman_ |
patches as in crosstool-ng's patches/gcc |
| # 20:46:20 |
aneyman_ |
there are some xtensa patches |
| # 20:47:08 |
aneyman_ |
can you check what 'nm libc.a | grep tlsdesc_return' reports in your test |
| # 20:47:31 |
aneyman_ |
cannot post gcc -v right away - I just started a rebuild of 1.0.19 to confirm it was fine |
| # 20:47:44 |
aneyman_ |
and see how it was built |
| # 20:49:10 |
wbx |
huch. it is empty. no tlsdesc_return |
| # 20:49:55 |
wbx |
in which *.os it is in your build? |
| # 20:50:41 |
aneyman_ |
avn@mistral:~/work/ctng/crosstool-ng$ ~/x-tools/xtensa-fsf-linux-uclibc/bin/xtensa-fsf-linux-uclibc-gcc -v |
| # 20:50:42 |
aneyman_ |
Using built-in specs. |
| # 20:50:42 |
aneyman_ |
COLLECT_GCC=/home/avn/x-tools/xtensa-fsf-linux-uclibc/bin/xtensa-fsf-linux-uclibc-gcc |
| # 20:50:42 |
aneyman_ |
COLLECT_LTO_WRAPPER=/home/avn/x-tools/xtensa-fsf-linux-uclibc/libexec/gcc/xtensa-fsf-linux-uclibc/6.2.0/lto-wrapper |
| # 20:50:42 |
aneyman_ |
Target: xtensa-fsf-linux-uclibc |
| # 20:50:44 |
aneyman_ |
Configured with: /home/avn/work/ctng/crosstool-ng/.build/src/gcc-6.2.0/configure --build=x86_64-build_pc-linux-gnu --host=x86_64-build_pc-linux-gnu --target=xtensa-fsf-linux-uclibc --prefix=/home/avn/x-tools/xtensa-fsf-linux-uclibc --with-sysroot=/home/avn/x-tools/xtensa-fsf-linux-uclibc/xtensa-fsf-linux-uclibc/sysroot --enable-languages=c,c++ --with-pkgversion='crosstool-NG crosstool-ng-1.22.0-354-gee4446c' --enable-__cxa_atexit --disable-libmud |
| # 20:50:49 |
aneyman_ |
flap --disable-libgomp --disable-libssp --disable-libquadmath --disable-libquadmath-support --disable-libsanitizer --disable-libmpx --with-gmp=/home/avn/work/ctng/crosstool-ng/.build/xtensa-fsf-linux-uclibc/buildtools --with-mpfr=/home/avn/work/ctng/crosstool-ng/.build/xtensa-fsf-linux-uclibc/buildtools --with-mpc=/home/avn/work/ctng/crosstool-ng/.build/xtensa-fsf-linux-uclibc/buildtools --with-isl=/home/avn/work/ctng/crosstool-ng/.build/xtensa-f |
| # 20:50:54 |
aneyman_ |
sf-linux-uclibc/buildtools --enable-lto --with-host-libstdcxx='-static-libgcc -Wl,-Bstatic,-lstdc++,-Bdynamic -lm' --enable-threads=posix --enable-target-optspace --disable-nls --disable-multilib --with-local-prefix=/home/avn/x-tools/xtensa-fsf-linux-uclibc/xtensa-fsf-linux-uclibc/sysroot --enable-long-long |
| # 20:50:58 |
aneyman_ |
Thread model: posix |
| # 20:51:00 |
aneyman_ |
gcc version 6.2.0 (crosstool-NG crosstool-ng-1.22.0-354-gee4446c) |
| # 20:51:02 |
aneyman_ |
libdl.os |
| # 20:51:09 |
aneyman_ |
avn@mistral:~/work/ctng/crosstool-ng$ nm ~/x-tools/xtensa-fsf-linux-uclibc/xtensa-fsf-linux-uclibc/sysroot/usr/lib/libc.a | grep tlsdesc_return |
| # 20:51:11 |
aneyman_ |
U _dl_tlsdesc_return |
| # 20:51:56 |
aneyman_ |
avn@mistral:~/work/ctng/crosstool-ng$ nm ~/x-tools/xtensa-fsf-linux-uclibc/xtensa-fsf-linux-uclibc/sysroot/lib/ld-uClibc.so.0 | grep tlsdesc_return |
| # 20:51:56 |
aneyman_ |
00004558 t _dl_tlsdesc_return |
| # 20:52:55 |
wbx |
hmm. i have configured my toolchain with --disable-shared |
| # 20:53:30 |
aneyman_ |
ah :) |
| # 20:54:03 |
wbx |
i do this when doing full static builds. i try with a --enabled-shared toolchain and then -static linking |
| # 20:54:25 |
aneyman_ |
diff -urpN uClibc-ng-1.0.19/libc/Makefile.in uClibc-ng-1.0.20/libc/Makefile.in |
| # 20:54:26 |
aneyman_ |
--- uClibc-ng-1.0.19/libc/Makefile.in 2016-10-23 00:19:04.000000000 -0700 |
| # 20:54:26 |
aneyman_ |
+++ uClibc-ng-1.0.20/libc/Makefile.in 2016-12-04 00:52:49.000000000 -0800 |
| # 20:54:26 |
aneyman_ |
@@ -42,29 +42,24 @@ else |
| # 20:54:26 |
aneyman_ |
libc-a-y = $(libc-y) $(libc-static-y) |
| # 20:54:26 |
aneyman_ |
endif |
| # 20:54:28 |
aneyman_ |
+libc-a-$(HAVE_SHARED) += $(libdl-a-y) |
| # 20:54:30 |
aneyman_ |
libc-a-$(DO_C99_MATH) += $(libm-a-y) |
| # 20:54:48 |
aneyman_ |
I guess that's the culprit - that's why libdl.os did not get into libc.a in 1.0.19 |
| # 20:55:04 |
aneyman_ |
but does so with 1.0.20 |
| # 20:55:24 |
wbx |
there was some user request on the mailingist |
| # 20:55:31 |
aneyman_ |
and while generic libdl.os behaves fine, xtensa's libdl.os has references to symbols outside of libc |
| # 20:55:54 |
aneyman_ |
I suspect this is how you fixed the 'static link with libdl' issue, right? |
| # 20:56:50 |
wbx |
yes. lance.. he used a shared toolchain and tried to compile openvpn and other packages statically. so he need libdl.a code in libc.a |
| # 20:57:16 |
aneyman_ |
so probably the fix is to compile dl-tlsdesc.S twice, too - once for libdl and once for ldso |
| # 20:57:25 |
aneyman_ |
similarly to how elfinterp.c ends up in both |
| # 20:58:37 |
wbx |
but only for static mode, otherwise we get duplicate symbol problem or not? |
| # 20:58:55 |
aneyman_ |
probably yes |
| # 20:59:07 |
aneyman_ |
although it can be made weak in libc |
| # 21:01:36 |
wbx |
if you have a clear idea and could cook up a patch, that would be great :) |
| # 21:03:45 |
aneyman_ |
I don't have any xtensa to test that the resulting binaries work :) I can take a stab at the patch and test it by building libc/simple app, but have no way of testing if it runs :) |
| # 21:06:18 |
wbx |
i can check little endian on my board |
| # 21:06:53 |
wbx |
and you can run in qemu |
| # 21:09:50 |
wbx |
i can now reproduce the failure in little endian mode |
| # 21:10:26 |
aneyman_ |
ok |
| # 21:10:32 |
aneyman_ |
will try to make a patch tonight |
| # 21:10:47 |
aneyman_ |
if you don't beat me to it :) |
| # 21:11:33 |
wbx |
i need to add those tests. i test shared build and run test suite, i test static builds and compile code. but i don't use shared toolchain to create static bins. i need thse covered in the future |
| # 21:11:45 |
aneyman_ |
yeah, just confirmed, libdl.os was not even built with 1.0.19 |
| # 21:11:54 |
aneyman_ |
only libdl.oS (i.e. shared) |
| # 21:11:54 |
wbx |
i wait for the patch... :) |
| # 21:12:13 |
wbx |
i am to k.o. working on it. 2 hours badminton.. |
| # 21:14:04 |
aneyman_ |
:) can I suggest "Krusovice Imperial" for the next release? :) |
| # 21:14:35 |
wbx |
no. belgian beer is set for the release names for 1.0.x ;) |
| # 21:14:50 |
aneyman_ |
ah, damn :) |
| # 21:14:55 |
aneyman_ |
1.1.x? :) |
| # 21:14:58 |
wbx |
Krusovice does not sound belgian |
| # 21:15:08 |
aneyman_ |
It's Czech, of course ;) |
| # 21:16:04 |
wbx |
i am thinking about polish beer for 1.1.x, but may be a mixup of east european would be fine, too :) |
| # 21:17:59 |
wbx |
it is getting more difficult to get more unique belgian beers in germany ;) |
| # 21:18:26 |
wbx |
i always buy and drink two of them on release day ;) |
| # 21:20:26 |
aneyman_ |
tell me... I am struggling to find decent beers in the US |
| # 21:23:40 |
wbx |
the us beers are really bad. i was on holidays there for 6 weeks many years ago, the irish pubs where fine ;) |
| # 21:24:50 |
wbx |
i think in new york we found some german kölsch somewhere ;) |
| # 21:30:12 |
aneyman_ |
yes, it is possible, but the selection is very small |
| # 21:30:44 |
aneyman_ |
BevMo usually carries a couple of Czech, 3-4 german brands and a few Belgians |
| # 21:31:25 |
aneyman_ |
But it is impossible to find Budweiser, because of that legal dispute with american namesake |
| # 21:31:45 |
aneyman_ |
(which is nigh impossible to drink, btw) :) |
| # 21:32:30 |
wbx |
because the us had it's own budweiser it is not possible to ge the czech beer? |
| # 21:33:48 |
aneyman_ |
well, they are allowed to sell under a different name (I think it's "Budejovicky Czechvar", or something like that) |
| # 21:34:02 |
aneyman_ |
but it can't be found anywhere |
| # 21:34:35 |
wbx |
are you using crosstool-ng @work or just hacking fo fun? |
| # 21:34:37 |
aneyman_ |
I found it once in a "World Market", bought all the inventory they had (which was just two cases, sigh) |
| # 21:34:42 |
aneyman_ |
both, I guess |
| # 21:34:43 |
wbx |
s/fo/for/ |
| # 21:35:18 |
aneyman_ |
we use it at work, and that's where the multilib support and "comp tools for host" work started |
| # 21:35:35 |
blueness_ |
quits : Quit: blueness_ |
| # 21:35:43 |
aneyman_ |
other than that, just making sure it is more-or-less stable and releasable :) |
| # 21:36:32 |
wbx |
the linkedin info is still correct? Lynx. isn't it a realtime os. you then use bare-metal toolchains mainly? |
| # 21:40:21 |
aneyman_ |
yes, linked info is correct |
| # 21:40:30 |
aneyman_ |
but I am not in LynxOS group |
| # 21:40:47 |
aneyman_ |
we have another product, LynxSecure - which is a bare metal hypervisor |
| # 21:41:34 |
aneyman_ |
and one of the supported guests is a paravirtualized Linux |
| # 21:41:44 |
aneyman_ |
for which ct-ng is used |
| # 21:44:01 |
wbx |
on which hardware platforms the hypervisor is running? |
| # 21:44:52 |
yann-kaelig |
quits : Quit: Leaving |
| # 21:45:21 |
blueness_ |
joins #crosstool-ng |
| # 21:46:11 |
aneyman_ |
currently x86 only |
| # 21:51:47 |
wbx |
will you take over elease management in crosstool-ng? or will bryan do a release ? |
| # 21:55:52 |
aneyman_ |
I think Bryan was going to do that |
| # 21:56:16 |
aneyman_ |
It is not like I am trying to wrestle this project from anybody |
| # 21:56:24 |
aneyman_ |
it just lied dormat for too long :) |
| # 21:56:33 |
aneyman_ |
s/dormat/dormant/ |
| # 23:14:14 |
pamaury |
quits : Ping timeout: 265 seconds |