ibotlog2html for #crosstool-ng

<< Previous 2011-12-12 Next >>

# 08:57:23 smartin joins #crosstool-ng
# 10:04:23 smartin quits : Ping timeout: 258 seconds
# 10:10:28 sh4rm4 joins #crosstool-ng
# 10:57:12 smartin joins #crosstool-ng
# 13:50:33 smartin quits : Ping timeout: 258 seconds
# 16:53:12 mnt_real joins #crosstool-ng
# 20:53:44 kugel joins #crosstool-ng
# 20:53:46 kugel parts #crosstool-ng
# 20:53:54 kugel joins #crosstool-ng
# 20:54:04 kugel hello
# 20:54:14 kugel can someone help me on how to use a local patch repository?
# 21:29:59 kos_tom I can probably give some help if no-one else is around.
# 21:30:17 kos_tom I've never used that feature in crosstool-ng, but I've heard of it, so I might try to help.
# 21:32:31 kugel kos_tom: just wondering about the naming conventions (path
# 21:32:38 kugel paths etc)
# 21:33:21 kugel in the meantime I reverse-engineered it from /usr/lib/ct-ng/patches and ./build.log. there's zero information on this feature
# 21:34:24 kos_tom Note that you must ensure that the directory containing your custom
# 21:34:25 kos_tom patches is arranged the same way the official directory is.
# 21:34:33 kos_tom in the help text of the LOCAL_PATCH_DIR option
# 21:34:46 kos_tom isn't that sufficient?
# 21:35:23 kugel not if the official repositry doesnt have patches for what I need one (eglibc ports)
# 21:36:07 kos_tom ah, yes, that's the kind of complicated case probably.
# 21:36:18 kos_tom I guess Yann would gladly take patches to improve the help text and/or the documentation
# 21:36:49 kugel also I didn't find that help text, I only looked in the top option (Patches origin)
# 22:00:42 y_morin joins #crosstool-ng
# 22:01:24 y_morin kos_tom: heyda! :-)
# 22:01:47 y_morin kugel: every option in the menuconfig has an associated help text.
# 22:02:21 y_morin kugel: as for the eglibc patch directory, follow the naming of the glibc structure, that is:
# 22:02:26 kos_tom y_morin: I keep receiving some error e-mails from your e-mail address @anciens.enib.fr
# 22:02:45 y_morin kugel: /local/patches/eglibc-ports/2.13/
# 22:03:01 kugel it's 2_13 actually
# 22:03:33 y_morin kos_tom: yeah, I know that. I'm banging on the admins so they let me tweak the config of the server. It uses some kind of black-list to detect spam, but guesses wrong most of the time... :-(
# 22:03:38 y_morin kugel: right.
# 22:04:31 y_morin kugel: and I got it wrong... It's: /local/patches/eglibc/ports-2_13
# 22:06:27 y_morin kugel: and the path you must enter in the config is: /local/patches
# 22:06:47 kos_tom y_morin: actually, I don't think it tells me that my mail is spam, it simply timeouts.
# 22:07:01 kugel y_morin: thanks. valuable information
# 22:07:10 y_morin kugel: cheers! :-)
# 22:07:21 y_morin kos_tom: gah... :-(
# 22:07:45 y_morin fumbles in his memory to remember how to access this fscking server... :-/
# 22:09:20 kugel any way to configure what CFLAGS to use?
# 22:09:50 kugel the same way as --with-XXX/--enable-YYY ?
# 22:11:24 y_morin curses the server... It's down... :-(
# 22:11:28 kugel or CT_TARGET_CFLAGS?
# 22:11:38 y_morin kugel: depends on what you want to pass in the CFLAGS?
# 22:11:55 kugel -U_FORTIFY_SOURCE
# 22:12:11 y_morin kugel: then, there is an option in the C library sub-menu for that.
# 22:12:27 kugel it should apply to gcc
# 22:14:05 y_morin kugel: C-library ---> [ ] Enable fortified build (EXPERIMENTAL)
# 22:14:26 y_morin kugel: by default -U_FORTIFY_SOURCE is passed, but if you set the above to 'y', then it is not.
# 22:14:48 y_morin kugel: it's a C library build option, it goes into the C library sub-menu.
# 22:15:40 kugel y_morin: I didnt enable experimintal features, this it should be off
# 22:15:46 y_morin kugel: note that you have to enable the experimental features to see this option. If you don't enable experimental, then you won't see the option, and it default to 'n'.
# 22:15:51 y_morin kugel: yes.
# 22:16:26 kugel I need to pass it to gcc/binutils as well
# 22:17:16 kugel otherwise the toolchain generates calls to symbols that are only there with _FORTIFY_SOURCE
# 22:17:35 y_morin kugel: for binutils, it is not possible to pass specific CFLAGS for now. So it needs changes to the code.
# 22:17:37 kugel (if I compile the target program with -U_FORTIFY_SOURCE then everything is fine again)
# 22:18:41 y_morin kugel: ditto for gcc.
# 22:18:52 kugel bummer
# 22:18:59 y_morin kugel: for gcc, you may get along with using the option "Flags to pass to --enable-cxx-flags"
# 22:19:55 y_morin kugel: you mean gcc e;its calls to 'fortified' symbols? What's the exact error message?
# 22:20:23 kugel no error message
# 22:20:49 kugel it just emits stuff like __open_2@@GLIBC_2.7
# 22:20:58 kugel (i guess the linker is doing it but anyway)
# 22:21:27 kugel this is for a normal open() call which resolves to open@@GLIBC_2.4 with -U_FORTIFY_SOURCE
# 22:21:56 kugel btw does ct-ng use ccache in anyway?
# 22:22:44 y_morin kugel: ccache is known to break the toolchain build, for sure. The only workaround to fix that is to remove it entirely; I have no fix.
# 22:23:06 y_morin kugel: and when running the toolchain proper, I have absolutely no idea on how ccache behaves...
# 22:23:48 y_morin kugel: I'd suggest that you try without ccache first, and then enable it only if everything works.
# 22:47:06 kugel y_morin: problem is that gcc does "#define _FORTIFY_SOURCE 2" by default
# 22:47:10 kugel I need to disable that
# 22:48:52 y_morin kugel: indeed, but I have no idea on why it does that. What gcc is that?
# 22:48:56 y_morin (version)
# 22:49:30 kugel 4.4.x
# 22:51:32 y_morin kugel: did you enable libssp?
# 22:52:24 kugel no
# 22:52:44 y_morin kugel: I see no place where gcc would do that. The only occurences of 'FORTIFY_SOURCE' are in libssp. And nowhere else in the code is there any reference to even just 'FORTIFY'
# 22:53:13 y_morin kugel: care to pastebin your .config, please?
# 22:58:46 y_morin quits : Quit: Night...

Generated by ibotlog2html by Yann E. MORIN