[9fans] Using gpc and g77 in 9front

[9fans] Using gpc and g77 in 9front

[mouad-all]

[-- Attachment #1: Type: text/plain, Size: 664 bytes --]

Hello,

Is it possible to compile an older version of gcc in 9front to use the gnu pascal and gnu fortran 77 compilers?

I have found an older version of gcc for i386 at https://code.google.com/archive/p/ports2plan9/downloads but I don't know if it will actually work nowadays.

There are converters like p2c and f2c, but they are limited in comparison to a compiler.

So please any advice or guidance would be much appreciated.
------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/T41cf38050bd5915d-Md03ce1e400bc9a4faedf6261
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

[-- Attachment #2: Type: text/html, Size: 1352 bytes --]

Re: [9fans] Using gpc and g77 in 9front

[Jens Staal]

On Wed, Dec 11, 2024 at 03:07:09AM -0500, mouad-all@outlook.com wrote:
> Hello,
> 
> Is it possible to compile an older version of gcc in 9front to use the gnu
> pascal and gnu fortran 77 compilers?
> 
> I have found an older version of gcc for i386 at https://code.google.com/
> archive/p/ports2plan9/downloads but I don't know if it will actually work
> nowadays.

The GCC port probably still works, but only for i386. I have abandoned
that track a bit and am now more interested in the transpilers since
they (theoretically) would work on all architectures supported by the C
compilers. 

> There are converters like p2c and f2c, but they are limited in comparison to a
> compiler.

I have integrated f2c and p2c in APExp, and I hope to integrate even
more transpilers there. I have not had time to play with it lately, but
I see my APExp project as a "spiritual successor" to ports2plan9

https://github.com/staalmannen/APExp 

> So please any advice or guidance would be much appreciated.
> 9fans / 9fans / see discussions + participants + delivery options Permalink

------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/T41cf38050bd5915d-M22e718799462db553700e5b5
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

[9fans] Re: Using gpc and g77 in 9front

[mouad-all]

[-- Attachment #1: Type: text/plain, Size: 529 bytes --]

Thanks for your reply.

How can I compile https://storage.googleapis.com/google-code-archive-downloads/v2/code.google.com/ports2plan9/gcc-4.5.4-p9-2-pth-src.tar.bz2 for i386 on 9front?

Unlike the very old version https://9p.io/sources/extra/gcc/ for plan9, there is no p9config script or similar.
------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/T41cf38050bd5915d-Mc1aaa200a73bb441a5bfa3e4
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

[-- Attachment #2: Type: text/html, Size: 1267 bytes --]

Re: [9fans] Re: Using gpc and g77 in 9front

[Frank D. Engel, Jr.]

[-- Attachment #1: Type: text/plain, Size: 1248 bytes --]

One thing to bear in mind is that it is not just the compiler you need 
to get working for a given language, but the runtime environment as well.

If the porting work did not cover the runtime libraries for those 
languages, you may still have some work to do for that.


On 12/11/24 03:44, mouad-all@outlook.com wrote:
> Thanks for your reply.
>
> How can I compile 
> https://storage.googleapis.com/google-code-archive-downloads/v2/code.google.com/ports2plan9/gcc-4.5.4-p9-2-pth-src.tar.bz2 
> for i386 on 9front?
>
> Unlike the very old version https://9p.io/sources/extra/gcc/ for 
> plan9, there is no p9config script or similar.
> *9fans <https://9fans.topicbox.com/latest>* / 9fans / see discussions 
> <https://9fans.topicbox.com/groups/9fans> + participants 
> <https://9fans.topicbox.com/groups/9fans/members> + delivery options 
> <https://9fans.topicbox.com/groups/9fans/subscription> Permalink 
> <https://9fans.topicbox.com/groups/9fans/T41cf38050bd5915d-Mc1aaa200a73bb441a5bfa3e4> 
>
------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/T41cf38050bd5915d-M62940c790d14dd542f403355
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

[-- Attachment #2: Type: text/html, Size: 2149 bytes --]

Re: [9fans] Re: Using gpc and g77 in 9front

[mouad-all]

[-- Attachment #1: Type: text/plain, Size: 597 bytes --]

At least in the old plan9 port of gcc https://9p.io/sources/extra/gcc/ the script p9config had --enable-languages'=c,c++' in it that you can modify, that is why I wanted to know how the compilation of  https://storage.googleapis.com/google-code-archive-downloads/v2/code.google.com/ports2plan9/gcc-4.5.4-p9-2-pth-src.tar.bz2 works without a script similar to p9config.
------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/T41cf38050bd5915d-Meeac2a36447b04992ad6f0bc
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

[-- Attachment #2: Type: text/html, Size: 1287 bytes --]

Re: [9fans] Re: Using gpc and g77 in 9front

[Michael Grunditz]

On Wed, 11 Dec 2024 at 11:09, <mouad-all@outlook.com> wrote:
>
> At least in the old plan9 port of gcc https://9p.io/sources/extra/gcc/ the script p9config had --enable-languages'=c,c++' in it that you can modify, that is why I wanted to know how the compilation of  https://storage.googleapis.com/google-code-archive-downloads/v2/code.google.com/ports2plan9/gcc-4.5.4-p9-2-pth-src.tar.bz2 works without a script similar to p9config.

If you need Pascal , a better path would be to port fpc ( Free
pascal). Fpc is very portable and is built with Fpc crosscompiler. The
only things needed is assembly for interworking with the operating
system. I have done a quick and dirty port to RISC OS , and that
system isn't like anything else. There are very few dependencies, most
important is gnu binutils .. you need to be able to produce a binary
that runs on Plan9. I guess that it can be tricked into something that
you can binary patch in order to get something useful.

I don't know Plan9 well enough to do it myself , but it is quite
simple if you know the system.

Michael

------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/T41cf38050bd5915d-M234978795b3bc9ea0d86d504
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] Using gpc and g77 in 9front

[Yury Chumak]

Once I tried to rebuild your sources in 9Front but it didn't work. I
had to modify the sources a little, add wrappers for APE, something
else (I don't remember everything). I achieved to rebuild it itself,
but C++ part doesn't work there.

Taking this opportunity, I would like to ask - under what conditions
did you build - a clean Plan9 or a ported environment or something
else?? And did the C++ part work for you??

ср, 11 дек. 2024 г. в 10:19, Jens Staal <staal1978@gmail.com>:
>
> On Wed, Dec 11, 2024 at 03:07:09AM -0500, mouad-all@outlook.com wrote:
> > Hello,
> >
> > Is it possible to compile an older version of gcc in 9front to use the gnu
> > pascal and gnu fortran 77 compilers?
> >
> > I have found an older version of gcc for i386 at https://code.google.com/
> > archive/p/ports2plan9/downloads but I don't know if it will actually work
> > nowadays.
>
> The GCC port probably still works, but only for i386. I have abandoned
> that track a bit and am now more interested in the transpilers since
> they (theoretically) would work on all architectures supported by the C
> compilers.
>
> > There are converters like p2c and f2c, but they are limited in comparison to a
> > compiler.
>
> I have integrated f2c and p2c in APExp, and I hope to integrate even
> more transpilers there. I have not had time to play with it lately, but
> I see my APExp project as a "spiritual successor" to ports2plan9
>
> https://github.com/staalmannen/APExp
>
> > So please any advice or guidance would be much appreciated.
> > 9fans / 9fans / see discussions + participants + delivery options Permalink



-- 
Sphynkx

------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/T41cf38050bd5915d-Md5c4bda460c92f4943ebe405
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] Using gpc and g77 in 9front

[mouad-all]

[-- Attachment #1: Type: text/plain, Size: 570 bytes --]

> Once I tried to rebuild your sources in 9Front but it didn't work. I
had to modify the sources a little, add wrappers for APE, something
else (I don't remember everything). I achieved to rebuild it itself,
but C++ part doesn't work there.

I would appreciate it if you point me to what you modified in the sources to get it to compile.
------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/T41cf38050bd5915d-Mbb8aa2810c311fb6e282d264
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

[-- Attachment #2: Type: text/html, Size: 1161 bytes --]

Re: [9fans] Using gpc and g77 in 9front

[Jens Staal]

[-- Attachment #1: Type: text/plain, Size: 2213 bytes --]

The Cfront is work-in-progress in APExp. I verify that each release builds
from scratch on a clean 9front amd64 VM.

Between releases, there can be breakage.

Den ons 11 dec. 2024 13:37Yury Chumak <sfynkx@gmail.com> skrev:

> Once I tried to rebuild your sources in 9Front but it didn't work. I
> had to modify the sources a little, add wrappers for APE, something
> else (I don't remember everything). I achieved to rebuild it itself,
> but C++ part doesn't work there.
>
> Taking this opportunity, I would like to ask - under what conditions
> did you build - a clean Plan9 or a ported environment or something
> else?? And did the C++ part work for you??
>
> ср, 11 дек. 2024 г. в 10:19, Jens Staal <staal1978@gmail.com>:
> >
> > On Wed, Dec 11, 2024 at 03:07:09AM -0500, mouad-all@outlook.com wrote:
> > > Hello,
> > >
> > > Is it possible to compile an older version of gcc in 9front to use the
> gnu
> > > pascal and gnu fortran 77 compilers?
> > >
> > > I have found an older version of gcc for i386 at
> https://code.google.com/
> > > archive/p/ports2plan9/downloads but I don't know if it will actually
> work
> > > nowadays.
> >
> > The GCC port probably still works, but only for i386. I have abandoned
> > that track a bit and am now more interested in the transpilers since
> > they (theoretically) would work on all architectures supported by the C
> > compilers.
> >
> > > There are converters like p2c and f2c, but they are limited in
> comparison to a
> > > compiler.
> >
> > I have integrated f2c and p2c in APExp, and I hope to integrate even
> > more transpilers there. I have not had time to play with it lately, but
> > I see my APExp project as a "spiritual successor" to ports2plan9
> >
> > https://github.com/staalmannen/APExp
> >
> > > So please any advice or guidance would be much appreciated.
> > > 9fans / 9fans / see discussions + participants + delivery options
> Permalink
> 
> --
> Sphynkx

------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/T41cf38050bd5915d-Mff3b4dfb44d1071fff1994bd
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

[-- Attachment #2: Type: text/html, Size: 4145 bytes --]

Re: [9fans] Using gpc and g77 in 9front

[Yury Chumak]

It was long time ago - dont remember detailsnow.. But I have my
personal notes that was written during rebuild process trying.. Put it
here:
https://9f.sphynkx.org.ua/wiki/gcc
Sorry they are in russian but it may be translate via google-translate..

ср, 11 дек. 2024 г. в 15:21, <mouad-all@outlook.com>:
>
> Once I tried to rebuild your sources in 9Front but it didn't work. I
> had to modify the sources a little, add wrappers for APE, something
> else (I don't remember everything). I achieved to rebuild it itself,
> but C++ part doesn't work there.
>
>
> I would appreciate it if you point me to what you modified in the sources to get it to compile.
> 9fans / 9fans / see discussions + participants + delivery options Permalink



-- 
Sphynkx

------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/T41cf38050bd5915d-M8d3ab3f06b08ba088472fe19
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] Using gpc and g77 in 9front

[Yury Chumak]

[-- Attachment #1: Type: text/plain, Size: 812 bytes --]

Hmm.. some formatting issues there.. Same text in attach..

ср, 11 дек. 2024 г. в 15:21, <mouad-all@outlook.com>:
>
> Once I tried to rebuild your sources in 9Front but it didn't work. I
> had to modify the sources a little, add wrappers for APE, something
> else (I don't remember everything). I achieved to rebuild it itself,
> but C++ part doesn't work there.
>
>
> I would appreciate it if you point me to what you modified in the sources to get it to compile.
> 9fans / 9fans / see discussions + participants + delivery options Permalink



-- 
Sphynkx

------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/T41cf38050bd5915d-Mfde4905297d9a6c4d09cef7f
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

[-- Attachment #2: p9_gcc.md --]
[-- Type: application/octet-stream, Size: 71051 bytes --]


## GCC
GCC v.3.0.0 ported to Plan9. 386 only.https://9p.io/sources/extra/gcc/ Там 3 архива - бинарь, сорцы и APE.GCC не может скомпилиться штатным плановским компиллятором, поэтому сначала необходимо установить бинари. Бинари можно устанавливать в х64, они компилят код с получением 386-бинарей, но в План9 другая архитектура запускаться не будет. Поэтому целесообразнее разворачиваться сразу на 386.

https://github.com/staalmannen/9front-screenshots тут есть упоминание о в.4.8, но сайт недоступен, а в сорцах автора признаков портирования нет.

GCC не понимает стиль кода План9 (и наоборот), поэтому плановские исходники необходимо приводить в приемлемый для GCC вид.
Пример корректного план9-кода:
#include <u.h>
#include <libc.h>

void
main()

{
    print("HW!!\n");
    exits(0);
}

Пример корректного GCC-кода:

#include <stdio.h>

int
main()

{
    printf("HWcc!!\n");
    return 0;
}

### GCC-3.0 compiling
Попытка запустить сборку из исходников. В чистую 386 систему установлен пакет бинарей, в /sys/src/gnu/ape - ape-архив. Сорцы развернуты в примонтированном по НФС каталоге /n/vega/home/_vega9/_gcc3

В плановской консоли сначала необходимо запустить позикс-окружение командой
gnu/gsh
и затем уже пробовать, как указано в мануалах:
cd gcc-3.0
../p9config gcc-3.0
Выдаются ошибки:
mv: config.trash not a directory
*** cannot find move-if-change.
Причина в команде mv в файле move-if-change - она не считает дестинейшн директорией, хотя должна обрабатывать как файл. Пришлось поправить скрипт: позаменять строку mv -f $1 $2
на пару:
cp $1 $2
rm -f $1
Дальнейшие варнинги:
*** This configuration is not supported in the following subdirectories:
     target-libffi target-boehm-gc target-zlib target-libjava target-libf2c zlib fastjar target-libobjc
    (Any other directories should still work fine.)
mv: config.back not a directory
mv: Makefile not a directory
configure:1138
###                mv -f ${subdir}/config.status ${subdir}/config.back
                cp ${subdir}/config.status ${subdir}/config.back
                rm -f ${subdir}/config.status
configure:1229
###              "") mv ${subdir}/Makefile.tem ${Makefile} ;;
              "") cp ${subdir}/Makefile.tem ${Makefile}.
<------><------>    rm -f ${subdir}/Makefile.tem
<------><------>    ;;
configure:1240
###                              mv ${subdir}/Makefile.tem ${Makefile}
                              cp ${subdir}/Makefile.tem ${Makefile}
                              rm -f ${subdir}/Makefile.tem

Т.к. подобных замен много и в разных файлах, решено было сделать "алиас" /386/bin/gnu/mv:
#!/bin/sh

if [ $1 == '-f' ]; then
##	echo 'shifted'
	shift
	fi
echo '	MOVING' $1 ' => ' $2
cp $1 $2
rm -f $1
Также враппер убирает отсутствующий параметр -f
Подобные проблемы были описаны тута: https://comp.os.plan9.narkive.com/fCfVw4k2/9fans-building-gcc

.PHONY: all all.normal all-apache all-ash all-autoconf all-m4 all-libiberty all-m4 all-texinfo all-automake all-bash all-bfd all-intl all-binutils all-opcodes all-cgen all-opcodes all-flex all-bison all-byacc all-bzip2 all-cvssrc all-db all-dejagnu all-tcl all-expect all-tk all-diff all-dosutils all-etc all-fastjar all-zlib all-fileutils all-findutils all-find all-gas all-gawk all-gettext all-gnuserv all-gprof all-gprof all-grep all-grez all-gzip all-hello all-indent all-inet all-send-pr all-prms all-perl all-emacs19 all-ispell all-tcl8.1 all-ld all-libgui all-mmalloc all-release all-recode all-sed all-shellutils all-snavigator all-tgas all-time all-wdiff all-zip all-emacs all-gdb all-tix all-gash all-guile all-target-libstdc++-v3 all-target-newlib configure-target-newlib all-target-libgloss configure-target-libgloss all-target-libiberty configure-target-libiberty all-target-librx all-target-libf2c configure-target-libf2c all-target-libchill configure-target-libchill all-target-libobjc configure-target-libobjc 



### GCC-3.0 compiling - 2 попытка
Смысл p9config - задать имя архитектуры, некоторые переменные и затем запустить configure make. Поэтому для попыток собраться можно сразу использовать configure и make
Цель 2й попытки - поиграться со сборочным окружением, минимизировав изменение кода.

#### Внесенные изменения в среду
0. Для удобства пересборки и создания/чтения лога процесса создан скрипт bld:
#!/bin/sh
rm -f mylog.txt
make clean 2>&1 | tee -a mylog.txt
./configure --prefix /sys/lib/gnu --exec-prefix /386/bin/gnu --bindir /386/bin/gnu --datadir /sys/lib/gnu --includedir /sys/include/gnu --infodir /sys/lib/gnu/info --enable-languages=c,c++ --libdir /386/lib/gnu --libexecdir /386/bin/gnu/libexec --localstatedir /sys/lib/gnu --mandir /sys/lib/gnu/man --oldincludedir /sys/include/ape --sbindir /386/bin/gnu --sharedstatedir /sys/lib/gnu --sysconfdir /sys/lib/gnu --build i386-lucent-plan9 --host i386-lucent-plan9 --target i386-lucent-plan9 --enable-maintainer-mode 2>&1 | tee -a mylog.txt
### --disable-bootstrap
make -k 2>&1 | tee -a mylog.txt


1. Добавлен скрипт, обходящий отсутствие у штатного mv опции -i
cat /bin/gnu/mv
#!/bin/sh

if [ $1 == '-f' ] || [ $1 == '-i' ]; then
##	echo '	SHIFTED'
	shift
	fi
echo '	MOVING' $1 ' => ' $2
cp $1 $2
rm -f $1
##echo 'moved' $1 ' => ' $2

2. Каталог libiberty заменен на i386-lucent-plan9/libiberty (возможно зря - надо перепроаверить с ориг.), т.к. оригинальный ругался предположительно на более новый синтаксис.. i386-lucent-plan9/libiberty похоже в компиляции не участвовал и валялся как резерв/мусор..

3. Убран (переименован) fastjar - связан с джавой и вызывал доп.ошибки. После пеереименования мерестал находиться и подключаться. Но можно потом, в случае успешной компилляции, попробовать снова вернуть..

4. Подкорректированы типы в аргументах некоторых фций, убран (возм. необязательно было) старый K&R-стиль объявления:
libiberty/putenv.c:52
int
///putenv (string)
///     const char *string;
putenv (char* string)
{

libiberty/getopt.c:972
int
///getopt (argc, argv, optstring)
///     int argc;
///     char *const *argv;
///     const char *optstring;
getopt (int argc, char **argv,  char* optstring)
{

5. В системе заменен gnu/make (v.3.79.1)  на порт более свежего (v.3.82 from https://storage.googleapis.com/google-code-archive-downloads/v2/code.google.com/ports2plan9/gmake-3.82.pkg.tbz)

6. В систему добавлен (возм.зря - надо проверить со штатным) sed from https://storage.googleapis.com/google-code-archive-downloads/v2/code.google.com/ports2plan9/gsed-4.2.1b.tbz изза того что сборка ругалась на слишком большую входную строку.

7. Сборка захотела bison, которого нет и нет портированного. Зато нашелся https://storage.googleapis.com/google-code-archive-downloads/v2/code.google.com/ports2plan9/byacc-2011.12.19.pkg.tbz 
Добавлен скрипт для согласования формата ключей параметров:
cat /bin/gnu/bison
#!/bin/rc

PARAM=`{echo $*|sed 's/--name-prefix=/-l /'}
/bin/gnu/byacc $PARAM
echo '	BISON_INPUT=' $PARAM

#### Компиляция в изм.среде
Теперь вся сборка отрабатывает по командам
make clean
./configure
make
и доходит почти до окончательной сборки. Затык на стадии:

rm -rf libbackend.a
ar rc libbackend.a diagnostic.o version.o tree.o print-tree.o stor-layout.o fold-const.o function.o stmt.o except.o expr.o calls.o expmed.o explow.o optabs.o real.o builtins.o intl.o varasm.o rtl.o print-rtl.o rtlanal.o emit-rtl.o genrtl.o dbxout.o sdbout.o dwarfout.o dwarf2asm.o dwarf2out.o xcoffout.o bitmap.o alias.o gcse.o integrate.o jump.o cse.o loop.o doloop.o unroll.o flow.o combine.o varray.o regclass.o regmove.o local-alloc.o global.o reload.o reload1.o caller-save.o insn-peep.o reorg.o haifa-sched.o final.o recog.o reg-stack.o regrename.o insn-opinit.o insn-recog.o insn-extract.o insn-output.o insn-emit.o lcm.o profile.o insn-attrtab.o i386.o  convert.o mbchar.o splay-tree.o graph.o sbitmap.o resource.o hash.o predict.o lists.o ggc-common.o ggc-page.o stringpool.o simplify-rtx.o ssa.o bb-reorder.o sibcall.o conflict.o timevar.o ifcvt.o dominance.o dependence.o dce.o sched-vis.o sched-deps.o sched-rgn.o sched-ebb.o params.o
if [ -f ranlib ] || [ -f /usr/bin/ranlib -o -f /bin/ranlib ] ; then ranlib libbackend.a ; else true ; fi
i386-lucent-plan9-gcc  -DIN_GCC    -g -O2 -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wtraditional -pedantic -Wno-long-long  -DHAVE_CONFIG_H  -o cc1 \
	c-parse.o c-lang.o c-errors.o c-lex.o c-pragma.o c-decl.o c-typeck.o c-convert.o c-aux-info.o c-common.o c-format.o c-semantics.o c-dump.o libcpp.a  toplev.o libbackend.a obstack.o        ../libiberty/libiberty.a -lintl -lbsd 
c-lex.o: In function `parse_float':
/n/vega/home/_vega9/_gcc3/gcc-3.0/gcc/c-lex.c:953: undefined reference to `_errnoloc'
/n/vega/home/_vega9/_gcc3/gcc-3.0/gcc/c-lex.c:959: undefined reference to `_errnoloc'
libcpp.a(cppinit.o): In function `append_include_chain':
/n/vega/home/_vega9/_gcc3/gcc-3.0/gcc/cppinit.c:220: undefined reference to `_errnoloc'
libcpp.a(cppfiles.o): In function `open_file':
/n/vega/home/_vega9/_gcc3/gcc-3.0/gcc/cppfiles.c:213: undefined reference to `_errnoloc'
/n/vega/home/_vega9/_gcc3/gcc-3.0/gcc/cppfiles.c:269: undefined reference to `_errnoloc'
libcpp.a(cppfiles.o):/n/vega/home/_vega9/_gcc3/gcc-3.0/gcc/cppfiles.c:253: more undefined references to `_errnoloc' follow
collect2: ld returned 1 exit status
make[1]: *** [cc1] Error 1
make[1]: Leaving directory `/n/vega/home/_vega9/_gcc3/gcc-3.0/gcc'
make: *** [all-gcc] Error 2
$ 

_errnoloc находится только в скомпиленных обжектах, в сорцах gcc нету. По указанным местам в сорцах - errno
_errnoloc найден в: 
/sys/src/ape/lib/ap/386/main9.s:4
/sys/src/ape/lib/ap/386/main9.s:14
/sys/src/ape/lib/ap/386/main9p.s:4
/sys/src/ape/lib/ap/386/main9p.s:14
GLOBL _errnoloc(SB), $4
/sys/src/ape/lib/ap/plan9/_envsetup.c:22

Добавлено объявление 
int *_errnoloc; //Y
в:
gcc/c-lex.c
gcc/cppinit.c
gcc/cppfiles.c
После чего дело двинулось и дошло до аналогично ошибки но в 
gcc/tradcpp.c:4722
gcc/tradcpp.c:4776


На этой стадии сгенерился cc1 который и есть бинарь gcc (откликается на cc1 --version)
Пробная компиляция не проходит - выдает  suicide: sys: trap: fault write addr=0x0 pc=0x46498
возможно следствие вставки объявления int *_errnoloc; а может изза того что комплекс бинарей не установлен в систему и он обращается к файлам чужой инсталляции.

Но дальше снова та же ошибка (но это вероятно на стадии компиляции фортрана) в
libiberty/getpwd.c
После добпаления объявления и сюда, процесс идет чуть дальше, но заканчивается на:
/n/vega/home/_vega9/_gcc3/gcc-3.0/gcc/xgcc -B/n/vega/home/_vega9/_gcc3/gcc-3.0/gcc/ -B/usr/local/i386-unknown-plan9/bin/ -B/usr/local/i386-unknown-plan9/lib/ -isystem /usr/local/i386-unknown-plan9/include -S tmp-dum.c

xgcc: Cannot allocate 1686421503 bytes after allocating 16392 bytes
make[1]: *** [s-under] Error 1
make[1]: Leaving directory `/n/vega/home/_vega9/_gcc3/gcc-3.0/gcc'
make: *** [all-gcc] Error 2

тут xgcc тоже бинарь gcc и команда компилляции выдает аналогичную ошибку:
/usr/glenda/XLAM% /n/vega/home/_vega9/_gcc3/gcc-3.0/gcc/xgcc -B/n/vega/home/_vega9/_gcc3/gcc-3.0/gcc/ -B/usr/local/i386-unknown-plan9/bin/ -B/usr/local/i386-unknown-plan9/lib/ -isystem /usr/local/i386-unknown-plan9/include -S tmp-dum.c
xgcc 441160: suicide: sys: trap: fault read addr=0x0 pc=0x1090b

В силу ошибки с аллокацией памяти пробуем увеличить память ВМ с 1Гб до 2 Гб. Но выдает ту же ошибку аллокации памяти.

вот что пишут..
https://www.math.utah.edu/docs/info/gcc_10.html
On Solaris, the malloc function in the `libmalloc.a' library may allocate memory that is only 4 byte aligned. Since GNU CC on the Sparc assumes that doubles are 8 byte aligned, this may result in a fatal signal if doubles are stored in memory allocated by the `libmalloc.a' library. The solution is to not use the `libmalloc.a' library. Use instead malloc and related functions from `libc.a'; they do not have this problem.

Штатные дебугеры acid db с ненативным бинарем работать отказались, но в поставке gcc есть gdb, хотя толку от него оказалось не больше..

В свежеразвернутых сорцах начала наблюдаться новая ошибка в команде ../p9config gcc-3.0 
./configure --prefix /sys/lib/gnu --exec-prefix /386/bin/gnu --bindir /386/bin/gnu --datadir /sys/lib/gnu --includedir /sys/include/gnu --infodir /sys/lib/gnu/info --enable-languages=c,c++ --libdir /386/lib/gnu --libexecdir /386/bin/gnu/libexec --localstatedir /sys/lib/gnu --mandir /sys/lib/gnu/man --oldincludedir /sys/include/ape --sbindir /386/bin/gnu --sharedstatedir /sys/lib/gnu --sysconfdir /sys/lib/gnu --build i386-lucent-plan9 --host i386-lucent-plan9 --target i386-lucent-plan9 --enable-maintainer-mode
../p9config:110: ./configure: exec header invalid
В переменную config не захотел добавляться параметр --enable-maintainer-mode
Однако запуск результирующей ./configure пошел нормально 

Облегченная сборка - только С и С++ и без джавовских либ:
./configure --enable-languages=c,c++ --disable-libgcj - составлен скрипт bld, запускающий очистку, переконфигурирование и пересборку (конф строка из config.status):
#!/bin/sh
make clean
make clean
./configure --prefix /sys/lib/gnu --exec-prefix /386/bin/gnu --bindir /386/bin/gnu --datadir /sys/lib/gnu --includedir /sys/include/gnu --infodir /sys/lib/gnu/info --enable-languages=c,c++ --libdir /386/lib/gnu --libexecdir /386/bin/gnu/libexec --localstatedir /sys/lib/gnu --mandir /sys/lib/gnu/man --oldincludedir /sys/include/ape --sbindir /386/bin/gnu --sharedstatedir /sys/lib/gnu --sysconfdir /sys/lib/gnu --build i386-lucent-plan9 --host i386-lucent-plan9 --target i386-lucent-plan9 --enable-maintainer-mode
###--disable-bootstrap

Также надо отключить (переименованием) fastjar - непомогло
Попробовать отключить трехэтапную сборку --disable-bootstrap - также ошибки не обошлись

Добавление опций -lc -lgcc в /fastjar/Makefile не избавило от неуспеха сборки, но доходя до стадии xgcc, он теперь компилит простейший исходник который компилит без suicide и получающийся бинарь тоже отрабатывает без ошибки.
--rwxrwxrwx M 110 glenda glenda   123712 Jun 13 23:36 a.out
--rwxr-xr-x M 110 glenda glenda 10374697 Jun 13 23:26 cc1
--rwxr-xr-x M 110 glenda glenda   542665 Jun 13 20:27 cpp
--rwxr-xr-x M 110 glenda glenda   907186 Jun 13 23:27 cpp0
--rw-r--r-- M 110 glenda glenda       74 Jun 10 17:53 hw.c
--rwxr-xr-x M 110 glenda glenda   536219 Jun 13 20:26 xgcc
Бинари от автора порта:
--rwxr-xr-x M 110 glenda sys   524428 May 25 23:16 /bin/gnu/c++
--rwxr-xr-x M 110 glenda sys   312514 May 25 23:16 /bin/gnu/c++filt
--rwxr-xr-x M 110 glenda sys    55954 May 25 23:16 /bin/gnu/ccppc
--rwxr-xr-x M 110 glenda sys   524749 May 25 23:16 /bin/gnu/cpp
--rwxr-xr-x M 110 glenda sys   522399 May 25 23:16 /bin/gnu/gcc
Однако произошло нечт непонятное - как оказалось, добаленные опции терялись в момент конфигурирование и сборка шла как прежде. Но собранные бинари перестали отваливаться с ошибкой suicide, и начали компилить тестовые сорцы и норм.работать. Исследование выхлопа 
diff -crB /home/_vega9/gcc300/src/gcc-3.0 /home/_vega9/_gcc3/gcc-3.0 >gcc30.patch
не прояснило происходящее, вероятно чтото поменялось в системе (сборка лезет в /usr/include итп на стадии до инсталла). Сборка нормальных бинарей устойчива - эффект сохраняется и после перезагузки системы. Надо проаерить с откатом системы.
Собираемый gcc/fixinc/fixincl при запуске все равно выдает suicide нл это промежуточный тестовый бинарь и на дальнейшую сборку не влияет. Зато после него ошибка сборки:
echo timestamp > full-stamp
./fixincl -v < /dev/null
'fixincl version 1.1'
fixincl 16053: suicide: invalid address 0x0/4097 in sys call pc=0x15697
fixincl 16053: suicide: sys: bad address in syscall pc=0x15697
make[2]: *** [install-bin] Error 1
make[2]: Leaving directory /n/vega/home/_vega9/_gcc3/gcc-3.0/gcc/fixinc
make[1]: *** [fixinc.sh] Error 2
Это цель в gcc/fixinc/Makefile, она отваливается т.к. не найден gcc/fixinc.sh который генерится
gcc/fixinc/mkfixinc.sh
Там не был предусмотрен вариант сборки план9 - добавлено в 75 стр.:
<------>i?86-*-plan9 | \

Далее ошибка на стадии:

mv tmp-fixtmp.c fixtmp.c
	MOVING tmp-fixtmp.c  =>  fixtmp.c
/n/vega/home/_vega9/_gcc3/gcc-3.0/gcc/xgcc -B/n/vega/home/_vega9/_gcc3/gcc-3.0/gcc/ -B/386/bin/gnu/i386-lucent-plan9/bin/ -B/386/bin/gnu/i386-lucent-plan9/lib/ -isystem /386/bin/gnu/i386-lucent-plan9/include fixtmp.c -w -U__SIZE_TYPE__ -U__PTRDIFF_TYPE__ -U__WCHAR_TYPE__ -E \
  | sed -e 's/	/ /g' -e 's/ *(/ (/g' -e 's/ [ ]*/ /g' -e 's/( )/()/' \
  | ./gen-protos >xsys-protos.hT
gen-protos 26721: suicide: invalid address 0x2/8 in sys call pc=0x9363
gen-protos 26721: suicide: invalid address 0x2/8 in sys call pc=0x9363
gen-protos 26721: suicide: sys: bad address in syscall pc=0x9363
make[1]: *** [xsys-protos.h] Error 1
i386-lucent-plan9-gcc -c  -DIN_GCC    -g -O2 -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wtraditional -pedantic -Wno-long-long  -DHAVE_CONFIG_H -DGENERATOR_FILE    -I. -I. -I. -I./. -I./config -I./../include ./scan-decls.c

Не отрабатывала команда sed Строка заменена на
sed -e 's/	/ /g' -e 's/ *\(/ \(/g' -e 's/ [ ]*/ /g' -e 's/( )/()/'
(заэскейпены открывающие скобки во 2м реплейсе)
Ошибка не пропала, а запущеннная вручную:
/n/vega/home/_vega9/_gcc3/gcc-3.0/gcc/xgcc -B/n/vega/home/_vega9/_gcc3/gcc-3.0/gcc/ -B/386/bin/gnu/i386-lucent-plan9/bin/ -B/386/bin/gnu/i386-lucent-plan9/lib/ -isystem /386/bin/gnu/i386-lucent-plan9/include fixtmp.c -w -U__SIZE_TYPE__ -U__PTRDIFF_TYPE__ -U__WCHAR_TYPE__ -E | sed -e 's/	/ /g' -e 's/ *\(/ \(/g' -e 's/ [ ]*/ /g' -e 's/( )/()/'| ./gen-protos >xsys-protos.hT
генерит норм.файл, без suicide
Команда ./gen-protos >xsys-protos.hT при запуске вручную в родном шелле отрабатывает без suicide и формирует вроде как правильный файл (сохранен как  xsys-protos.hT_YYY). При запуске изпод gnu/gsh выдает suicide и генерит файл не похожий на рабочий.
В gen-protos.c:80,86 обработка ошибок с выдачей "Funny input line" и return 0
закоментаривание или return 1 не дает полож.рез. Видимо эти ретурны возвращаются мейку и он рапортует общую ошибку.
Надо убрать в мейкфайле весь вызов и разместить подмену ранее сгенеренного и бекапнутого xsys-protos.hT_YYY

Составлен скрипт gen-protosed:
#!/bin/rc
rfork En
/n/vega/home/_vega9/_gcc3/gcc-3.0/gcc/xgcc -B/n/vega/home/_vega9/_gcc3/gcc-3.0/gcc/ -B/386/bin/gnu/i386-lucent-plan9/bin/ -B/386/bin/gnu/i386-lucent-plan9/lib/ -isystem /386/bin/gnu/i386-lucent-plan9/include fixtmp.c -w -U__SIZE_TYPE__ -U__PTRDIFF_TYPE__ -U__WCHAR_TYPE__ -E  | sed -e 's/        / /g' -e 's/ *(/ (/g' -e 's/ [ ]*/ /g' -e 's/( )/()/'  | ./gen-protos >xsys-protos.hT
выполняющий обработку выхлопа корректно, в среде изолированного rc. Вызов скрипта заменяет соотв.строки в 
gcc/Makefile.in:2223-2225
на
    ./gen-protosed
После этого процесс сборки в каталоге gcc прошел до конца (но бинаря gcc все еще нет) и запустился конфигур в  libstdc++v3 И там ошибка:
checking for c++... (cached) i386-lucent-plan9-g++ -B/386/bin/gnu/i386-lucent-plan9/bin/ -B/386/bin/gnu/i386-lucent-plan9/lib/ -isystem /386/bin/gnu/i386-lucent-plan9/include
checking whether we are using GNU C++... (cached) no
checking for as... (cached) /386/bin/gnu/i386-lucent-plan9/as
checking for ar... (cached) ar
checking for ranlib... (cached) ranlib
checking for a BSD compatible install... /bin/install -c
checking whether to enable maintainer-specific portions of Makefiles... yes
./configure[1568]: .: ./../.././libstdc++-v3/configure.host: not found
make: *** [configure-target-libstdc++-v3] Error 1
Configuring in i386-lucent-plan9/libiberty
IGNORE no-such-file
IGNORE2 . .. CVS

В процессе сборки предварительно исчезает содержимое каталогов libiberty и libstdc++v3. Ошибка получается видимо от тог что не находятся удаленные файлы из этих каталогов. Проба - убрать атрибут записи для всех, со всех файлов в этих каталогах (только файлы, не каталоги).. Эффекта не дало - надо таки найти явную команду удаления..
POSSIBLY: libiberty/Makefile.in:216-234
Найти в мейкфайлах место удаления чрезвычайно сложно, т.к. оно может оказаться неявным. Вероятнее всего команда отдается из главного мейкфайла (после отработки i386-lucent-plan9/libiberty/Makefile где компилятся объекты и собираетс конечная libiberty.a). Совершалась попытка отследить действия команды удаления. Т.к. штатная не умеет выдавать инфу об удаляемом файле, пришлось сделать скрипт /bin/gnu/rm в котором перед удалением выводится содержимое входной переменной.. Однако неожиданно, скрипт почему то неправильно работает и уходит в зацикливание и переполнение буфера - по неизвестной причине. Поэтому пришлось сделать модифицированную копию /sys/src/cmd/rm.c, в которой после строки
		f = argv[i];
добавлена 
		fprint(2, "\tDBGREMOVING %s\n", f);
(вывод именно в 2 - stderr т.к. stdout считывался мейкфайлом и DBGREMOVING воспринималась как переменная, которая нигде не объявлена и вызывала сбой компилляции). Ее сборка/установка:
#!/bin/rc
rm -f *.[05678qv] [05678qv].out y.tab.? lex.yy.c y.debug y.output rm2 $CLEANFILES
8c rm.c
8l rm.8
mv 8.out /bin/gnu/rm
Запуск сборки GCC теперь:
bld 2>&1 | tee mylog.txt
По результатам изучения лога. Явные команды rm в мейкфайлах не делали ничего необычного, однако обнаружены многочисленные команды ln пытавиеся делать софтлинки файлов из libiberty и libstdc++v3. Реализация ln - иммитация софтлинкования копированием, однако там замечена отработка rm которая видимо и удаляла файлы. В скрипте /rc/bin/ape/ln нет команд rm. 
В gcc/configure:10168 есть проверка if test "$symbolic_link" = "ln -s"; then после чего идет софтлинковка и удаление. Попытка отключить поддержку софтлинков
configure:37-38,42-43 - закоммент переменных с командой и раскомент с неправильной командой
Не проканало - вернул назад и переименовываем /rc/bin/ape/ln в др.имя..
отбивается на нач.стадии, не находя команду. Надо искать правильный метод откл. софтлинка.

Похоже дело в скрипте symlink-tree:52 - там он после линковки удаляет исх.файлы.. Закоментарено..
Вроде продвижение дальше. Но:
/n/vega/home/_vega9/_gcc3/gcc-3.0/gcc/xgcc -B/n/vega/home/_vega9/_gcc3/gcc-3.0/gcc/ -B/386/bin/gnu/i386-lucent-plan9/bin/ -B/386/bin/gnu/i386-lucent-plan9/lib/ -isystem /386/bin/gnu/i386-lucent-plan9/include -c -DHAVE_CONFIG_H -g -I. -I./../../include  -W -Wall -Wtraditional -pedantic xstrerror.c
In file included from xstrerror.c:5:
/sys/include/gnu/stdio.h:9:20: std: No such file or directory
make[1]: *** [xstrerror.o] Error 1
В системном /sys/include/gnu/stdio.h инклудится несуществующий stdarg.h Он отсутствует и во всех архивах (Стаален видимо кросс-компилил из План-окружения, поднятом во Фре??). Так или иначе - сначала попробовать закомментить инклуд (NO!!) либо скопировать его из gcc/ginclude/stdarg.h Также можно (если 2й вар.проканает - добавить компилятору этот инклуд-путь
Ошибка все равно остается, хотя команда
/n/vega/home/_vega9/_gcc3/gcc-3.0/gcc/xgcc -B/n/vega/home/_vega9/_gcc3/gcc-3.0/gcc/ -B/386/bin/gnu/i386-lucent-plan9/bin/ -B/386/bin/gnu/i386-lucent-plan9/lib/ -isystem /386/bin/gnu/i386-lucent-plan9/include -c -DHAVE_CONFIG_H -g -I. -I./../../include  -W -Wall -Wtraditional -pedantic xstrerror.c
запущенная отдельно (из i386-lucent-plan9/libiberty) производит обж без ошибок. Решено добавлением явного инклуда в i386-lucent-plan9/libiberty/xstrerror.c (перед инклудом stdio.h):
#include <stdarg.h>

Дальнейшие проблемы начинаются после перехода в i386-lucent-plan9/libstdc++-v3 :
make[1]: Leaving directory '/n/vega/home/_vega9/_gcc3/gcc-3.0/i386-lucent-plan9/libiberty'
make[1]: Entering directory '/n/vega/home/_vega9/_gcc3/gcc-3.0/i386-lucent-plan9/libstdc++-v3'
cd . && autoheader
	DBGREMOVING /tmp/ac320340
autoheader: error: shell error while sourcing /tmp/ah320324/traces.sh
	DBGREMOVING /tmp/ah320324
make[1]: *** [stamp-h.in] Error 1

Дело было в /rc/bin/gnu/autoheader:189
mktemp в системе отсутствует, неудача генерации имени неправильно обрабатывается и врем.директория не создается. Далее скрипт:263 не создает $tmp/traces.sh (и неверно обрабатывает эту ошибку) и спотыкается (267) на попытке его запуска.
mktemp видимо не была портирована (ТУДУ: надо бы https://github.com/coreutils/coreutils/blob/master/src/mktemp.c https://elixir.bootlin.com/busybox/latest/source/coreutils/mktemp.c), поэтому временно :263 заменена на захардкордженное имя:
###tmp=`(umask 077 && mktemp -d -q "$TMPDIR/ahXXXXXX") 2>/dev/null` &&
###test -n "$tmp" && test -d "$tmp"
  tmp=$TMPDIR/ah$$
  (umask 077 && mkdir $tmp)
Также в 267 вставлена строка cat $tmp/traces.sh чтоб посмотреть какой файл туда пишется. Однако:
cd . && autoheader
CREATED /tmp/ah347296
total 1000
	DBGREMOVING /tmp/ac347316
CONTROL of /tmp/ah347296
configure.in:5: error: m4_file_append: cannot write: /tmp/ac347316/forbidden.rx
configure.in:5: the top level
total 1000
-rw-rw-rw- 1 glenda glenda 110 Jun 23 23:22 /tmp/ah347296/traces.sh
autoheader: error: shell error while sourcing /tmp/ah347296/traces.sh
	DBGREMOVING /tmp/ah347296
Замена umask 077 на umask 000

configure.in:5 - не смог заинклудить src/ios.cc - замена на $localdir/src/ios.cc в libstdc++-v3/configure.in:5 и i386-lucent-plan9/libstdc++-v3/configure.in:5

Далее "не смог" найти aclocal automake.. хотя они присуствуют в /rc/bin/gnu - проблема в отсутствии перла. Перл можно взять из бинарей для 4.5 или 4.8 Т.к. задействован вроде как минимальный функционал, добавлен лишь 1 бинарь /home/_vega9/_gcc4/gcc454bin/386/bin/gnu/perl 
automake захотел все же модулей, поэтому также скопирован и каталог /home/_vega9/_gcc4/gcc454bin/sys/lib/gnu/perl5/ 

cd . && aclocal
aclocal: couldn't open 'aclocal.m4' for writing: Permission denied
chmod a+w libstdc++-v3/*
chmod a+w i386-lucent-plan9/libstdc++-v3/*

Далее непонятная ошибка при отработке autoheader/aclocal. Их задача вроде как генерирование configure, который изначально уже присутствует, поэтому пробуем вообще убрать стадию перегенерации. Найти место оказалось сложно, но оно в i386-lucent-plan9/libstdc++-v3/Makefile.in:181
Также в процессе поиска были закомменчены gcc/Makefile.in:953 libf2c/libI77/Makefile.in:87 libf2c/libI77/Makefile.in:104 - их надо вернуть потом. Также вернуть исх. копии autoheader/aclocal

Следующие многочисленные ошибки..
Для компилятора i386-lucent-plan9-g++  установлен параметр -Werror и 
cc1plus: warnings being treated as errors
убран в i386-lucent-plan9/configure:4901

automake: configure.in: required file '../install-sh' not found
automake: configure.in: required file '../mkinstalldirs' not found
automake: configure.in: required file '../missing' not found
таки нету..
added to i386-lucent-plan9/libstdc++-v3/configure:605 : 
ac_install_sh="$srcdir/install.sh -c"

modified i386-lucent-plan9/libstdc++-v3/Makefile.in:119
mkinstalldirs = $(SHELL) $(srcdir)/mkinstalldirs

modified i386-lucent-plan9/libstdc++-v3/configure:981 : 
missing_dir=`cd $srcdir && pwd`


automake: libsupc++/Makefile.in: cannot write: Permission denied
Во всех поддиректориях i386-lucent-plan9/libstdc++-v3/ файлы без права на запись и не могут переписаться - 
делаем в них chmod a+w *

../include/c_std/bits/std_cwchar.h:42:24: wchar.h: No such file or directory
Присутсвует в  i386-lucent-plan9/libstdc++-v3/include/c_shadow
Добавлен путь к инклуду в i386-lucent-plan9/libstdc++-v3/configure:1301 :
  test "${CXXFLAGS+set}" = set || CXXFLAGS="-I$(GLIBCPP_INCLUDE_DIR)/c_shadow -g"
НЕ увиден - вернуть и прписать гдето а др.месте. либо откл. в i386-lucent-plan9/libstdc++-v3/include/bits/c++config.h
^^^-NO_EFFECT - 2RETURN. maybe touch zero-size *.h
i386-lucent-plan9/libstdc++-v3/include/bits/c++config.h is generated by i386-lucent-plan9/libstdc++-v3/mkc++config from  config.h (which generated from config.h.in) - need to make changes in config.h.in -DONE:
#define _GLIBCPP_HAVE_ENDIAN_H 1
#define _GLIBCPP_HAVE_FP_H 1
#define _GLIBCPP_HAVE_IEEEFP_H 1
#define _GLIBCPP_HAVE_MACHINE_ENDIAN_H 1
#define _GLIBCPP_HAVE_NAN_H 1
#define _GLIBCPP_HAVE_SYS_MACHINE_H 1

In file included from copysignf.c:32:
mathconf.h:34:21: endian.h: No such file or directory
mathconf.h:76:18: nan.h: No such file or directory
mathconf.h:85:21: ieeefp.h: No such file or directory
mathconf.h:89:17: fp.h: No such file or directory
In file included from copysignf.c:32:
mathconf.h:169: conflicting types for 'ieee_double_shape_type'
mathconf.h:158: previous declaration of 'ieee_double_shape_type'
mathconf.h:218: conflicting types for 'ieee_long_double_shape_type'
mathconf.h:205: previous declaration of 'ieee_long_double_shape_type'
mathconf.h:256: conflicting types for 'ieee_quad_double_shape_type'
mathconf.h:241: previous declaration of 'ieee_quad_double_shape_type'
^^^ушло после отключения дефайнов (см выше)


(cd .libs && rm -f libsupc++convenience.la && ln -s ../libsupc++convenience.la libsupc++convenience.la)
	DBGREMOVING libsupc++convenience.la
/bin/ln:18: test: '-L' directory entry not found
/bin/ln:23: cp: '-L' directory entry not found
make[3]: *** [libsupc++convenience.la] Error 1

/rc/bin/ape/ln - добавлен обработчик параметра -L
	switch($1){
	case -L
		shift
also commands `test` and `cp` replaced with full path of ones (/bin/test /bin/cp)

mkdir .libs/libstdc++.lax/libsupc++convenience.a
(cd .libs/libstdc++.lax/libsupc++convenience.a && ar x /n/vega/home/_vega9/_gcc3/gcc-3.0/i386-lucent-plan9/libstdc++-v3/src/../libsupc++/.libs/libsupc++convenience.a)
../libtool: find: not found

`find` is absent both system and APE/GNU..
A 4.5.4-bin package has 386/bin/gnu/find2perl
It understand all params of `find` and generates as output the perl script that could find all set with params.. Need to write script /rc/bin/gnu/find that take params, generate tmp file, run it, return its output, del tmp file..

Создан скрипт /rc/bin/gnu/find
#!/bin/sh
/bin/gnu/find2perl $@ > /tmp/findtmp.pl
chmod a+x /tmp/findtmp.pl
exec /tmp/findtmp.pl
rm -f /tmp/findtmp.pl

Также была ошибка в модуле /sys/lib/gnu/perl5/lib/5.14.2/i386-plan9/Cwd.pm:342 не отрабатывался поиск команды pwd - захардкоджен плановский путь, а цикл поиска закомментарен.

Продвижение чуть дальше. Дальнейшие ошибки - гдето недособран bitset.o (однако присутствует i386-lucent-plan9/libstdc++-v3/src/bitset.o)
mkdir .libs
rm -fr .libs/libstdc++.lax
	DBGREMOVING .libs/libstdc++.lax
mkdir .libs/libstdc++.lax
rm -fr .libs/libstdc++.lax/libmath.a
	DBGREMOVING .libs/libstdc++.lax/libmath.a
mkdir .libs/libstdc++.lax/libmath.a
(cd .libs/libstdc++.lax/libmath.a && ar x /n/vega/home/_vega9/_gcc3/gcc-3.0/i386-lucent-plan9/libstdc++-v3/src/../libmath/.libs/libmath.a)
Unrecognized switch: bitset.o
rm -fr .libs/libstdc++.lax/libsupc++convenience.a
	DBGREMOVING .libs/libstdc++.lax/libsupc++convenience.a
mkdir .libs/libstdc++.lax/libsupc++convenience.a
(cd .libs/libstdc++.lax/libsupc++convenience.a && ar x /n/vega/home/_vega9/_gcc3/gcc-3.0/i386-lucent-plan9/libstdc++-v3/src/../libsupc++/.libs/libsupc++convenience.a)
Unrecognized switch: bitset.o
ar cru .libs/libstdc++.a  limitsMEMBERS.o stdexcept.o functexcept.o bitset.o globals.o basic_file.o ios.o complex_io.o strstream.o c++locale.o locale.o localename.o codecvt.o locale-inst.o stl-inst.o misc-inst.o valarray-inst.o string-inst.o wstring-inst.o  
ranlib .libs/libstdc++.a
rm -fr .libs/libstdc++.lax
	DBGREMOVING .libs/libstdc++.lax
creating libstdc++.la
	DBGREMOVING libstdc++.la
	DBGREMOVING .libs/libstdc++.lai
(cd .libs && rm -f libstdc++.la && ln -s ../libstdc++.la libstdc++.la)
	DBGREMOVING libstdc++.la
make[3]: Leaving directory '/n/vega/home/_vega9/_gcc3/gcc-3.0/i386-lucent-plan9/libstdc++-v3/src'

libtool (3510 3751 4530) перегенеривается из ltmain.sh (3186 3427 4206)

После распаковки (ar x /n/vega/home/_vega9/_gcc3/gcc-3.0/i386-lucent-plan9/libstdc++-v3/src/../libsupc++/.libs/libsupc++convenience.a) в директории не оказывалось bitset.o который был собран и присутствовал в i386-lucent-plan9/libstdc++-v3/src Добавлены строки (ltmain.sh:4204-4205), подкидывающая либу:
echo "<>DBG:COPYING bitset.o => $xabs"
cp bitset.o $xabs

После этого начала (??) неправильно собираться i386-lucent-plan9/libstdc++-v3/libmath/.libs/libmath.a
mkdir .libs/libstdc++.lax/libmath.a
    DBG:COPYING bitset.o => /n/vega/home/_vega9/_gcc3/gcc-3.0/i386-lucent-plan9/libstdc++-v3/src/../libmath/.libs/libmath.a
(cd .libs/libstdc++.lax/libmath.a && ar x /n/vega/home/_vega9/_gcc3/gcc-3.0/i386-lucent-plan9/libstdc++-v3/src/../libmath/.libs/libmath.a)
DBG_libtool:4530 from ltmain.sh:4206

x: File format not recognized
make[3]: *** [libstdc++.la] Error 1

Действительно, по смещению 0x00 сигнатура 0x00 0x64 вместо !<arch> как у др. *.a (в т.ч. i386-lucent-plan9/libstdc++-v3/libsupc++/.libs/libsupc++.a  и там же  libsupc++convenience.a)

Команды
cd  /n/vega/home/_vega9/_gcc3/gcc-3.0/i386-lucent-plan9/libstdc++-v3/libmath/
/bin/sh ../libtool --mode=link "i386-lucent-plan9-gcc -B/386/bin/gnu/i386-lucent-plan9/bin/ -B/386/bin/gnu/i386-lucent-plan9/lib/ -isystem /386/bin/gnu/i386-lucent-plan9/include"  -g  -o libmath.la   signbit.lo signbitf.lo nan.lo hypotf.lo atan2f.lo expf.lo copysignf.lo
однако производят корректную библиотеку.. Без изм.пути (находясь в i386-lucent-plan9/libstdc++-v3/src) ругалось:
libtool: link: 'signbit.lo' is not a valid libtool object
Возм. дело в не смененном пути..

Сработали проставленные метки
(cd .libs && rm -f libsupc++.la && ln -s ../libsupc++.la libsupc++.la)
	DBG_ltmain.sh:4408 CD RM LN
норм.собрана
(cd .libs && rm -f libsupc++convenience.la && ln -s ../libsupc++convenience.la libsupc++convenience.la)
	DBG_ltmain.sh:4408 CD RM LN
	DBGREMOVING libsupc++convenience.la
норм.собрана


	DBGREMOVING libmath.la
(cd .libs && rm -f libmath.la && ln -s ../libmath.la libmath.la)
	DBG_ltmain.sh:4408 CD RM LN
гораздо выше по логу.. не нормально собрана

i386-lucent-plan9/libstdc++-v3/libmath/Makefile:223
правило сборки libmath.la 
libmath.la: $(libmath_la_OBJECTS) $(libmath_la_DEPENDENCIES)
<------>$(LINK)  $(libmath_la_LDFLAGS) $(libmath_la_OBJECTS) $(libmath_la_LIBADD) $(LIBS)

i386-lucent-plan9/libstdc++-v3/libsupc++/Makefile:321-325 сборка libsupc++convenience.la и libsupc++.la
libsupc++convenience.la: $(libsupc__convenience_la_OBJECTS) $(libsupc__convenience_la_DEPENDENCIES)
<------>$(CXXLINK)  $(libsupc__convenience_la_LDFLAGS) $(libsupc__convenience_la_OBJECTS) $(libsupc__convenience_la_LIBA
libsupc++.la: $(libsupc___la_OBJECTS) $(libsupc___la_DEPENDENCIES)
<------>$(CXXLINK) -rpath $(toolexeclibdir) $(libsupc___la_LDFLAGS) $(libsupc___la_OBJECTS) $(libsupc___la_LIBADD) 

cd i386-lucent-plan9/libstdc++-v3/libmath
make -kB libmath.la
дает норм.либу

При этом на стадии исполнения ltmain.sh:4408 уже имеется правильная либа (18054 б), которая потом переписывается некорректной версией (133973 б). Надо либо найти место пересборки, либо бекапить и потом подставлять ее.
    

Причиной оказался "выстрел в ногу" - добавленный костыль cp bitset.o по ошибке в путях записывался в файл .libs/libmath.a затирая собой правильно собранную либу. Заменено в ltmain.sh:4206 на
cp bitset.o ../libmath/bitset.o
Также убран за ненадобностью котыль в ltmain.sh:4410 (бекап удачно собранной libmath.a)

Теперь все собирается и даже без ошибок. Однако мейк останавливается на той же стадии что и при предыдущих ошибках
make[4]: Entering directory `/n/vega/home/_vega9/_gcc3/gcc-3.0/i386-lucent-plan9/libstdc++-v3'
if [ -z "" ]; then \
.......
fi
make[4]: Leaving directory `/n/vega/home/_vega9/_gcc3/gcc-3.0/i386-lucent-plan9/libstdc++-v3'
make[3]: Leaving directory `/n/vega/home/_vega9/_gcc3/gcc-3.0/i386-lucent-plan9/libstdc++-v3'
make[2]: Leaving directory `/n/vega/home/_vega9/_gcc3/gcc-3.0/i386-lucent-plan9/libstdc++-v3'
make[1]: Leaving directory `/n/vega/home/_vega9/_gcc3/gcc-3.0/i386-lucent-plan9/libstdc++-v3'
$ 
Файл gcc/gcc не появляется и похоже что сборка все же не достигает финала.
gcc/Makefile:1341 - xgcc - временное имя gcc (чттоб избегать конфликтов с именем каталога) и в момент инсталла переименуется (gcc/Makefile:2944).

Теперь надо заснапшотить ВМ и попробовать сделать make install


## make install
chmod a+w gcc/doc/*
В остальном инсталл прошел успешно, в результате в системе поменялся бинарь на свежесобранный (проверка пока лишь по gcc -v). Компилится и запускается простейший хелловорд.
ls -l /n/vega/home/_vega9/gcc300/bin/386/bin/gnu/gcc
-rwxr-xr-x 1 0 0 522399 Apr 25  2002 /n/vega/home/_vega9/gcc300/bin/386/bin/gnu/gcc
ls -l /bin/gnu/gcc
-rwxr-xr-x 1 glenda sys 573289 Jul  6 00:25 /bin/gnu/gcc

Последующая пересборка начала в конце выдавать
/bin/sh ../libtool --tag CXX --mode=link i386-lucent-plan9-g++ -B/386/bin/gnu/i386-lucent-plan9/bin/ -B/386/bin/gnu/i386-lucent-plan9/lib/ -isystem /386/bin/gnu/i386-lucent-plan9/include 	    -fno-implicit-templates 	 	-Wall -Wno-format -W -Wwrite-strings -Winline  -fdiagnostics-show-location=once 	 	-g    -o libstdc++.la -rpath /386/lib/gnu -version-info 3:0:0 -lm limitsMEMBERS.lo stdexcept.lo functexcept.lo bitset.lo globals.lo basic_file.lo ios.lo complex_io.lo strstream.lo c++locale.lo locale.lo localename.lo codecvt.lo locale-inst.lo stl-inst.lo misc-inst.lo valarray-inst.lo string-inst.lo wstring-inst.lo ../libmath/libmath.la  	../libsupc++/libsupc++convenience.la 
mkdir .libs
../libtool: internal error: alloc: freeing memory outside of block (corrupted?)
make[3]: Leaving directory `/n/vega/home/_vega9/_gcc3/gcc-3.0/i386-lucent-plan9/libstdc++-v3/src'

Других ошибок вроде нет..
Сообщение найдено лишь в сорцах оболочки /sys/src/ape/cmd/pdksh/alloc.c:345
Однако libstdc++.la не создается. 
Отключение проверки границ аллокейшна памяти (принудительное допущение утечки памяти) также не приводит к сборке либы в конечном итоге.    
Данная ошибка потом начинает проявляться и при make install (там еще раз пересобирается libsupc++convenience.la) и на ней последующая make install уже начинает отбиваться (не достигается строка  Libraries have been installed in:) но копирование в сис.директории все равно происходит.

Проблема видимо в ../libsupc++/libsupc++convenience.la (только в случае без нее не выдется эта ошибка и собирается libstdc++.la), хотя сама либа собралась без ошибок:
/bin/sh ../libtool --tag CXX --tag disable-shared           --mode=link i386-lucent-plan9-g++ -B/386/bin/gnu/i386-lucent-plan9/bin/ -B/386/bin/gnu/i386-lucent-plan9/lib/ -isystem /386/bin/gnu/i386-lucent-plan9/include             -fno-implicit-templates 	 	-Wall -Wno-format -W -Wwrite-strings -Winline  -fdiagnostics-show-location=once 	 	-g    -o libsupc++convenience.la   del_op.lo del_opnt.lo del_opv.lo del_opvnt.lo eh_alloc.lo eh_aux_runtime.lo eh_catch.lo eh_exception.lo eh_globals.lo eh_personality.lo eh_terminate.lo eh_throw.lo new_handler.lo new_op.lo new_opnt.lo new_opv.lo new_opvnt.lo pure.lo tinfo.lo tinfo2.lo vec.lo  
mkdir .libs
ar cru .libs/libsupc++convenience.a  del_op.o del_opnt.o del_opv.o del_opvnt.o eh_alloc.o eh_aux_runtime.o eh_catch.o eh_exception.o eh_globals.o eh_personality.o eh_terminate.o eh_throw.o new_handler.o new_op.o new_opnt.o new_opv.o new_opvnt.o pure.o tinfo.o tinfo2.o vec.o
ranlib .libs/libsupc++convenience.a

Выяснено методом послед.исключения, что дело не в подключаемых *.o *.lo

Проставлением эхо-меток в i386-lucent-plan9/libstdc++-v3/libtool:2728 определено, что исполнение кода доходит до конца блока 
do..done #for pass
после чего метка не появляется, а только ошибка.

замена в 2725 deplibs new_libs дает сборку без ошибок. Возм. поковырять содержимое deplibs. А оно оказалось таким:
../libsupc++/libsupc++convenience.la -L/sys/lib/gnu/i386-lucent-plan9/lib -L/386/lib/gnu -lstdc++ -lgcc -lc -lgcc -lstdc++ -lgcc -lc -lgcc -lstdc++ -lgcc -lc -lgcc -lstdc++ -lgcc -lc -lgcc -lgcc -lc -lgcc -lstdc++ -lgcc -lc -lgcc -lstdc++ -lgcc -lc -lgcc -lgcc -lc -lgcc -lgcc -lc -lgcc -lstdc++ -lgcc -lc -lgcc -lstdc++ -lgcc -lc -lgcc -lgcc -lc -lgcc -lgcc -lc -lgcc -lstdc++ -lgcc -lc -lgcc -lstdc++ -lgcc -lc -lgcc -lstdc++ -lgcc -lc -lgcc -lstdc++ -lgcc -lc -lgcc -lgcc -lc -lgcc -lstdc++ -lgcc -lc -lgcc -lstdc++ -lgcc -lc -lgcc -lgcc -lc -lgcc -lgcc -lc -lgcc -lstdc++ -lgcc -lc -lgcc -lstdc++ -lgcc -lc -lgcc -lgcc -lc -lgcc -lgcc -lc -lgcc -lstdc++ -lgcc -lc -lgcc -lstdc++ -lgcc -lc -lgcc -lstdc++ -lgcc -lc -lgcc -lstdc++ -lgcc -lc -lgcc -lgcc -lc -lgcc -lstdc++ -lgcc -lc -lgcc -lstdc++ -lgcc -lc -lgcc -lgcc -lc -lgcc -lgcc -lc -lgcc -lstdc++ -lgcc -lc -lgcc -lstdc++ -lgcc -lc -lgcc -lgcc -lc -lgcc -lgcc -lc -lgcc -lstdc++ -lgcc -lc -lgcc -lstdc++ -lgcc -lc -lgcc -lstdc++ -lgcc -lc -lgcc -lstdc++ -lgcc -lc -lgcc -lgcc -lc -lgcc -lstdc++ -lgcc -lc -lgcc -lstdc++ -lgcc -lc -lgcc -lgcc -lc -lgcc -lgcc -lc -lgcc -lstdc++ -lgcc -lc -lgcc -lstdc++ -lgcc -lc -lgcc -lgcc -lc -lgcc -lgcc -lc -lgcc -lgcc -lc -lgcc -lstdc++ -lgcc -lc -lgcc -lstdc++ -lgcc -lc -lgcc -lstdc++ -lgcc -lc -lgcc -lstdc++ -lgcc -lc -lgcc -lgcc -lc -lgcc -lstdc++ -lgcc -lc -lgcc -lstdc++ -lgcc -lc -lgcc -lgcc -lc -lgcc -lgcc -lc -lgcc -lstdc++ -lgcc -lc -lgcc -lstdc++ -lgcc -lc -lgcc -lgcc -lc -lgcc -lgcc -lc -lgcc -lstdc++ -lgcc -lc -lgcc -lstdc++ -lgcc -lc -lgcc -lstdc++ -lgcc -lc -lgcc -lstdc++ -lgcc -lc -lgcc -lgcc -lc -lgcc -lstdc++ -lgcc -lc -lgcc -lstdc++ -lgcc -lc -lgcc -lgcc -lc -lgcc -lgcc -lc -lgcc -lstdc++ -lgcc -lc -lgcc -lstdc++ -lgcc -lc -lgcc -lgcc -lc -lgcc -lgcc -lc -lgcc -lgcc -lc -lgcc -lgcc -lc -lgcc -lstdc++ -lgcc -lc -lgcc -lstdc++ -lgcc -lc -lgcc -lstdc++ -lgcc -lc -lgcc -lstdc++ -lgcc -lc -lgcc -lgcc -lc -lgcc -lstdc++ -lgcc -lc -lgcc -lstdc++ -lgcc -lc -lgcc -lgcc -lc -lgcc -lgcc -lc -lgcc -lstdc++ -lgcc -lc -lgcc -lstdc++ -lgcc -lc -lgcc -lgcc -lc -lgcc -lstdc++ -lgcc -lc -lgcc -lstdc++ -lgcc -lc -lgcc -lstdc++ -lgcc -lc -lgcc -lstdc++ -lgcc -lc -lgcc -lgcc -lc -lgcc -lstdc++ -lgcc -lc -lgcc -lstdc++ -lgcc -lc -lgcc -lgcc -lc -lgcc -lgcc -lc -lgcc -lstdc++ -lgcc -lc -lgcc -lstdc++ -lgcc -lc -lgcc -lgcc -lc -lgcc -lgcc -lc -lgcc -lstdc++ -lgcc -lc -lgcc -lstdc++ -lgcc -lc -lgcc -lstdc++ -lgcc -lc -lgcc -lstdc++ -lgcc -lc -lgcc -lgcc -lc -lgcc -lstdc++ -lgcc -lc -lgcc -lstdc++ -lgcc -lc -lgcc -lgcc -lc -lgcc -lgcc -lc -lgcc -lstdc++ -lgcc -lc -lgcc -lstdc++ -lgcc -lc -lgcc -lgcc -lc -lgcc -lgcc -lc -lgcc -lgcc -lc -lgcc -lgcc -lc -lgcc -lstdc++ -lgcc -lc -lgcc -lstdc++ -lgcc -lc -lgcc -lstdc++ -lgcc -lc -lgcc -lstdc++ -lgcc -lc -lgcc -lgcc -lc -lgcc -lstdc++ -lgcc -lc -lgcc -lstdc++ -lgcc -lc -lgcc -lgcc -lc -lgcc -lgcc -lc -lgcc /386/lib/gnu/libstdc++.la -lm -lstdc++ -lgcc -lc -lgcc -lstdc++ -lgcc -lc -lgcc -lgcc -lc -lgcc -lgcc -lc -lgcc -lgcc -lc -lgcc -lstdc++ -lgcc -lc -lgcc
    
Убирание повторов эффекта не имело.

Также отмечено, что в системе в /386/lib/gnu/ оставались старые либы (libgcc.a итд), которые видимо линковались в собираемые либы gcc. make install не перезаписал их, однако выявил что либы должны копироваться в /386/lib/gnu/gcc-lib/i386-lucent-plan9/3.0/, но этого не происходит. Сделан chmod +w эффекта не имело.

Пересборка (libtool && ar cru) libsupc++convenience с последовательным убиранием объектов эффекта не дала.
Далее пересборка libtool libstdc++.la даже без объектов: 
/bin/sh ../libtool --tag CXX --mode=link i386-lucent-plan9-g++ -B/386/bin/gnu/i386-lucent-plan9/bin/ -B/386/bin/gnu/i386-lucent-plan9/lib/ -isystem /386/bin/gnu/i386-lucent-plan9/include 	    -fno-implicit-templates 	 	-Wall -Wno-format -W -Wwrite-strings -Winline  -fdiagnostics-show-location=once 	 	-g    -o libstdc++.la -rpath /386/lib/gnu -version-info 3:0:0 ../libmath/libmath.la  	../libsupc++/libsupc++convenience.la     
дает ошибку - только убирание ../libsupc++/libsupc++convenience.la

Проверим как собирается весь GCC из изначальных бинарей,либ (до того как они заменялись свежесобранными и возм.начали вызывать ошибку)
virsh snapshot-list --domain v9t386
 Имя               Время создания Статус
------------------------------------------------------------
 2023_07_06_Works     2023-07-06 02:29:17 +0300 running
 4.06.2023_Works      2023-06-04 00:41:49 +0300 running

## Создание снапшота ВМ на текущий момент:

virsh snapshot-create-as --domain v9t386 --name "2023_07_09_Works" --description "after make install, trying fix errors (probably all returned back)" 
Переключаемся на предыдущий (2023_07_06_Works)
virsh snapshot-revert --domain v9t386 --snapshotname 2023_07_06_Works --running
С предыдущим снапшотом ошибки нет, либа создается
ls -l /home/_vega9/_gcc3/gcc-3.0/i386-lucent-plan9/libstdc++-v3/src/.libs
итого 2968
-rw-r--r-- 1 nfsnobody nfsnobody 3027930 июл  9 07:54 libstdc++.a
-rw-r--r-- 1 nfsnobody nfsnobody    3604 июл  9 07:54 libstdc++.la
-rw-r--r-- 1 nfsnobody nfsnobody    3603 июл  9 07:54 libstdc++.lai
ls -l /386/lib/gnu/gcc-lib/i386-lucent-plan9/3.0/libgcc.a 
--rw-r--r-- M 112 glenda sys 1110620 May 25 23:17 /386/lib/gnu/gcc-lib/i386-lucent-plan9/3.0/libgcc.a
diff лога с логом при ошибке - не выявил отклонений при сборке причастных объектов.
2я пересборка также без ошибок, дифф дога с 1й одинаков.
Исх. либы:
term% ls -l /386/lib/gnu/
--rw-r--r-- M 112 glenda sys     192 May 25 23:17 /386/lib/gnu/charset.alias
--rw-r--r-- M 112 glenda sys     210 Jun 12 12:01 /386/lib/gnu/crt0.o
d-rwxr-xr-x M 112 glenda sys       0 May 25 23:17 /386/lib/gnu/gcc-lib
--rw-r--r-- M 112 glenda sys    2596 Jun 12 12:01 /386/lib/gnu/lib9.a
--rw-r--r-- M 112 glenda sys  222578 Jun 12 12:01 /386/lib/gnu/libap.a
--rw-r--r-- M 112 glenda sys 1430466 May 25 23:17 /386/lib/gnu/libbfd.a
--rwxr-xr-x M 112 glenda sys     648 May 25 23:17 /386/lib/gnu/libbfd.la
--rw-r--r-- M 112 glenda sys   36192 May 25 23:17 /386/lib/gnu/libbsd.a
--rw-r--r-- M 112 glenda sys  222578 Jun 12 12:01 /386/lib/gnu/libc.a
--rw-r--r-- M 112 glenda sys   98992 Jun 12 12:01 /386/lib/gnu/libdraw.a
--rw-r--r-- M 112 glenda sys   36200 Jun 12 12:01 /386/lib/gnu/libfmt.a
--rw-r--r-- M 112 glenda sys 1127238 May 25 23:17 /386/lib/gnu/libgcc.a
--rw-r--r-- M 112 glenda sys  380630 May 25 23:17 /386/lib/gnu/libiberty.a
--rw-r--r-- M 112 glenda sys  128106 May 25 23:17 /386/lib/gnu/libintl.a
--rw-r--r-- M 112 glenda sys     600 May 25 23:17 /386/lib/gnu/libintl.la
--rw-r--r-- M 112 glenda sys    2976 Jun 12 12:01 /386/lib/gnu/libl.a
--rw-r--r-- M 112 glenda sys    5332 Jun 12 12:01 /386/lib/gnu/libnet.a
--rw-r--r-- M 112 glenda sys  241802 May 25 23:17 /386/lib/gnu/libopcodes.a
--rwxr-xr-x M 112 glenda sys     660 May 25 23:17 /386/lib/gnu/libopcodes.la
--rw-r--r-- M 112 glenda sys   13368 Jun 12 12:01 /386/lib/gnu/libregexp.a
--rw-r--r-- M 112 glenda sys 3249148 May 25 23:17 /386/lib/gnu/libstdc++.a
--rw-r--r-- M 112 glenda sys 1791230 May 25 23:17 /386/lib/gnu/libstdc++.a.2.10.0
--rwxr-xr-x M 112 glenda sys    1003 May 25 23:17 /386/lib/gnu/libstdc++.la
--rw-r--r-- M 112 glenda sys  199782 May 25 23:17 /386/lib/gnu/libsupc++.a
--rwxr-xr-x M 112 glenda sys     805 May 25 23:17 /386/lib/gnu/libsupc++.la
--rw-r--r-- M 112 glenda sys   15704 Jun 12 12:01 /386/lib/gnu/libutf.a
--rw-r--r-- M 112 glenda sys    4756 Jun 12 12:01 /386/lib/gnu/libv.a
ls -l /386/lib/gnu/gcc-lib/i386-lucent-plan9/3.0/libgcc.a 
--rw-r--r-- M 112 glenda sys 1110620 May 25 23:17 /386/lib/gnu/gcc-lib/i386-lucent-plan9/3.0/libgcc.a

1й make install (mki_1.txt)
ls -l /386/lib/gnu/
--rw-r--r-- M 112 glenda sys     192 May 25 23:17 /386/lib/gnu/charset.alias
--rw-r--r-- M 112 glenda sys     210 Jun 12 12:01 /386/lib/gnu/crt0.o
d-rwxr-xr-x M 112 glenda sys       0 May 25 23:17 /386/lib/gnu/gcc-lib
--rw-r--r-- M 112 glenda sys    2596 Jun 12 12:01 /386/lib/gnu/lib9.a
--rw-r--r-- M 112 glenda sys  222578 Jun 12 12:01 /386/lib/gnu/libap.a
--rw-r--r-- M 112 glenda sys 1430466 May 25 23:17 /386/lib/gnu/libbfd.a
--rwxr-xr-x M 112 glenda sys     648 May 25 23:17 /386/lib/gnu/libbfd.la
--rw-r--r-- M 112 glenda sys   36192 May 25 23:17 /386/lib/gnu/libbsd.a
--rw-r--r-- M 112 glenda sys  222578 Jun 12 12:01 /386/lib/gnu/libc.a
--rw-r--r-- M 112 glenda sys   98992 Jun 12 12:01 /386/lib/gnu/libdraw.a
--rw-r--r-- M 112 glenda sys   36200 Jun 12 12:01 /386/lib/gnu/libfmt.a
--rw-r--r-- M 112 glenda sys 1127238 May 25 23:17 /386/lib/gnu/libgcc.a
--rw-r--r-- M 112 glenda sys  400722 Jul  9 08:21 /386/lib/gnu/libiberty.a
--rw-r--r-- M 112 glenda sys  128106 May 25 23:17 /386/lib/gnu/libintl.a
--rw-r--r-- M 112 glenda sys     600 May 25 23:17 /386/lib/gnu/libintl.la
--rw-r--r-- M 112 glenda sys    2976 Jun 12 12:01 /386/lib/gnu/libl.a
--rw-r--r-- M 112 glenda sys    5332 Jun 12 12:01 /386/lib/gnu/libnet.a
--rw-r--r-- M 112 glenda sys  241802 May 25 23:17 /386/lib/gnu/libopcodes.a
--rwxr-xr-x M 112 glenda sys     660 May 25 23:17 /386/lib/gnu/libopcodes.la
--rw-r--r-- M 112 glenda sys   13368 Jun 12 12:01 /386/lib/gnu/libregexp.a
--rw-r--r-- M 112 glenda sys 3027930 Jul  9 05:21 /386/lib/gnu/libstdc++.a
--rw-r--r-- M 112 glenda sys 1791230 May 25 23:17 /386/lib/gnu/libstdc++.a.2.10.0
--rwxr-xr-x M 112 glenda sys    3603 Jul  9 05:21 /386/lib/gnu/libstdc++.la
--rw-r--r-- M 112 glenda sys  209022 Jul  9 05:20 /386/lib/gnu/libsupc++.a
--rwxr-xr-x M 112 glenda sys    1019 Jul  9 05:20 /386/lib/gnu/libsupc++.la
--rw-r--r-- M 112 glenda sys   15704 Jun 12 12:01 /386/lib/gnu/libutf.a
--rw-r--r-- M 112 glenda sys    4756 Jun 12 12:01 /386/lib/gnu/libv.a
 
ls -l /386/lib/gnu/gcc-lib/i386-lucent-plan9/3.0/libgcc.a 
--rw-r--r-- M 112 glenda sys 1118382 Jul  9 05:20 /386/lib/gnu/gcc-lib/i386-lucent-plan9/3.0/libgcc.a
 
3я пересбока (на свежесобранных либах) - ошибка и либа не собралась

Копать придется видимо libtool. Начиная с i386-lucent-plan9/libstdc++-v3/libtool:2728 и наверх - щупаем переменную deplibs
Ошибка выглядит так:
../libtool: internal error: alloc: freeing memory outside of block (corrupted?)
2663-2668 - мимо
2657
2583
2524-2526
2485-2487
2306-2312
2292
2284-2285
2280-2281
2187 - закомментаривание вызвало изменение текста ошибки:
../libtool: -lstdc++[1619828]: internal error: alloc: freeing memory outside of block (corrupted?)
2176 снова попрежнему ../libtool: internal error: alloc: freeing memory outside of block (corrupted?)
2108-2109
2102
2087
2081
2059
2055
2048
2039
2021
2008
2004-2005
1968
1945-1950 - закоментаривание вызвало сборку либы без ошибки - либтул отработал до конца:
#    for deplib in $deplibs; do
#      case "$libs " in
#      *" $deplib "*) specialdeplibs="$specialdeplibs $deplib" ;;
#      esac
#      libs="$libs $deplib"
#    done
собранный  libstdc++.a в сорцах (идентичен проинсталленому свежесобранному из 1й компилляции)
ls -l
итого 2968
-rw-r--r-- 1 nfsnobody nfsnobody 3027930 июл 10 08:14 libstdc++.a
-rw-r--r-- 1 nfsnobody nfsnobody    3618 июл 10 08:14 libstdc++.la
-rw-r--r-- 1 nfsnobody nfsnobody    3619 июл 10 08:14 libstdc++.lai
1817-1818 - закоментаривание вызвало сборку либы без ошибки - либтул отработал до конца:
#<----->else
#<----->  deplibs="$deplibs $arg"
собранный  libstdc++.a в сорцах (идентичен проинсталленому свежесобранному из 1й компилляции)
1801 снова попрежнему ../libtool: internal error: alloc: freeing memory outside of block (corrupted?)
1551
1523
1520-1526
1148
--------
1952 - содержимое $libs
 -lm ../libmath/libmath.la ../libsupc++/libsupc++convenience.la
но если захардкодить (libsupc++convenience.la присутствует также и в src):
libs=" -lm ../libmath/libmath.la libsupc++convenience.la "
компиляция без ошибки, но прерывается на распаковке:
ar: /n/vega/home/_vega9/_gcc3/gcc-3.0/i386-lucent-plan9/libstdc++-v3/src/./.libs/libsupc++convenience.a: No such file or directory


Добавление в libtool:1952-1953 строк
libs=" -lm ../libmath/libmath.la libsupc++convenience.la "
cp ../libsupc++/.libs/libsupc++convenience.a .libs/libsupc++convenience.a
привело к успешной сборке libstdc++.*

добавим эти же строки в ltmain.sh:1627-1628 и пересоберемся.. Не пересбралось - куча ошибок..
Закомментарим вместо них libtool:1817-1818 т.е. ltmain.sh:1493-1494
Теперь все собралось без ошибок. Лог: mylog_before_mkinstall_3.txt
Затем все проинсталлилось mki_3.txt
И еще пересборка/переинсталл: mylog_before_mkinstall_4.txt mki_4.txt

Теперь надо заснапшотить успешные пересборку/реинсталл, откатиться на исх.ГЦЦ и там попробовать также покомпилить.
Примеры: tttoe
bind -a /sys/lib/gnu/include/g++-v3/i386-lucent-plan9/bits /sys/lib/gnu/include/g++-v3/bits
g++ gistfile1.c  
в новой сборке вызывает кучу ошибок..

Простой пример: cat /n/vega/home/_vega9/_Xlam/hww.cpp
#include <iostream>
using namespace std;
int main() {
cout << "hello world" << endl;
return 0;
}
не смог сам найти нужные инклуды. Запускаем так:
cd /n/vega/home/_vega9/_Xlam
g++ -I/sys/lib/gnu/include/g++-v3 hww.cpp 2>&1 | tee hww_log.txt
/386/bin/gnu/i386-lucent-plan9/ld: cannot open output file a.out: No such file or directory
collect2: ld returned 1 exit status

В тоже время С-код: cat hww.c
#include <stdio.h>
    main(){
        printf("Hello, world\n");
    }    
скомпилися и запустился норм:
gcc hww.c    

Надо проверить на исх.сборке. Снапшотим текущее состояние:
virsh snapshot-create-as --domain v9t386 --name "2023_07_12_Works" --description "after make install, e
rrors fixed, build-install successfull, but heloworld.cpp doesnt compile and gens much of errs (undefined reference) Problemas with libstdc++.a(locale-inst.o)"


Переключаемся на снапшот с исх.сборкой (от Стаала) (2023_07_06_Works)
virsh snapshot-revert --domain v9t386 --snapshotname 2023_07_06_Works --running

Идентичная картина: С-код компилится без ошибок, С++ - с такими же ошибками там же. Т.е. сборка по сути воспроизведена и вероятно без новых ошибок, но имевшиеся увы сохранились.



Jens Staal about port LLVM to Plan9
https://lists.llvm.org/pipermail/llvm-dev/2010-February/029658.html


## Pack src and installed to archives
Staal's ape-archive didnt modified..
tar -zcf gcc300_src_i386_9front_nativebuild.tar.bz2 ./gcc-3.0
OR
tar -jcf gcc300_src_i386_9front_nativebuild.tar.bz2 ./gcc-3.0
tar -zcf gcc300_bin_i386_9front_nativebuild.tar.gz /386/include/gnu /386/bin/gnu /386/lib/gnu /rc/bin/gnu /sys/include/gnu /sys/lib/gnu


Однако.. компилляция командой
g++ -I/sys/lib/gnu/include/g++-v3 -Wall -Wextra -Werror -c hww.cpp -o hwww.o
прошла без ошибок/варнингов и дала обжект, похожий на правильный..
Ошибка далее на стадии линкера.
Эта ошибка в первую очередь вызвана тем, что у компилятора нет доступа к библиотеке STL (из C++).

g++ -I/sys/lib/gnu/include -I/sys/lib/gnu/include/g++-v3 -I/sys/lib/gnu/include/g++-v3/i386-lucent-plan9 hww.cpp    
    
g++ -L/386/lib/gnu  -I/386/include/gnu -I/386/lib/gnu/gcc-lib/i386-lucent-plan9/3.0/include -I/sys/include/gnu -I/sys/lib/gnu/include/g++-v3 -I/sys/lib/gnu/include/g++-v3/backward -I/sys/lib/gnu/include/g++-v3/bits -I/sys/lib/gnu/include/g++-v3/ext -I/sys/lib/gnu/include/g++-v3/i386-lucent-plan9/bits -I/n/vega/home/_vega9/_gcc3/gcc-3.0/gcc/include  -B/386/bin/gnu/i386-lucent-plan9/bin/ -B/386/bin/gnu/i386-lucent-plan9/lib/ hww.cpp    
    
https://qna.habr.com/q/1117406
Проверьте, содержатся ли эти символа в подключаемых библиотеках.
Проверить можно с помощью objdump или nm.
glfw3 вы сами собирали? Возможно вы его собрали компилятором С++ и символа у него получились с плюсовым манглингом, а линковщик ищет с Сишным.


Возможно, GCC таки был недособран. https://gcc.gnu.org/install/build.html make bootstrap дает ошибку - stage1/xgcc: Command not found
см gcc/Makefile:3286
bootstrap
Сборка останавливается на 2стадии.
Before gcc/Makefile:3286 (gcc/Makefile.in:2965) added:
<------>echo "<>DBG: copying xgcc"
<------>cp xgcc stage1/xgcc



В https://gcc.gnu.org/install/build.html нашелся интересный момент (подсказывающий плпробовать configure --disable-bootstrap):
Создание кросс-компилятора
При создании кросс-компилятора обычно невозможно выполнить трехэтапную начальную загрузку компилятора. Это создает интересную проблему, поскольку части GCC могут быть созданы только с помощью GCC.
Чтобы создать кросс-компилятор, мы рекомендуем сначала собрать и установить собственный компилятор. Затем вы можете использовать собственный компилятор GCC для создания кросс-компилятора. Установленный собственный компилятор должен быть GCC версии 2.95 или новее.

Сборка с configure --disable-bootstrap собралась и проинсталлилась - бинари идентичны пред.сборкам.
g++ -I/sys/lib/gnu/include -I/sys/lib/gnu/include/g++-v3 -I/sys/lib/gnu/include/g++-v3/i386-lucent-plan9 hww.cpp    
не компилит и с теми же ошибками.

Последущая пересборка - без configure --disable-bootstrap и с make bootstrap

После сборки ar rc libbackend.a интересные ошибки:
stage1/xgcc -Bstage1/ -B/386/bin/gnu/i386-lucent-plan9/bin/  -DIN_GCC    -g -O2 -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wtraditional -pedantic -Wno-long-long  -DHAVE_CONFIG_H  -o cc1 \
	c-parse.o c-lang.o c-errors.o c-lex.o c-pragma.o c-decl.o c-typeck.o c-convert.o c-aux-info.o c-common.o c-format.o c-semantics.o c-dump.o libcpp.a  toplev.o libbackend.a obstack.o        ../libiberty/libiberty.a -lintl -lbsd 
toplev.o: In function `rest_of_compilation':
/n/vega/home/_vega9/_gcc3/gcc-3.0/gcc/toplev.c:3631: undefined reference to `reorder_basic_blocks'
make[2]: *** [cc1] Error 1
stage1/xgcc -Bstage1/ -B/386/bin/gnu/i386-lucent-plan9/bin/ -c  -DIN_GCC    -g -O2 -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wtraditional -pedantic -Wno-long-long  -DHAVE_CONFIG_H    -I. -I. -I. -I./. -I./config -I./../include gcov.c -o gcov.o
xgcc: installation problem, cannot exec `cc1': No such file or directory
make[2]: *** [gcov.o] Error 1

cc1 присутствует:
/bin/i386-lucent-plan9/3.0/cc1
/bin/gnu/i386-lucent-plan9/3.0/cc1

Решилось некрасивым костылем:
cp /386/bin/gnu/i386-lucent-plan9/3.0/cc1 /n/vega/home/_vega9/_gcc3/gcc-3.0/gcc/stage1

правка в gcc/Makefile.in:2964..
stage2_build: stage1_copy
<------>echo "<>DBG: copying xgcc and cc1"
<------>cp xgcc stage1/xgcc
<------>cp /386/bin/gnu/i386-lucent-plan9/3.0/cc1 stage1

Но оставалась ошибка undefined reference to 'reorder_basic_blocks' поэтому
gcc/toplev.c:90
> extern void reorder_basic_blocks<------>PARAMS ((void));
не помогло - убрать..

Re: [9fans] Using gpc and g77 in 9front

[Yury Chumak]

I asked about the C++ part because I wanted to understand whether I
screwed something up in the source code, or whether the C++ in your
source code didn't work from the start.
It turns out that CFront is alive??!! Great.. Could you give me a link
to its current versions - I'd really like to try what it's capable of
now.. And APExp also..

ср, 11 дек. 2024 г. в 15:22, Jens Staal <staal1978@gmail.com>:
>
> The Cfront is work-in-progress in APExp. I verify that each release builds from scratch on a clean 9front amd64 VM.
>
> Between releases, there can be breakage.
>
> Den ons 11 dec. 2024 13:37Yury Chumak <sfynkx@gmail.com> skrev:
>>
>> Once I tried to rebuild your sources in 9Front but it didn't work. I
>> had to modify the sources a little, add wrappers for APE, something
>> else (I don't remember everything). I achieved to rebuild it itself,
>> but C++ part doesn't work there.
>>
>> Taking this opportunity, I would like to ask - under what conditions
>> did you build - a clean Plan9 or a ported environment or something
>> else?? And did the C++ part work for you??
>>
>> ср, 11 дек. 2024 г. в 10:19, Jens Staal <staal1978@gmail.com>:
>> >
>> > On Wed, Dec 11, 2024 at 03:07:09AM -0500, mouad-all@outlook.com wrote:
>> > > Hello,
>> > >
>> > > Is it possible to compile an older version of gcc in 9front to use the gnu
>> > > pascal and gnu fortran 77 compilers?
>> > >
>> > > I have found an older version of gcc for i386 at https://code.google.com/
>> > > archive/p/ports2plan9/downloads but I don't know if it will actually work
>> > > nowadays.
>> >
>> > The GCC port probably still works, but only for i386. I have abandoned
>> > that track a bit and am now more interested in the transpilers since
>> > they (theoretically) would work on all architectures supported by the C
>> > compilers.
>> >
>> > > There are converters like p2c and f2c, but they are limited in comparison to a
>> > > compiler.
>> >
>> > I have integrated f2c and p2c in APExp, and I hope to integrate even
>> > more transpilers there. I have not had time to play with it lately, but
>> > I see my APExp project as a "spiritual successor" to ports2plan9
>> >
>> > https://github.com/staalmannen/APExp
>> >
>> > > So please any advice or guidance would be much appreciated.
>> > > 9fans / 9fans / see discussions + participants + delivery options Permalink
>> 
>> 
>> --
>> Sphynkx
>
> 9fans / 9fans / see discussions + participants + delivery options Permalink



-- 
Sphynkx

------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/T41cf38050bd5915d-Mdf1bcce926fcca3492cbd5a7
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] Using gpc and g77 in 9front

[Jens Staal]

On Wed, Dec 11, 2024 at 05:43:56PM +0200, Yury Chumak wrote:
> I asked about the C++ part because I wanted to understand whether I
> screwed something up in the source code, or whether the C++ in your
> source code didn't work from the start.
> It turns out that CFront is alive??!! Great.. Could you give me a link
> to its current versions - I'd really like to try what it's capable of
> now.. And APExp also..
>

No it is a very old plan9 port that I copied from /n/sources

I thought you were asking about the APExp. For the gcc I don't remember
really what I got to build in the 4.5 port. For GCC, you basically need
an earlier GCC to build the newer one so I started off with the old gcc
3 binary port and upgraded it gradually.

This was a long time ago however.


> ср, 11 дек. 2024 г. в 15:22, Jens Staal <staal1978@gmail.com>:
> >
> > The Cfront is work-in-progress in APExp. I verify that each release builds from scratch on a clean 9front amd64 VM.
> >
> > Between releases, there can be breakage.
> >
> > Den ons 11 dec. 2024 13:37Yury Chumak <sfynkx@gmail.com> skrev:
> >>
> >> Once I tried to rebuild your sources in 9Front but it didn't work. I
> >> had to modify the sources a little, add wrappers for APE, something
> >> else (I don't remember everything). I achieved to rebuild it itself,
> >> but C++ part doesn't work there.
> >>
> >> Taking this opportunity, I would like to ask - under what conditions
> >> did you build - a clean Plan9 or a ported environment or something
> >> else?? And did the C++ part work for you??
> >>
> >> ср, 11 дек. 2024 г. в 10:19, Jens Staal <staal1978@gmail.com>:
> >> >
> >> > On Wed, Dec 11, 2024 at 03:07:09AM -0500, mouad-all@outlook.com wrote:
> >> > > Hello,
> >> > >
> >> > > Is it possible to compile an older version of gcc in 9front to use the gnu
> >> > > pascal and gnu fortran 77 compilers?
> >> > >
> >> > > I have found an older version of gcc for i386 at https://code.google.com/
> >> > > archive/p/ports2plan9/downloads but I don't know if it will actually work
> >> > > nowadays.
> >> >
> >> > The GCC port probably still works, but only for i386. I have abandoned
> >> > that track a bit and am now more interested in the transpilers since
> >> > they (theoretically) would work on all architectures supported by the C
> >> > compilers.
> >> >
> >> > > There are converters like p2c and f2c, but they are limited in comparison to a
> >> > > compiler.
> >> >
> >> > I have integrated f2c and p2c in APExp, and I hope to integrate even
> >> > more transpilers there. I have not had time to play with it lately, but
> >> > I see my APExp project as a "spiritual successor" to ports2plan9
> >> >
> >> > https://github.com/staalmannen/APExp
> >> >
> >> > > So please any advice or guidance would be much appreciated.
> >> > > 9fans / 9fans / see discussions + participants + delivery options Permalink
> >> 
> >> 
> >> --
> >> Sphynkx
> >
> > 9fans / 9fans / see discussions + participants + delivery options Permalink
> 
> 
> --
> Sphynkx

------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/T41cf38050bd5915d-Mf68ea8ce55db8e2904150c06
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] Using gpc and g77 in 9front

[Mouad All]

[-- Attachment #1: Type: text/plain, Size: 641 bytes --]

> Hmm.. some formatting issues there.. Same text in attach..

Thanks for the notes.

> It turns out that CFront is alive??!! Great.. Could you give me a link
to its current versions - I'd really like to try what it's capable of
now.. And APExp also..

The developer of APExp Jens Staal posted its link in the second post of this thread:

https://github.com/staalmannen/APExp

You'll find CFront there.
------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/T41cf38050bd5915d-M635c45bc78adb8734e3ddb29
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

[-- Attachment #2: Type: text/html, Size: 1454 bytes --]

Re: [9fans] Using gpc and g77 in 9front

[Yury Chumak]

And about APExp also asking.. I haven't heard of APExp before. Doesnt
googling anything.. Is it a development/fork of APE?? In any case,
it's also interesting to look at it.
As for gcc, I worked with early versions (v.3.0.0). And in early
versions, problems with C++ were discovered. There was no point in
moving forward until the issue with C++ was resolved.

ср, 11 дек. 2024 г. в 17:51, Jens Staal <staal1978@gmail.com>:
>
> On Wed, Dec 11, 2024 at 05:43:56PM +0200, Yury Chumak wrote:
> > I asked about the C++ part because I wanted to understand whether I
> > screwed something up in the source code, or whether the C++ in your
> > source code didn't work from the start.
> > It turns out that CFront is alive??!! Great.. Could you give me a link
> > to its current versions - I'd really like to try what it's capable of
> > now.. And APExp also..
> >
>
> No it is a very old plan9 port that I copied from /n/sources
>
> I thought you were asking about the APExp. For the gcc I don't remember
> really what I got to build in the 4.5 port. For GCC, you basically need
> an earlier GCC to build the newer one so I started off with the old gcc
> 3 binary port and upgraded it gradually.
>
> This was a long time ago however.
>
>
> > ср, 11 дек. 2024 г. в 15:22, Jens Staal <staal1978@gmail.com>:
> > >
> > > The Cfront is work-in-progress in APExp. I verify that each release builds from scratch on a clean 9front amd64 VM.
> > >
> > > Between releases, there can be breakage.
> > >
> > > Den ons 11 dec. 2024 13:37Yury Chumak <sfynkx@gmail.com> skrev:
> > >>
> > >> Once I tried to rebuild your sources in 9Front but it didn't work. I
> > >> had to modify the sources a little, add wrappers for APE, something
> > >> else (I don't remember everything). I achieved to rebuild it itself,
> > >> but C++ part doesn't work there.
> > >>
> > >> Taking this opportunity, I would like to ask - under what conditions
> > >> did you build - a clean Plan9 or a ported environment or something
> > >> else?? And did the C++ part work for you??
> > >>
> > >> ср, 11 дек. 2024 г. в 10:19, Jens Staal <staal1978@gmail.com>:
> > >> >
> > >> > On Wed, Dec 11, 2024 at 03:07:09AM -0500, mouad-all@outlook.com wrote:
> > >> > > Hello,
> > >> > >
> > >> > > Is it possible to compile an older version of gcc in 9front to use the gnu
> > >> > > pascal and gnu fortran 77 compilers?
> > >> > >
> > >> > > I have found an older version of gcc for i386 at https://code.google.com/
> > >> > > archive/p/ports2plan9/downloads but I don't know if it will actually work
> > >> > > nowadays.
> > >> >
> > >> > The GCC port probably still works, but only for i386. I have abandoned
> > >> > that track a bit and am now more interested in the transpilers since
> > >> > they (theoretically) would work on all architectures supported by the C
> > >> > compilers.
> > >> >
> > >> > > There are converters like p2c and f2c, but they are limited in comparison to a
> > >> > > compiler.
> > >> >
> > >> > I have integrated f2c and p2c in APExp, and I hope to integrate even
> > >> > more transpilers there. I have not had time to play with it lately, but
> > >> > I see my APExp project as a "spiritual successor" to ports2plan9
> > >> >
> > >> > https://github.com/staalmannen/APExp
> > >> >
> > >> > > So please any advice or guidance would be much appreciated.
> > >> > > 9fans / 9fans / see discussions + participants + delivery options Permalink
> > >>
> > >>
> > >> --
> > >> Sphynkx
> > >
> > > 9fans / 9fans / see discussions + participants + delivery options Permalink
> >
> >
> > --
> > Sphynkx



-- 
Sphynkx

------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/T41cf38050bd5915d-M526f5b4089eb42c56f520886
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] Using gpc and g77 in 9front

[Yury Chumak]

Thanks for the link - I didn't see the post ..

ср, 11 дек. 2024 г. в 18:03, Mouad All <mouad-all@outlook.com>:
>
> Hmm.. some formatting issues there.. Same text in attach..
>
>
> Thanks for the notes.
>
> It turns out that CFront is alive??!! Great.. Could you give me a link
> to its current versions - I'd really like to try what it's capable of
> now.. And APExp also..
>
>
> The developer of APExp Jens Staal posted its link in the second post of this thread:
>
> https://github.com/staalmannen/APExp
>
> You'll find CFront there.
> 9fans / 9fans / see discussions + participants + delivery options Permalink



-- 
Sphynkx

------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/T41cf38050bd5915d-Mc10fdc0203c88efbe9f31e96
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] Using gpc and g77 in 9front

[Jens Staal]

On Wed, Dec 11, 2024 at 06:07:51PM +0200, Yury Chumak wrote:
> And about APExp also asking.. I haven't heard of APExp before. Doesnt
> googling anything.. Is it a development/fork of APE?? In any case,
> it's also interesting to look at it.

It is basically a fork of APE from 9front, but changed to be built
"portably" (so in a local check out directory) without overwriting the
system utilities.

The compiler has several patches and several utilities have been
replaced (often with GNU utilities, like gmake, gawk, flex, byacc, GNU
m4, ...) and some common dependencies are pre-packaged/included

everything can be built by running mk install in the root of the
checkout.

Then to work with it, you basically just run ./apexp-sh to mount all the
directories and make a APExp namespace where you can start building *nix
applications.

> As for gcc, I worked with early versions (v.3.0.0). And in early
> versions, problems with C++ were discovered. There was no point in
> moving forward until the issue with C++ was resolved.
> 
> ср, 11 дек. 2024 г. в 17:51, Jens Staal <staal1978@gmail.com>:
> >
> > On Wed, Dec 11, 2024 at 05:43:56PM +0200, Yury Chumak wrote:
> > > I asked about the C++ part because I wanted to understand whether I
> > > screwed something up in the source code, or whether the C++ in your
> > > source code didn't work from the start.
> > > It turns out that CFront is alive??!! Great.. Could you give me a link
> > > to its current versions - I'd really like to try what it's capable of
> > > now.. And APExp also..
> > >
> >
> > No it is a very old plan9 port that I copied from /n/sources
> >
> > I thought you were asking about the APExp. For the gcc I don't remember
> > really what I got to build in the 4.5 port. For GCC, you basically need
> > an earlier GCC to build the newer one so I started off with the old gcc
> > 3 binary port and upgraded it gradually.
> >
> > This was a long time ago however.
> >
> >
> > > ср, 11 дек. 2024 г. в 15:22, Jens Staal <staal1978@gmail.com>:
> > > >
> > > > The Cfront is work-in-progress in APExp. I verify that each release builds from scratch on a clean 9front amd64 VM.
> > > >
> > > > Between releases, there can be breakage.
> > > >
> > > > Den ons 11 dec. 2024 13:37Yury Chumak <sfynkx@gmail.com> skrev:
> > > >>
> > > >> Once I tried to rebuild your sources in 9Front but it didn't work. I
> > > >> had to modify the sources a little, add wrappers for APE, something
> > > >> else (I don't remember everything). I achieved to rebuild it itself,
> > > >> but C++ part doesn't work there.
> > > >>
> > > >> Taking this opportunity, I would like to ask - under what conditions
> > > >> did you build - a clean Plan9 or a ported environment or something
> > > >> else?? And did the C++ part work for you??
> > > >>
> > > >> ср, 11 дек. 2024 г. в 10:19, Jens Staal <staal1978@gmail.com>:
> > > >> >
> > > >> > On Wed, Dec 11, 2024 at 03:07:09AM -0500, mouad-all@outlook.com wrote:
> > > >> > > Hello,
> > > >> > >
> > > >> > > Is it possible to compile an older version of gcc in 9front to use the gnu
> > > >> > > pascal and gnu fortran 77 compilers?
> > > >> > >
> > > >> > > I have found an older version of gcc for i386 at https://code.google.com/
> > > >> > > archive/p/ports2plan9/downloads but I don't know if it will actually work
> > > >> > > nowadays.
> > > >> >
> > > >> > The GCC port probably still works, but only for i386. I have abandoned
> > > >> > that track a bit and am now more interested in the transpilers since
> > > >> > they (theoretically) would work on all architectures supported by the C
> > > >> > compilers.
> > > >> >
> > > >> > > There are converters like p2c and f2c, but they are limited in comparison to a
> > > >> > > compiler.
> > > >> >
> > > >> > I have integrated f2c and p2c in APExp, and I hope to integrate even
> > > >> > more transpilers there. I have not had time to play with it lately, but
> > > >> > I see my APExp project as a "spiritual successor" to ports2plan9
> > > >> >
> > > >> > https://github.com/staalmannen/APExp
> > > >> >
> > > >> > > So please any advice or guidance would be much appreciated.
> > > >> > > 9fans / 9fans / see discussions + participants + delivery options Permalink
> > > >>
> > > >>
> > > >> --
> > > >> Sphynkx
> > > >
> > > > 9fans / 9fans / see discussions + participants + delivery options Permalink
> > >
> > >
> > > --
> > > Sphynkx
> 
> 
> --
> Sphynkx

------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/T41cf38050bd5915d-Mce2530b6fc8ee6a18fd5a0ea
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] Using gpc and g77 in 9front

[Yury Chumak]

I've already seen the link, looked at it...
Thankx, I'll try it ..

ср, 11 дек. 2024 г. в 18:37, Jens Staal <staal1978@gmail.com>:
>
> On Wed, Dec 11, 2024 at 06:07:51PM +0200, Yury Chumak wrote:
> > And about APExp also asking.. I haven't heard of APExp before. Doesnt
> > googling anything.. Is it a development/fork of APE?? In any case,
> > it's also interesting to look at it.
>
> It is basically a fork of APE from 9front, but changed to be built
> "portably" (so in a local check out directory) without overwriting the
> system utilities.
>
> The compiler has several patches and several utilities have been
> replaced (often with GNU utilities, like gmake, gawk, flex, byacc, GNU
> m4, ...) and some common dependencies are pre-packaged/included
>
> everything can be built by running mk install in the root of the
> checkout.
>
> Then to work with it, you basically just run ./apexp-sh to mount all the
> directories and make a APExp namespace where you can start building *nix
> applications.
>
> > As for gcc, I worked with early versions (v.3.0.0). And in early
> > versions, problems with C++ were discovered. There was no point in
> > moving forward until the issue with C++ was resolved.
> >
> > ср, 11 дек. 2024 г. в 17:51, Jens Staal <staal1978@gmail.com>:
> > >
> > > On Wed, Dec 11, 2024 at 05:43:56PM +0200, Yury Chumak wrote:
> > > > I asked about the C++ part because I wanted to understand whether I
> > > > screwed something up in the source code, or whether the C++ in your
> > > > source code didn't work from the start.
> > > > It turns out that CFront is alive??!! Great.. Could you give me a link
> > > > to its current versions - I'd really like to try what it's capable of
> > > > now.. And APExp also..
> > > >
> > >
> > > No it is a very old plan9 port that I copied from /n/sources
> > >
> > > I thought you were asking about the APExp. For the gcc I don't remember
> > > really what I got to build in the 4.5 port. For GCC, you basically need
> > > an earlier GCC to build the newer one so I started off with the old gcc
> > > 3 binary port and upgraded it gradually.
> > >
> > > This was a long time ago however.
> > >
> > >
> > > > ср, 11 дек. 2024 г. в 15:22, Jens Staal <staal1978@gmail.com>:
> > > > >
> > > > > The Cfront is work-in-progress in APExp. I verify that each release builds from scratch on a clean 9front amd64 VM.
> > > > >
> > > > > Between releases, there can be breakage.
> > > > >
> > > > > Den ons 11 dec. 2024 13:37Yury Chumak <sfynkx@gmail.com> skrev:
> > > > >>
> > > > >> Once I tried to rebuild your sources in 9Front but it didn't work. I
> > > > >> had to modify the sources a little, add wrappers for APE, something
> > > > >> else (I don't remember everything). I achieved to rebuild it itself,
> > > > >> but C++ part doesn't work there.
> > > > >>
> > > > >> Taking this opportunity, I would like to ask - under what conditions
> > > > >> did you build - a clean Plan9 or a ported environment or something
> > > > >> else?? And did the C++ part work for you??
> > > > >>
> > > > >> ср, 11 дек. 2024 г. в 10:19, Jens Staal <staal1978@gmail.com>:
> > > > >> >
> > > > >> > On Wed, Dec 11, 2024 at 03:07:09AM -0500, mouad-all@outlook.com wrote:
> > > > >> > > Hello,
> > > > >> > >
> > > > >> > > Is it possible to compile an older version of gcc in 9front to use the gnu
> > > > >> > > pascal and gnu fortran 77 compilers?
> > > > >> > >
> > > > >> > > I have found an older version of gcc for i386 at https://code.google.com/
> > > > >> > > archive/p/ports2plan9/downloads but I don't know if it will actually work
> > > > >> > > nowadays.
> > > > >> >
> > > > >> > The GCC port probably still works, but only for i386. I have abandoned
> > > > >> > that track a bit and am now more interested in the transpilers since
> > > > >> > they (theoretically) would work on all architectures supported by the C
> > > > >> > compilers.
> > > > >> >
> > > > >> > > There are converters like p2c and f2c, but they are limited in comparison to a
> > > > >> > > compiler.
> > > > >> >
> > > > >> > I have integrated f2c and p2c in APExp, and I hope to integrate even
> > > > >> > more transpilers there. I have not had time to play with it lately, but
> > > > >> > I see my APExp project as a "spiritual successor" to ports2plan9
> > > > >> >
> > > > >> > https://github.com/staalmannen/APExp
> > > > >> >
> > > > >> > > So please any advice or guidance would be much appreciated.
> > > > >> > > 9fans / 9fans / see discussions + participants + delivery options Permalink
> > > > >>
> > > > >>
> > > > >> --
> > > > >> Sphynkx
> > > > >
> > > > > 9fans / 9fans / see discussions + participants + delivery options Permalink
> > > >
> > > >
> > > > --
> > > > Sphynkx
> >
> >
> > --
> > Sphynkx



-- 
Sphynkx

------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/T41cf38050bd5915d-M131d133d22b03e666da17e37
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription