| # 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 |