This is the mail archive of the crossgcc@sourceware.org mailing list for the crossgcc project.
See the CrossGCC FAQ for lots more information.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
Yann E. MORIN wrote: > Konrad, All, > > On Monday 14 November 2011 11:30:54 Konrad Eisele wrote: >> I'll send revised patches as reply to this one, in the >> meantime here are the comment-comments: > > OK, I saw your updated patch. I'll have a look tomorow, it's a bit late > for me here for now, and I could not get to review it this evening... > Sorry for the delay this implies... :-( > >> I'll send the Multilib-patches only. I also skip the CC_MULTILIB >> option definition, as for you have to decide where to put it. > > Sorry I was not explicit. My opinion is it should go into the toolchain > sub-menu. If you think of a better place, feel free to suggest it. :-) You should decide. >>>> + done >>>> + >>>> + # rewrite the library multiplexers >>>> + for l in libc libpthread libgcc_s; do >>>> + for d in lib/${dir} usr/lib/${dir}; do >>>> + if [ -f "${CT_SYSROOT_DIR}/${d}/${l}.so" -a ! -L ${CT_SYSROOT_DIR}/${d}/${l}.so ]; then >>>> + if [ ! -f "${CT_SYSROOT_DIR}/${d}/${l}.so_ori_i" ]; then >>> >>> What if the the _ori_i file already exist? >>> Surely, it should not happen, and if it does, we should consider this >>> as an error. >> >> I emit a Warning. If _iri_i exist it will already have been patched. > > But why would a file, that we _just_installed_, be already patched? Yes you are right, the "if [ ! -f "${CT_SYSROOT_DIR}/${d}/${l}.so_ori_i" ]; then" ... can be removed. > >>>> + > >>>> + CT_DoLog EXTRA "Prepare C library" >>>> + CT_DoExecLog ALL make ${JOBSFLAGS} \ >>>> + "${extra_make_args[@]}" \ >>>> + clean >>> >>> Why do you need to clean here? >>> The build dir should be brand new, as we just mkdir it a few lines above. >>> In any way, do not reuse any existing dir. >> >> I remember that it didnt proceed compiling without it when using the >> "RESTART, STOP" option, maybe it can be removed, on the other hand it >> doesnt hurt. > > OK. But I would prefer to really understand why it breaks, so we get to > fix it rather than have a workaround... > I tried again with the "clean" rule removed. I built the whole chain and also did a "RESTART=libc STOP=libc" and it still built. So again: You are right and the "clean" rule can be removed. >>> We need to find a place where to put that option, but I think the gcc >>> sub-menu is not the proper place. >> >> I didnt add this to the patchset this time. I think you have >> to decide where to place CC_MULTILIB ... >> >>> Multi-lib is a property of the toolchain, that is implemented by many >>> components, and gcc is only one of those. binutils also plays a role in >>> multilib. >>> >>> So, it makes more sense to put the option in a more global sub-menu, such >>> as in the toolchain options sub-menu. > > And here I said where to put it. ;-) > > Thanks for the efforts you are putting in that feature. It's much > appreciated! > > As I said above (it was about 1h ago for me!), I'll review the new patch > tomorrow. > > Going to sleep for now... (eyes, stay open for a few more minutes, please)... :-) > > Regards, > Yann E. MORIN. > -- For unsubscribe information see http://sourceware.org/lists.html#faq
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |