From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.5-pre1 (2020-06-20) on ip-172-31-74-118.ec2.internal X-Spam-Level: X-Spam-Status: No, score=-1.9 required=3.0 tests=BAYES_00,FREEMAIL_FROM autolearn=ham autolearn_force=no version=3.4.5-pre1 X-Received: by 2002:a37:7683:: with SMTP id r125mr15923279qkc.39.1595693239651; Sat, 25 Jul 2020 09:07:19 -0700 (PDT) X-Received: by 2002:ae9:dc85:: with SMTP id q127mr11585391qkf.398.1595693238931; Sat, 25 Jul 2020 09:07:18 -0700 (PDT) Path: eternal-september.org!reader01.eternal-september.org!feeder.eternal-september.org!news.gegeweb.eu!gegeweb.org!usenet-fr.net!proxad.net!feeder1-2.proxad.net!209.85.160.216.MISMATCH!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail Newsgroups: comp.lang.ada Date: Sat, 25 Jul 2020 09:07:18 -0700 (PDT) In-Reply-To: Complaints-To: groups-abuse@google.com Injection-Info: google-groups.googlegroups.com; posting-host=95.250.125.238; posting-account=JRF_-woAAABYlsAtkCl_CUxBuQy2SsaQ NNTP-Posting-Host: 95.250.125.238 References: <748b7abb-4bda-4174-aa37-367daaf1c02ao@googlegroups.com> User-Agent: G2/1.0 MIME-Version: 1.0 Message-ID: <0029cbaf-d2ea-4bb9-8594-4a4041f55d64o@googlegroups.com> Subject: Re: SweetAda 0.1e released From: gabriele.galeotti.xyz@gmail.com Injection-Date: Sat, 25 Jul 2020 16:07:19 +0000 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Xref: reader01.eternal-september.org comp.lang.ada:59526 List-Id: On Saturday, July 25, 2020 at 3:44:57 PM UTC+2, Roger wrote: > On Thursday, July 23, 2020 at 4:03:06 AM UTC+10, gabriele....@gmail.com w= rote: > > Hi all. I've just released SweetAda 01.e. > >=20 > > Go to http://www.sweetada.org and download the archive. RTS and LibGCC = packages are still valid @ 0.1c. > >=20 > > - general cleanup and cosmetics > > - general infrastructure improvements > > - QEMU-RISC-V-32 target can do serial output in a terminal > > - IntegratorCP target uses LCD VGA > > - Malta MIPS target uses a VGA PCI board > > - handling of directories in the cpus hierarchy, which allows selective= unit overriding > > - Insight can be called as a toolchain component > > - IOEMU configuration files are now fully consistent > >=20 > > Next days I will to concentrate on generic low-level CPU support, docum= entation, and restructuring of some redundant units. Let me know, feedback = is highly appreciated. > >=20 > > G > I have not been able to build with 1e menu.sh. > The make case statement in menu.sh seems to not get activated. > In particular, no kernel.cfg file is generated. > I copied the make statements from 1d into the 1e menu.sh and make occur= red until: >=20 > [RANLIB] libplatform.a > [GPRBUILD-C] build.gpr > [GPRBUILD-B] build.gpr > gprbuild: unable to find binder driver /opt/sweetada/libexec/gprbuild/gpr= bind > make: *** [Makefile:586: kernel_compile_gpr] Error 4 >=20 > PC-x86-64: start kernel build. >=20 > [GPRBUILD-C] build.gpr > [GPRBUILD-B] build.gpr > gprbuild: unable to find binder driver /opt/sweetada/libexec/gprbuild/gpr= bind > make: *** [Makefile:586: kernel_compile_gpr] Error 4 >=20 > After this I removed the 1d statements and tried the original 1e menu.sh. > As before ./menu.sh generated nothing. > But I individual menu targets worked from all-clean through configure the= n > menu.sh all failed with same error: >=20 > [RANLIB] libplatform.a > [GPRBUILD-C] build.gpr > [GPRBUILD-B] build.gpr > gprbuild: unable to find binder driver /opt/sweetada/libexec/gprbuild/gpr= bind > make: *** [Makefile:586: kernel_compile_gpr] Error 4 Hi Roger. Sounds very strange. 1) ---------------------------------------------------------------------- Every executable of the "gprbuild set" has no dependency other than system = libraries, so it should not be a library problem (and gprbuild seems runnin= g fine because of the steps carried out); gprbind is in another directory, = not bin/ but libexec/gprbuild/, relative to the prefix, and gets called by = the executable gprbuild. Could you try to dry-run gprbind directly from the shell? My result is: gabriele-iMac:sweetada-0.1e root# /opt/sweetada/libexec/gprbuild/gprbind gprbind: incorrect invocation (yes, it's an error, but shown by gprbind because it gets no arguments, cur= rently it gets executed fine). 2) ------------------------------------------------------------------- The only difference in menu.sh, 0.1d vs 0.1e, is an "if" test: 0.1d: MAKE=3D/opt/sweetada/bin/make 0.1e: SWEETADA_MAKE=3D/opt/sweetada/bin/make if [ -e ${SWEETADA_MAKE} ] ; then MAKE=3D${SWEETADA_MAKE} else MAKE=3Dmake (I've put a "guess" test to switch to a system make in case). The only reas= on could be the "-e" test failing. So the shell is not able to find SweetAd= a's make. ----------------------------------------------------------------------- If we put together 1) and 2), I would say that maybe your system could have= problems in finding executables. Perhaps you have some sort of anti-virus = installed? Or, maybe new OSX have restrictive policies in finding them. Unfortunately gprbuild is a direct build out of AC repository, and it is co= mplicated to go deep in the code. Try to comment out BUILD_MODE :=3D GPR in the configuration.in, so maybe yo= u are able to successfully build with the standard procedure. Let's investigate further, let me know.