Hi team, I'm looking for some help - as suggested I successfully built GCC on Debian and gave it a shot on HPE Nonstop OSS. According to ./config.guess, my system was nsv-tandem-nskL25 so I had to run configure like below - ../configure \ --build=nsv-tandem-nskL25 \ --host=nsv-tandem-nskL25 \ --target=nsv-tandem-nskL25 \ --enable-languages=c,c++ \ --disable-multilib \ --disable-shared \ --prefix=$HOME/gcc-install \ CC="nscc -Wstd=c17" \ CXX="nscc -Wstd=c++17" \ LD=xld The CC, CXX & LD flags are my system specific - I also wanted to build GCC for C & C++ first before considering other languages. But it seems to fail at the below make step irrespective of what I do. make[3]: Entering directory '/home/shiva/gcc/build/libiberty' if [ x"-fPIC" != x ] && [ ! -d pic ]; then \ mkdir pic; \ else true; fi touch stamp-picdir if [ x"" != x ] && [ ! -d noasan ]; then \ mkdir noasan; \ else true; fi touch stamp-noasandir if [ x"-fPIC" != x ]; then \ nscc -Wstd=c17 -c -DHAVE_CONFIG_H -g -I. -I../../libiberty/../include -D_GNU_SOURCE -fPIC ../../libiberty/regex.c -o pic/regex.o; \ else true; fi nscc: illegal option -- f Makefile:1241: recipe for target 'regex.o' failed make[3]: *** [regex.o] Error 1 make[3]: Leaving directory '/home/shiva/gcc/build/libiberty' Makefile:14374: recipe for target 'all-stage1-libiberty' failed make[2]: *** [all-stage1-libiberty] Error 2 make[2]: Leaving directory '/home/shiva/gcc/build' Makefile:25592: recipe for target 'stage1-bubble' failed make[1]: *** [stage1-bubble] Error 2 make[1]: Leaving directory '/home/shiva/gcc/build' Makefile:1105: recipe for target 'all' failed make: *** [all] Error 2 /home/shiva/gcc/build: Unfortunately, our C compiler doesn't under the -fPIC flag - I've tried exporting PICFLAG variable as empty before configure or run it as a param to Make but neither worked. I wouldn't want to update the libiberty/Makefile manually so would appreciate any ideas. Thanks, Shiva ________________________________ From: Shiva Subramanian <Shiva.Subramanian@xxxxxxxxxx> Sent: Saturday, September 06, 2025 21:08 To: Basile Starynkevitch <basile@xxxxxxxxxxxxxxxxx>; Jonathan Wakely <jwakely.gcc@xxxxxxxxx> Cc: gcc-help <gcc-help@xxxxxxxxxxx> Subject: Re: Porting GCC Hello, Thank you everyone for your advice. Apologies for not providing enough information in my first email. HPE Nonstop Compute is currently x86 architecture so they can run on any standard x86 hardware. They have two intertwined operating systems - Guardian & OSS. The later is POSIX.1 and POSIX.2 compliant, and partially conforms to the XPG4 specifications. Over the years, we've found some deviances to the compliance but mostly we've had good success porting open source over to it. Git runs natively without any recompile but we had to contribute some code to it, so does OpenSSL and a few other open source products. The executable format that works on HPE Nonstop Compute's OSS is ELF64-bit, Big_Endian, X86_64. We do have C17 & C++17 support on the platform with some minor exceptions so hopefully the build will be smooth. I'll try and build it locally as suggested and then try the same on the Nonstop compute. Thanks, Shiva ________________________________ From: Basile Starynkevitch <basile@xxxxxxxxxxxxxxxxx> Sent: Saturday, September 06, 2025 09:48 To: Jonathan Wakely <jwakely.gcc@xxxxxxxxx> Cc: Shiva Subramanian <Shiva.Subramanian@xxxxxxxxxx>; gcc-help <gcc-help@xxxxxxxxxxx> Subject: Re: Porting GCC On Sat, 2025-09-06 at 09:35 +0100, Jonathan Wakely via Gcc-help wrote: > On Sat, 6 Sept 2025, 06:34 Basile Starynkevitch, <basile@xxxxxxxxxxxxxxxxx> > wrote: > > > . > > > > > > If HPE Nonstop has some specific to HPE coding rules, tell us more about > > them, then consider first writing your GCC plugin > > (it has to be open source and could be inspired from > > https://arxiv.org/abs/1109.0779 and obsolete code on > > https://github.com/bstarynk/bismon that you will need to improve and port) > > > > Basile, > > Please stop telling people to write their own GCC plugins. > > A plugin is not relevant to porting to a new OS. it definitely is if the OS has an API not supported by current GCC And once you have an open source plugin, proposing to merge it inside GCC is simpler (both technically and politically). On the other hand most OSes have today some POSIX compatibility. For those OSes running on Intel processors the porting effort should be very small But if you write a brand new OS (and kernel with its own API) and want to support GCC on that new OS (which is supposed to be non POSIX) you need documentation of that OS. For example take GNU hurd or https://en.wikipedia.org/wiki/L4_microkernel_family (I don't know if GCC is ported to L4; I heard it have been) At last, many libraries define an API and it makes sense to have some code to check compliance with that API. (it could be outside of GCC, e.g. frama-c.com based) -- Basile STARYNKEVITCH <basile@xxxxxxxxxxxxxxxxx> 8 rue de la Faïencerie http://starynkevitch.net/Basile/ 92340 Bourg-la-Reine https://github.com/bstarynk France https://github.com/RefPerSys/RefPerSys
