[Bug 1001468] eCos GNU tools 4.6.2

[bugzilla-daemon@bugs.ecos.sourceware.org]

Please do not reply to this email. Use the web interface provided at:
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001468

--- Comment #10 from Ilija Kocho <ilijak@siva.com.mk> 2012-02-03 08:42:28 GMT ---
Hi Sergei, thank you for the comments.

(In reply to comment #8)
> Hi Ilija,
> 
> Thank you for your work. Some thoughts if you let.
> 
> It seems for me that we have to discuss/test, get/maintain such a set of
> the patches
> 
>   gcc-4.6.2.patch (common fixes for GCC core and g++)
>   gcc-4.6.2-<arch>.patch (GCC fixes for <arch> architecture)
>   gdb-7.3.1.patch (common fixes for all architectures)
>   gdb-7.3.1-<arch>.patch (GDB fixes for <arch> architecture)
> 
> So, minimal set of patches to review and tests for arm targets
> (including your cortex-m4 founds) would be
> 
>   gcc-4.6.2.patch, gcc-4.6.2-arm.patch
>   gdb-7.3.1.patch, gdb-7.3.1-arm.patch
> 

Generally I find are 3 categories of patches (speaking about GCC):
   - Bug fixes/workarounds: (such as LDRD). They are obsolete so I have omitted
them.

   - eCos related changes other than multilib: I assume we still want them and
I have applied them verbatim.

   - Multilib: This required some creative work and we can expect it to evolve
in future as eCos gets ported to other architectures (I hope for Cortex-A,
Cortex-R). Therefore I have extracted t-arm-elf in a separate file (Attachment
1535) and I would insist keeping it separate.

Further I have separated libgcc and libstfc++ patches. They can probably be
merged back but I think it's better if they stay separate.


> I mean a naming convention (*and splitting*) like used for the patches
> from eCosCentric (you know/work with) which are in Public Domain:
> 
>  
> ftp://sourceware.org/pub/ecos/gnutools/src/ecoscentric-gnutools-20090121-sw-patches.tar.bz2
> 
> Then it will be easy to test (apply only needed), review, and track the
> patches for any supported architecture. More that, then we will be able
> to examine any "inter-diffs", looking on 4.3.2 patch set vs 4.6.2 one.
> As I could see the most (all?) smart/tricky things and workarounds for
> 4.3.2 based toolchain from eCosCentric do migrate to new patch set
> (4.6.2). Is it right? Well, I tried to apply old patches for new stuff
> and I got not so many FAILED Hunks as I could expect, but I got a few.
> Thank you that you get rid all of them.

My application was manual, so actually, after some analysis I got rid of some
patches :)

> 
> Fortunately, the sent patches can be easy joined/split in arch/noarch
> stuffs (there is only one architecture yet) and I would not split fixes
> in GCC 'core' and 'g++' in separate patches (that's mine). What do you
> think? For example, a fix in 'config/host' for arm targets (attachment
> 1538 [details]) I would move to gcc-<version>-arm.patch, etc. IMHO, all fixed
> files under **config/<arch>** directories should be located in a proper
> <arch> patch. And even more, all tweaks for <arch> in GCC core files
> have to be placed also in gcc-4.6.2-<arch>.patch (if that possible).
> 
> Regarding your build scripts. Thank you for sharing it.  Unfortunately,
> I could not get what you proposed as configure options for binutils/gcc.
> I mean magic 'configure' options like --enable-*, --disable-*, --with-*,
> --without-* :-)
> 
> For example, I saw behind sha (# --disable-libspp, # --disable-nls, #
> --with-system-zlib, etc) and I misunderstood the reason. I think that
> build scripts are good things to refer for used options (but, in any
> case most from us use own preferences for scripting), so, IMHO, it's
> better just to have 3 long lines with clear options for 3 invokes
> 'configure' here (and for future documentation) instead any build
> scripts. IMHO, the value of one line the options for 'configure' is much
> higher than 100 lines above and below the line :-) So, I will appreciate
> only 3-lines "script" from you and any experts or three 1-line files
> like binutils.configure, gcc.configure, gdb.configure and that will be
> quite enough for testing and discuss.

I have provided the scripts as a reference how I am building GCC (for the time
being). I understand that they may not work in other environment.

Also, that was my first experience with building GCC (when I started it was GCC
4.6.0), and you can find traces of my learning process in scripts. 

Ilija

-- 
Configure bugmail: http://bugs.ecos.sourceware.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.