# 01:04:38 |
codyps |
quits : Ping timeout: 252 seconds |
# 01:46:02 |
codyps |
joins #crosstool-ng |
# 02:46:08 |
Jacky79 |
joins #crosstool-ng |
# 02:48:54 |
Jacky79 |
Hello, in "How is a toolchain constructed.txt", it said when compile gcc core pass 2, gcc need start files. As far as I know, he start files will be linked to the executable and shared files, so why gcc also need start files in compiling time ? |
# 03:03:26 |
imMute |
Jacky79: that doc does a good explanation |
# 03:06:48 |
Jacky79 |
Yes. But the docs just say "The start files are a very few files that gcc needs to be able to |
# 03:06:48 |
Jacky79 |
turn on thread local storage (TLS) on an NPTL system." |
# 03:07:00 |
Jacky79 |
why ? |
# 03:07:30 |
imMute |
the start files are the stuff that runs before main() |
# 03:07:49 |
imMute |
such as that stuff or copying down constant data or other architectural specifics |
# 03:08:21 |
imMute |
I think they also handle loading shared libraries |
# 03:09:19 |
Jacky79 |
I know, the crt* is linked into executable and shared, and is the entrence for executable and shared. |
# 03:09:51 |
Jacky79 |
so, why gcc need these in compiling time ? |
# 03:10:22 |
imMute |
My guess would be because the start files are C rather than object code. |
# 03:10:30 |
imMute |
someone who knows GCC would know |
# 03:11:21 |
Jacky79 |
The startup files are compiled as object files and are keeped in filesystem. When linking, these start files will be linked into executable. |
# 03:14:18 |
Jacky79 |
I mean that the crt* deals with TLS, but it is in runing time. and crt* are linked into executable and shared. So it seems that it is useless in compiling time. |
# 03:15:06 |
imMute |
because they have to be compiled at compile time? |
# 03:18:24 |
Jacky79 |
You mean that only core gcc pass 2 knows about TLS, so it can build crt* files which can dealing with TLS ? |
# 03:19:28 |
imMute |
no idea |
# 03:19:59 |
Jacky79 |
while like core gcc pass 1 know nothing about TLS, so if use core gcc pass 1 builds crt*, the crt* will not support TLS ? |
# 03:20:32 |
Jacky79 |
you know, all I am confused is 3-step gcc. |
# 03:21:57 |
Jacky79 |
I think 2-step gcc is ok, just like : 1 binutils; 2 freestanding gcc ; 3 kernel headers; 4 glibc; 5 final gcc. |
# 03:22:36 |
Jacky79 |
In crosstoo-ng, it said to support TLS(nptl), the gcc is compiled 3 times. |
# 03:23:19 |
imMute |
the first compilation is a bare minimum. the second is to create a compiler that has zero dependency on the host system. the third is to add in libc support |
# 03:24:35 |
Jacky79 |
yes, what I just said "freestanding" is "bare-metal" you just said. |
# 03:25:52 |
Jacky79 |
And another, the first bare-metal gcc depends on host ? |
# 03:26:44 |
imMute |
not really, but it can't really do much other than compile the kernel headers |
# 03:26:54 |
Jacky79 |
no. |
# 03:27:19 |
Jacky79 |
the bare-metal gcc can build self-containd, including kernel and glibc. |
# 03:28:29 |
imMute |
I'll admit I don't really know why it has to build gcc so many times - I trust y_morin to know WTF he's doing and that it's actually necessary |
# 03:28:43 |
Jacky79 |
so you can see that when use LT thead model, the toolchain just use 2-step gcc. |
# 03:29:21 |
Jacky79 |
I agree, but I can not find the rootcause. |
# 03:29:34 |
imMute |
then my guess is that the gcc-that-can-do-TLS can't be compiled with the host compiler, so it has to have another gcc do it instead (the core pass 1) |
# 03:32:01 |
Jacky79 |
I also doubt, if the host gcc can not compile cross gcc supporting TLS, the simpler gcc can do it ?:) |
# 03:32:19 |
Jacky79 |
host gcc should be strong than core gcc pass 1. |
# 03:32:30 |
imMute |
well apparently it can't |
# 03:32:42 |
Jacky79 |
more detail ? |
# 03:32:53 |
imMute |
nevermind |
# 03:35:42 |
Jacky79 |
For gcc, the crt* are needed by libgcc*so, and libgcc*.so will be replaced by the final gcc. so... |
# 03:38:19 |
Jacky79 |
it is so confused that compiles crt* before core gcc pass 2... |
# 03:43:18 |
Jacky79 |
The crt* is just need by libgcc, so why not use static libgcc, I mean configure gcc with --disable-shared, then the libgcc will not depend on crt*, and crosstool-ng just installs libc header is ok, instead of libc headers and crt*. |
# 03:47:14 |
tkil |
it's not a single-dimensional "stronger". the host gcc does not have the same environment as any of the ct-ng compilers. |
# 04:14:29 |
Jacky79 |
tkil, you mean "gcc-that-can-do-TLS can't be compiled with the host compiler" ? |
# 04:19:05 |
tkil |
very possibly. |
# 04:19:24 |
tkil |
but i think that if you're really that concerned, the correct action is to write to the list, pointing out exactly what has you confused in the docs. |
# 04:19:50 |
tkil |
because if you're confused, then maybe someone else is too, and improving the docs would help everyone. |
# 04:23:31 |
tkil |
yann is sometimes here, but it's only 5a or so in france right now... |
# 04:23:54 |
tkil |
depending on your time zone, you can try asking again in 4 hours, or maybe even after end of european working hours. |
# 04:24:14 |
Jacky79 |
ok, thanks. |
# 04:25:33 |
Jacky79 |
I will mail my confured to list. and I will post here later, hope someone can clarify. |
# 04:34:40 |
Jacky79 |
Let me clarify what I am confused. |
# 04:34:40 |
Jacky79 |
Before using ct-ng, I built a toolchain as the following steps: |
# 04:34:40 |
Jacky79 |
1 build binutils; |
# 04:34:40 |
Jacky79 |
2 bare-metal(freestanding) gcc |
# 04:34:40 |
Jacky79 |
 a configured with "--with-newlib" not to depend on glibc; |
# 04:34:40 |
Jacky79 |
 b configured with "--disable-shared" to build static libgcc, because shared libgcc will linked start files, crt*.o, which will be built in glibc. |
# 04:34:40 |
Jacky79 |
3 use the bare-meta gcc builing glibc; |
# 04:34:41 |
Jacky79 |
4 glibc is ready, so compile the full gcc. |
# 04:34:42 |
Jacky79 |
while studying ct-ng scripts, I found ct-ng add another gcc step: |
# 04:34:42 |
Jacky79 |
after building bare-meta gcc, ct-ng install libc headers and build crt*.o files, then build gcc pass 2, then building glibc using gcc pass 2, then final gcc. |
# 04:34:43 |
Jacky79 |
What I am confused is: |
# 04:34:43 |
Jacky79 |
The crt*.o files is linked into executable and shared, so why gcc need these files in compiling time, why gcc need crt*.o files ? |
# 04:35:00 |
Jacky79 |
so sorry. |
# 04:39:50 |
plfiorini |
quits : Ping timeout: 272 seconds |
# 04:40:24 |
Jacky79 |
all, I just send a mail to list which title is "why build start files before core gcc pass 2". the layout is not distorted. |
# 04:42:39 |
plfiorini |
joins #crosstool-ng |
# 04:42:49 |
Jacky79 |
hope you can clarify my confused ,thanks in advance. |
# 05:12:22 |
alan_o |
quits : Quit: Leaving |
# 05:23:47 |
tkil |
and for future reference, his name is Yann. :) (in fact, i think the list has two of those now...) |
# 05:25:24 |
Jacky79 |
Ok, got it. Thanks! |
# 05:25:59 |
Jacky79 |
my mistake. The english is not my mother language, so often some type error. |
# 05:28:26 |
tkil |
understood. |
# 05:28:55 |
Jacky79 |
another clue, in gcc.sh, I found "In case the threading model is NPTL, we need a shared-capable core gcc". I know, shared-capable gcc will need crt*.o, because libgcc*.so will linked with crt*.o. |
# 05:58:05 |
imMute |
quits : Ping timeout: 255 seconds |
# 07:38:36 |
plfiorini |
quits : Ping timeout: 264 seconds |
# 08:05:25 |
plfiorini |
joins #crosstool-ng |
# 08:12:40 |
plfiorini |
quits : Quit: Leaving |
# 08:49:57 |
kos_tom |
Jacky79: I've followed your questions on the list, and I would also be interested in understanding why gcc has to be compiled three times. |
# 08:50:10 |
kos_tom |
two times make sense to me, but three times, not really. |
# 08:50:23 |
kos_tom |
I've also been given vague explanations, but not real, convincing explanations :) |
# 09:01:22 |
Jacky79 |
kos_tom, I haven't receive your email. pls double check. |
# 09:02:02 |
kos_tom |
Jacky79: I haven't sent an e-mail. |
# 09:02:07 |
kos_tom |
I'm just seeing that I've seen your e-mail |
# 09:02:24 |
kos_tom |
and I'm also interested in seeing replies from people who will give a detailed answer to your interesting question :) |
# 09:02:40 |
Jacky79 |
see. |
# 09:17:41 |
Jacky79 |
kos_tom, I add some hints on the list. |
# 09:37:17 |
smartin |
joins #crosstool-ng |
# 10:06:43 |
Jacky79 |
quits : Remote host closed the connection |
# 12:25:42 |
Net147 |
joins #crosstool-ng |
# 13:47:54 |
Jacky79 |
joins #crosstool-ng |
# 13:57:28 |
Net147 |
quits : Quit: HydraIRC -> http://www.hydrairc.com <- Like it? Visit #hydrairc on EFNet |
# 14:16:17 |
alan_o |
joins #crosstool-ng |
# 15:02:48 |
Jacky79 |
quits : Remote host closed the connection |
# 15:04:09 |
smartin_ |
joins #crosstool-ng |
# 15:07:48 |
smartin |
quits : *.net *.split |
# 15:27:46 |
herdingcat |
joins #crosstool-ng |
# 15:31:30 |
herdingcat |
hi all, I wanna build openmpi-1.6.3 for rpi pi and here's the output by using my own cross-toolchain: http://fpaste.org/Sg2J/ Can anyone tell me how to fix that? Thanks. |
# 16:18:58 |
herdingcat |
anyone herE? |
# 17:09:33 |
y_morin |
joins #crosstool-ng |
# 17:23:04 |
herdingcat |
ping y_morin |
# 17:23:30 |
y_morin |
herdingcat: Hello! |
# 17:23:43 |
herdingcat |
y_morin, hey master!!! |
# 17:24:10 |
herdingcat |
y_morin, sorry to disturb you at this moment. I gonna some issues here to compile some packages for rpi |
# 17:24:30 |
herdingcat |
y_morin, http://fpaste.org/Sg2J/ |
# 17:24:49 |
herdingcat |
y_morin, I don't understand what it means |
# 17:25:49 |
y_morin |
herdingcat: what version of gcc are you using? |
# 17:27:21 |
herdingcat |
y_morin, gcc version 4.7.2 (crosstool-NG 1.17.0) |
# 17:28:05 |
y_morin |
herdingcat: Well, it means that there are no atomic primitives! ;-) |
# 17:28:23 |
y_morin |
herdingcat: atomic primitives are small functions that are called for locking and so on. |
# 17:28:44 |
herdingcat |
y_morin, so is there any way to fix that? |
# 17:29:09 |
herdingcat |
y_morin, do you need ct-ng .config file? |
# 17:29:11 |
y_morin |
herdingcat: Those functions basically wrap up one (or a very few) assembly instruction for the processor it is running on. Those functions are not available for all processors. |
# 17:29:22 |
y_morin |
herdingcat: Yes, .config would be usefull. |
# 17:29:47 |
herdingcat |
y_morin, http://fpaste.org/OJ4D/ |
# 17:29:55 |
herdingcat |
y_morin, .config file |
# 17:30:30 |
y_morin |
herdingcat: http://wiki.debian.org/ArmEabiProblems <-- search for openmpi... ;-) |
# 17:30:45 |
herdingcat |
y_morin, so can I tell the gcc not to use those functions? Because I asked some guys they told me that armv6/armv5 does not support that functions |
# 17:31:00 |
y_morin |
herdingcat: openmpi has not been completely ported to ARM. |
# 17:31:17 |
y_morin |
herdingcat: Yes, probably, armv6/v5 are too "old" for those functions. |
# 17:31:37 |
herdingcat |
y_morin, yes, I read that. But I do really need to compile openmpi in a faster system it takes me 12 hrs to compile this package in rpi |
# 17:31:40 |
herdingcat |
sighs |
# 17:32:48 |
y_morin |
herdingcat: Maybe you could have a look at the gcc-linaro-4.7 (also avail in ct-ng). *Maybe* they have introduced those primitives (as Linaro wants to target a large number of fashionable devices, of which the Pi is). |
# 17:32:48 |
herdingcat |
y_morin, I can compile openmpi under rpi but cannot compile it by cross-toochain, that does not make sense. |
# 17:33:00 |
y_morin |
herdingcat: See my suggestion above. ;-) |
# 17:33:32 |
herdingcat |
y_morin, you mean the workaround is try to use another gcc, right? |
# 17:33:48 |
y_morin |
herdingcat: AFAICS, *maybe*, |
# 17:34:42 |
herdingcat |
y_morin, the point I feel confused is even I specify -march as armv7-a it still fails w/ the atomic error., |
# 17:35:25 |
y_morin |
herdingcat: I've a few things to do here that I need to focus on for a few minutes. Will be available back in ~15min... |
# 17:35:37 |
herdingcat |
y_morin, AFAIK, armv7 can support it those function well. |
# 17:35:45 |
herdingcat |
y_morin, thanks |
# 17:46:58 |
diorcety |
joins #crosstool-ng |
# 17:50:22 |
y_morin |
herdingcat: Worth a read: http://www.jonmasters.org/blog/2012/11/13/arm-atomic-operations/ |
# 17:50:35 |
y_morin |
is reading it right now... |
# 17:51:44 |
herdingcat |
is reading it as well... |
# 17:54:01 |
herdingcat |
y_morin, so? |
# 17:54:29 |
y_morin |
Still no clue... Still looking for answers... |
# 17:56:29 |
herdingcat |
y_morin, mate, I even tried jon's patch for openmpi but still get the same error |
# 17:57:24 |
herdingcat |
y_morin, so I think there must be some options for the compilers to fix this issue. |
# 17:58:35 |
y_morin |
herdingcat: can you run: arm-unknown-linux-gnueabi-gcc -E -dM -xc - |
# 17:59:22 |
y_morin |
herdingcat: my rpi-optimised toolchain says: #define __ARM_ARCH_6__ 1 |
# 17:59:37 |
y_morin |
herdingcat: which means it is targetting an armv6 |
# 18:01:05 |
herdingcat |
y_morin, [huli@localhost ct]$ arm-unknown-linux-gnueabi-gcc -E -dM -xc - |
# 18:01:05 |
herdingcat |
#define __ARM_ARCH_5T__ 1 |
# 18:01:16 |
herdingcat |
y_morin, armv5, I think |
# 18:01:20 |
y_morin |
herdingcat: Yes. |
# 18:01:31 |
herdingcat |
y_morin, is that would be a problem? |
# 18:01:40 |
y_morin |
herdingcat: There's an optimised sample for the rpi in the current ct-ng tree. |
# 18:01:48 |
y_morin |
herdingcat: Maybe you could give that a spin... |
# 18:01:55 |
herdingcat |
y_morin, oh mate, can you download openmpi src package and try to compile it if convenient? |
# 18:02:37 |
herdingcat |
y_morin, and could you give me an optimized .config file for the current stable released ct-ng? |
# 18:02:50 |
y_morin |
herdingcat: No, I have far too much on my tablets. I do already do not have enough time to do all what I *have* to do, even much to do what I *want* to do... :-( |
# 18:03:08 |
y_morin |
herdingcat: look at the ct-ng repository, the sample is right in there... |
# 18:03:08 |
herdingcat |
y_morin, okay. :( |
# 18:04:52 |
herdingcat |
y_morin, you mean in samples/ directory? |
# 18:05:47 |
y_morin |
herdingcat: Yes. But it requries the latest tree, it will (porbably) not work as-is for 1.17.0. |
# 18:06:05 |
y_morin |
herdingcat: what version of openmpi are you using? |
# 18:07:23 |
herdingcat |
y_morin, http://www.open-mpi.org/software/ompi/v1.6/downloads/openmpi-1.6.3.tar.bz2 |
# 18:07:27 |
herdingcat |
y_morin, 1.6.3 |
# 18:09:28 |
imMute |
joins #crosstool-ng |
# 18:09:32 |
y_morin |
herdingcat: 1.6.x looks to have emulated atomic for armv5: https://github.com/open-mpi/ompi-svn-mirror/blob/v1.6/opal/include/opal/sys/arm/atomic.h#L56 |
# 18:10:13 |
herdingcat |
y_morin, so there has been a fix here, right? |
# 18:10:36 |
y_morin |
herdingcat: probably not. There probably is a much deeper issue... |
# 18:11:41 |
herdingcat |
y_morin, the current default arch I set up for ct-ng is armv5, can I use march to compile codes for other arm arch? |
# 18:13:37 |
y_morin |
herdingcat: I'd suggest you look at the arm-hardrpi sample (note the CT_ARCH_ARCH and CT_ARCH_FPU settings), and rebuild your toolchain with these values. |
# 18:14:03 |
herdingcat |
y_morin, okay, you are right |
# 18:14:44 |
y_morin |
is always right! (unless proven otherwise!) ;-] |
# 18:17:19 |
herdingcat |
quits : Quit: Leaving |
# 18:28:11 |
diorcety |
y_morin: Hi ! |
# 18:55:41 |
plfiorini |
joins #crosstool-ng |
# 19:04:56 |
smartin_ |
quits : Quit: leaving |
# 19:25:55 |
retard |
quits : Read error: Operation timed out |
# 19:57:42 |
ctngbot |
joins #crosstool-ng |
# 20:15:41 |
y_morin |
diorcety: Hello! |
# 21:09:46 |
diorcety |
y_morin: i need your help |
# 21:10:04 |
y_morin |
gives his help to diocerty |
# 21:10:08 |
y_morin |
diorcety: happy, now? ;-) |
# 21:10:24 |
diorcety |
y_morin: thanks, good night |
# 21:10:29 |
y_morin |
:-) |
# 21:10:36 |
diorcety |
quits : Quit: Leaving. |
# 21:10:54 |
diorcety |
joins #crosstool-ng |
# 21:10:56 |
diorcety |
haha |
# 21:11:12 |
y_morin |
had a panic-moment... :-( |
# 21:11:29 |
y_morin |
OK, seriously, now. What's the issue? |
# 21:12:34 |
diorcety |
I'm trying to add other compiler |
# 21:12:36 |
diorcety |
(llvmgcc) |
# 21:17:39 |
y_morin |
diorcety: So? |
# 21:23:08 |
mingwandroid |
quits : Quit: Leaving. |
# 21:29:13 |
diorcety |
i have strange behaviour |
# 21:29:48 |
diorcety |
y_morin: in first time st-dummy.c:1:23: error: sys/types.h: No such file or directory |
# 21:29:59 |
diorcety |
i saw that you already had the same issue |
# 21:30:09 |
diorcety |
it's not a big deal .. but after that |
# 21:30:10 |
y_morin |
diorcety: yes, with SuperH |
# 21:30:29 |
diorcety |
types.h:168: error: two or more data types in declaration specifiers |
# 21:34:11 |
diorcety |
y_morin: i have this issue with x86, power ... but not ARM |
# 21:34:35 |
y_morin |
Hmm... Can you pastebin the build.log, please? |
# 21:36:48 |
y_morin |
diorcety: Also, isn't llvmgcc dead, and 'replaced' by the llvm plugin to gcc? |
# 21:51:45 |
diorcety |
y_morin: now it clang |
# 21:51:48 |
diorcety |
it's |
# 21:52:30 |
diorcety |
y_morin: http://dl.free.fr/kINT693ko |
# 21:57:59 |
y_morin |
diorcety: is i386-unknown-elf the real tuple? |
# 22:00:06 |
y_morin |
diorcety: What are you targetting: bare-metal, or Linux kernel? |
# 22:00:31 |
y_morin |
diorcety: i386-unknown-elf is for bare-metal; i386-unknown-linux-gnu is for Linux. |
# 22:02:05 |
diorcety |
y_morin: at the end? all . but here yes bare-metal |
# 22:05:14 |
y_morin |
diorcety: Without the code, I can't say much. But what about: http://stackoverflow.com/questions/2098973/two-or-more-data-types-in-declaration-specifiers-error |
# 22:05:32 |
ubergeek42 |
quits : Ping timeout: 252 seconds |
# 22:06:00 |
mingwandroid |
joins #crosstool-ng |
# 22:12:04 |
diorcety |
pid_t it's two time defined |
# 22:12:14 |
diorcety |
i just want know ifyou already have this issue |
# 22:17:08 |
y_morin |
diorcety: No, I don't remember having it so far. |
# 22:21:46 |
ubergeek42 |
joins #crosstool-ng |
# 22:28:36 |
y_morin |
quits : Quit: Night Night! |
# 22:29:50 |
smartin |
quits : Quit: leaving |
# 22:53:16 |
devcoder |
joins #crosstool-ng |