Compiling the GNU ada compiler on a new platform
Hi All, I'm wanting to update the GNU ADA compiler for OS/2... I'm currently building GCC 4.3.x and 4.4.x on OS/2 (C/C++/fortran) but for ADA configure complains about not finding gnat. The problem is that the only gnat compiled for OS/2 was years ago using a different toolchain so it's not suitable. I assume that at some point in time, ada didn't depend on an existing gnat, so if I could find that version, I could compile a version of gnat to get me started?? Otherwise it's a bit chicken and egg :( -- Cheers, Paul.
Re: Compiling the GNU ada compiler on a very old platform
Hi Geert! On Thu, 27 Aug 2009 01:44:11 UTC, Geert Bosch wrote: > > On Aug 21, 2009, at 18:40, Paul Smedley wrote: > > I'm wanting to update the GNU ADA compiler for OS/2... I'm currently > > building GCC 4.3.x and 4.4.x on OS/2 (C/C++/fortran) but for ADA > > configure complains about not finding gnat. The problem is that the > > only gnat compiled for OS/2 was years ago using a different toolchain > > so it's not suitable. > > I used to maintain the OS/2 port for AdaCore, but that was many years > ago. > IBM released its last version of OS/2 in 2001. Currently it is almost > impossible to run OS/2 in either real modern hardware or on a > virtualized > system. Not quite true - www.ecomstation.com - and it does run in things like virtualbox. I'm running on a quad core system here and all 4 cores are recognised. > AFAIK, GNAT 3.15p is the last GNAT version with OS/2 support. As the > OS/2 > version was a full implementation of Ada 95, including all annexes, > passing > all ACATS tests, this version should still be very useful today, if you > have a system running OS/2, that is. If you're interested in developing > Ada applications on OS/2, your best bet is to use GNAT 3.15p. > You'll get a mature well-tested and very fast compiler. I don't actually NEED this :) Another member of the community inquired about an updated gnat, so I thought I'd look at it. With GNAT 3.15p did it also depend on an existing gnat? or that one built directory from source? > This version might still be able to bootstrap GNAT. It might - but I'm using a different c library :( libc vs emx -- Cheers, Paul.
'Obsolete' architectures in GCC 4.4
Hi Guys, I see the following in the changes for GCC 4.4: Support for a number of older systems and recently unmaintained or untested target ports of GCC has been declared obsolete in GCC 4.4. Unless there is activity to revive them, the next release of GCC will have their sources permanently removed. The following ports for individual systems on particular architectures have been obsoleted: * Generic a.out on IA32 and m68k (i[34567]86-*-aout*, m68k-*-aout*) For the record, the Generic a.out support for IA32 is used by my GCC 4.3.3 and upcoming GCC 4.4.x ports for OS/2. I don't yet have the patches in any form ready enough to be submitted for inclusion, but they are available from http://www.smedley.info/os2ports/index.php?page=gcc I'd be really grately if the IA32 a.out support could be left in place as it does work for OS/2 at least :) -- Cheers, Paul.
build break in libstdc++-v3 on OS/2
Hi All, I'm trying to update my OS/2 port of GCC to v4.6.3 I have the compiler part building, but am currently getting a break in libstdc++-v3. The error is as follows: In file included from U:/DEV/gcc-4.6.3/i386-pc-os2-emx/libstdc++-v3/include/rege x:39:0, from ../../.././libstdc++-v3/src/regex.cc:30: U:/DEV/gcc-4.6.3/i386-pc-os2-emx/libstdc++-v3/include/bitset: In member function 'void std::bitset<_Nb>::_M_copy_from_ptr(const _CharT*, std::size_t, std::size_ t, std::size_t, _CharT, _CharT)': U:/DEV/gcc-4.6.3/i386-pc-os2-emx/libstdc++-v3/include/bitset:1371:67: error: no matching function for call to 'min(unsigned int&, const unsigned int&)' U:/DEV/gcc-4.6.3/i386-pc-os2-emx/libstdc++-v3/include/bitset:1371:67: note: cand idates are: U:/DEV/gcc-4.6.3/i386-pc-os2-emx/libstdc++-v3/include/bits/stl_algobase.h:187:5: note: template const _Tp& std::min(const _Tp&, const _Tp&) U:/DEV/gcc-4.6.3/i386-pc-os2-emx/libstdc++-v3/include/bits/stl_algobase.h:233:5: note: template const _Tp& std::min(const _Tp&, const _Tp&, _Compare) U:/DEV/gcc-4.6.3/i386-pc-os2-emx/libstdc++-v3/include/bits/stl_algo.h:4184:5: no te: template _Tp std::min(std::initializer_list<_Tp>) U:/DEV/gcc-4.6.3/i386-pc-os2-emx/libstdc++-v3/include/bits/stl_algo.h:4189:5: no te: template _Tp std::min(std::initializer_list<_Tp>, _Compare) Any ideas? Cheers, Paul
.opt file help
Hi All,
As part of updating the OS/2 port of GCC from v4.4.x to v4.6.x I've hit
a snag where the passing of options to the linker is no longer working.
Previous OS/2 builds of gcc have supported -Zlinker on the command
line to pass the option to the linker.
With previous gcc versions this worked, however with 4.6 I get an error
about gcc not recognising the option.
I added:
-Zlinker
driver separate
to the opt file I'm using, now the option is recognised but it doesn't
know what to do with it.
I added
{-Zlinker}
to LINK_SPEC - but it's passing -Zlinker and the option to the linker.
Any hints, tips or documentation on LINK_SPEC?
Thanks in advance,
Paul
Re: .opt file help
Hi Jonathan,
On 09/04/12 21:54, Jonathan Wakely wrote:
On 9 April 2012 10:59, Paul Smedley wrote:
Hi All,
As part of updating the OS/2 port of GCC from v4.4.x to v4.6.x I've hit a
snag where the passing of options to the linker is no longer working.
Previous OS/2 builds of gcc have supported -Zlinker on the command line
to pass the option to the linker.
With previous gcc versions this worked, however with 4.6 I get an error
about gcc not recognising the option.
I added:
-Zlinker
driver separate
Can you simply make it an alias of the existing -Xlinker option?
-Zlinker
Driver Separate Alias(-Xlinker)
I discovered the above shortly after posting last night. I tried it
this morning and it doesn't work :(
Looking at emx.h again - the previous code that worked with GCC <= 4.5
had as part of GCC_DRIVER_HOST_INITIALIZATION:
else if (!strcmp (argv [i], "-Zlinker"))
\
{\
if (i + 1 >= argc) \
fatal_error ("argument to `-Zlinker' is missing");\
arg [0] = "-Xlinker"; \
arg [1] = "-O"; \
arg [2] = "-Xlinker"; \
arg [3] = argv [++i]; \
arg_count = 4;\
} \
So it looks like it was rewriting a gcc option of (for example)
-Zlinker /PM:PM
to -Xlinker -O -Xlinker /PM:PM
whereas alias's Zlinker to -xlinker just results in -Xlinker /PM:PM
which fails :(
Re: .opt file help
On 10/04/12 07:17, Paul Smedley wrote:
Hi Jonathan,
On 09/04/12 21:54, Jonathan Wakely wrote:
On 9 April 2012 10:59, Paul Smedley wrote:
Hi All,
As part of updating the OS/2 port of GCC from v4.4.x to v4.6.x I've
hit a
snag where the passing of options to the linker is no longer working.
Previous OS/2 builds of gcc have supported -Zlinker on the
command line
to pass the option to the linker.
With previous gcc versions this worked, however with 4.6 I get an error
about gcc not recognising the option.
I added:
-Zlinker
driver separate
Can you simply make it an alias of the existing -Xlinker option?
-Zlinker
Driver Separate Alias(-Xlinker)
I discovered the above shortly after posting last night. I tried it this
morning and it doesn't work :(
Looking at emx.h again - the previous code that worked with GCC <= 4.5
had as part of GCC_DRIVER_HOST_INITIALIZATION:
else if (!strcmp (argv [i], "-Zlinker")) \
{ \
if (i + 1 >= argc) \
fatal_error ("argument to `-Zlinker' is missing");\
arg [0] = "-Xlinker"; \
arg [1] = "-O"; \
arg [2] = "-Xlinker"; \
arg [3] = argv [++i]; \
arg_count = 4; \
} \
So it looks like it was rewriting a gcc option of (for example)
-Zlinker /PM:PM
to -Xlinker -O -Xlinker /PM:PM
whereas alias's Zlinker to -xlinker just results in -Xlinker /PM:PM
which fails :(
FWIW - having the following in LINK_SPEC appears to fix it:
"%{Zlinker*:-O %*}" \
