search

Memotech-Bill / PicoBB

BBC BASIC for Raspberry Pi Pico
zlib License
32 stars 4 forks source link

Build error: unrecognized command line option '-fcallgraph-info=su' #22

Open rtrussell opened 2 months ago

rtrussell commented 2 months ago

When trying to build PicoBB on a Raspberry Pi 400 (Raspbian Buster, fully updated, and freshly installed Pico-SDK) I am getting this error:

cc: error: unrecognized command line option '-fcallgraph-info=su'

It's entirely likely that this results from me doing something silly, or not doing something I should, but I don't know how to proceed.

Memotech-Bill commented 2 months ago

That is not an option I have set anywhere, so it must come from either CMake or the SDK.

Buster is now at least two versions of OS out of date, so probably has an old version of GCC.

My immediate guess is a new version of the SDK has introduced this option. Are you able to try installing Bookworm on a different SD card, and then test the compilation on that?

Memotech-Bill commented 2 months ago

Strange. On a fully updated version of Bullseye, with latest version of SDK, erasing the build folder then doing a new make shows no sign of requesting the -fcallgraph-info=su option.

I wonder whether something else you have done on the OS has set that option as a default.

rtrussell commented 2 months ago

I wonder whether something else you have done on the OS has set that option as a default.

Any idea what that might be? I only use the Raspberry Pi 400 for building BBC BASIC (the GUI, Console and Pico versions) so it's only turned on every three months or so! I certainly won't have done anything 'unusual' on it because I'm too inexperienced in Linux to have a clue. :-(

I've tried reverting the Pico-SDK to the version which has worked previously (which I'd kept as pico-sdk-old) and that has made no difference, the same error is reported. The one thing I have changed, and I can't revert, is to do a sudo apt-get dist-upgrade so maybe that's where the problem has arisen.

I'm rather at a loss to know what to do next, but I appreciate that it's not your problem.

Memotech-Bill commented 2 months ago

I don't think apt dist-upgrade is recommended for Raspberry Pi OS. I believe that the currently recommended sequence is:

sudo apt update
sudo apt full-upgrade

For updating from one major release to the next, a fresh install is recommended.

If that is all you use the system for, I would suggest installing a copy of the latest Raspberry Pi OS (Bookworm), ideally on a new SD card, and then starting again. I don't think it makes much difference whether you pick the 32-bit or 64-bit version.

rtrussell commented 2 months ago

If that is all you use the system for, I would suggest installing a copy of the latest Raspberry Pi OS (Bookworm),

Unless PiOS is an exception, the general rule in Linux is that you must build an app (which is distributed in binary form) on an OS version at least as old as the OS the end-user will be running it on. That's why I build the Linux version of BBC BASIC for SDL 2.0 on Ubuntu 18.04 LTS!

Some time ago, before I was made aware of that, I made the mistake of updating my Ubuntu installation and rebuilding BBCSDL with it, whereupon I started to receive complaints that the latest version wasn't running on earlier OS releases. As I understand it, it has something to do with compatibility of the C run-time library.

If that's not the case for PiOS, I'd be interested to know.

Memotech-Bill commented 2 months ago

It goes both ways. More recent releases of an OS may drop old versions of a DLL that old programs wish to load.

Also, for security reasons, people should not be running versions of an OS for which support has ended. From https://wiki.debian.org/DebianReleases

I would recommend downloading one of the images from https://www.raspberrypi.com/software/operating-systems/

However, If you do want to continue with Buster, then clean images can be downloaded from https://downloads.raspberrypi.org/raspios_armhf/images/ I have no experience with installing from these.

rtrussell commented 2 months ago

Also, for security reasons, people should not be running versions of an OS for which support has ended

Probably true, but I can't say to my customers that to run BBC BASIC they must update PiOS, especially as that is a real pain (basically you lose all your files and apps, and have to start again from scratch). If it was felt that important, a mechanism for updating the OS without losing personal files would be available, as it is for Windows and MacOS.

I would recommend downloading one of the images from https://www.raspberrypi.com/software/operating-systems/

OK, thanks for the advice. That's not something I feel able to embark on at the moment so I'll probably leave the Pico edition of BBC BASIC at the current version (0.45). Fortunately nearly all the changes to the core interpreter aren't relevant to the Pico edition anyway (e.g. increasing the maximum size of the heap to 4 Gb, fixing a bug in the COLOUR statement) so the practical impact will be small.

rtrussell commented 2 months ago

That is not an option I have set anywhere, so it must come from either CMake or the SDK.

Actually, searching with grep, it appears to me that it is set in (a sub-module of) your PicoBB project. In PicoBB/littlefs/Makefile (line 62) there is this:

CFLAGS += -fcallgraph-info=su

Unfortunately commenting out this line simply results in another error occurring: gcc: error: ../../littlefs/lfs.a: No such file or directory. Can you advise?

Memotech-Bill commented 2 months ago

It looks as though there have been a number of recent changes to littlefs/Makefile. Not only has -fcallgraph-info=su been introduced, but one of the build targets has been changed from lfs.a to liblfs.a.

As a quick work-aound, you could copy liblfs.a to lfs.a.

I will have to revise my makefiles to take account of this change.

Memotech-Bill commented 2 months ago

I have now committed the necessary changes to my makefiles.

In doing so I had to add your sort.c into the build.

rtrussell commented 2 months ago

In doing so I had to add your sort.c into the build.

You absolutely should not have needed to, indeed adding sort.c ought to have resulted in double-definition errors. The sort routines are in bbccos.c precisely to avoid the need to include this module. You should probably check why they did not automatically get picked up in your build, because I think you should be including BBCSDL as a submodule. You will remember that bbccos.c includes picocos.h so any Pico-specific code can be incorporated.

Memotech-Bill commented 2 months ago

Revised in latest commit.

rtrussell commented 2 months ago

Revised in latest commit.

Thank you very much.

Ironically, one of the main reasons why I put the sort routines in bbccos.c was to avoid breaking the PicoBB build! I can never be sure whether you will be available to (or willing to) make modifications to PicoBB, so where possible I try not to make changes to the BBCSDL project that will break it.

In addition, the code of the sort routines is different in bbccos.c compared with sort.c. The more recent code is suitable for the whole range of CPUs supported by the Console Mode editions, whereas the code in sort.c isn't (for example it doesn't support the alignment requirements of 32-bit ARM).

The architecture diagram shows sort.c as part of the GUI build (BBCSDL) but not of the Console Mode build:

Architecture

rtrussell commented 2 months ago

I raised the original issue at the littlefs project and they don't advise using their Makefile in your build, saying "The primary purpose of littlefs's Makefile is littlefs development, integration with external build systems is coincidental/secondary (and a can of worms)". They are suggesting that "Maybe [PicoBB] just needs $(MAKE) or export CFLAGS=*?" to avoid the error when building on Raspbian Buster.

Memotech-Bill commented 2 months ago

liblfs.a was never used for building any of the PicoBB executables. It was only used to build the mklfsimage utility used to produce the filesystem image.

I have now revised src/lfsutil/Makefile to explicitly compile the LFS source files, rather than use the library file. This will work until LFS changes the source file names.

rtrussell commented 2 months ago

I have now revised src/lfsutil/Makefile to explicitly compile the LFS source files, rather than use the library file. This will work until LFS changes the source file names.

Thank you again. Unfortunately I'm now getting the following error when I try to build it:

make: *** No rule to make target '../../src/bbccos.c', needed by 'bbcbasic_pkc.uf2', Stop.

I'm thinking that this should perhaps be ../../BBCSDL/src/bbccos.c and if I make that change to the Makefile it does build, but perhaps you would check whether I've done the right thing (rather than, say, deleting that target altogether).

One other question whilst I have your attention, I can't remember where the library files (i.e. those that end up in the lib/ directory on the Pico) are specified in the build. I had expected to find a PicoBB/console/pico/lib/ directory analogous with the PicoBB/console/pico/examples/ directory, but there isn't one.

Memotech-Bill commented 2 months ago

Thank you again. Unfortunately I'm now getting the following error when I try to build it:

make: *** No rule to make target '../../src/bbccos.c', needed by 'bbcbasic_pkc.uf2', Stop.

Sorry about that. I changed the path on the CMakeLists.txt file, so the build used your version, but I forgot to change the path in the Makefile, and I did my test build before deleting my copy of bbccos.c, so the test performed by make passed. Fixed in my latest commit.

One other question whilst I have your attention, I can't remember where the library files (i.e. those that end up in the lib/ directory on the Pico) are specified in the build. I had expected to find a PicoBB/console/pico/lib/ directory analogous with the PicoBB/console/pico/examples/ directory, but there isn't one.

The file pico_examples.cfg in the root folder specifies the source of all the files that go to make up the filesystem. From that file, for the pico build, selected files are taken from BBCSDL/lib

[all, all, lib/]
BBCSDL/lib/arraylib.bbc
BBCSDL/lib/classlib.bbc
BBCSDL/lib/datelib.bbc
BBCSDL/lib/fnusing.bbc
BBCSDL/lib/sortlib.bbc
BBCSDL/lib/stringlib.bbc
BBCSDL/lib/utf8lib.bbc
BBCSDL/lib/xmllib.bbc

For the pico_w build, additional files are taken from console/pico_w/examples/lib/

[pico_w, all, lib/]
console/pico_w/examples/lib/*
rtrussell commented 2 months ago

From that file, for the pico build, selected files are taken from BBCSDL/lib

Ah, OK. What do I do about libraries that are different in the Console editions compared with the GUI editions (typically because they call SYS "malloc" instead of SYS "SDL_malloc" or similar), an example being arraylib.bbc?

Memotech-Bill commented 2 months ago

Ah, OK. What do I do about libraries that are different in the Console editions compared with the GUI editions (typically because they call SYS "malloc" instead of SYS "SDL_malloc" or similar), an example being arraylib.bbc?

What do you do about them for the other console builds? I only see one copy of arraylib.bbc in BBCSDL.

If the console versions were in BBCSDL/console_lib/ (or similar), then pico_examples.cfg could be revised to copy files from there.

I suppose the other option would be for the Pico code to implement SDL_malloc (as a call to malloc).

rtrussell commented 2 months ago

What do you do about them for the other console builds? I only see one copy of arraylib.bbc in BBCSDL.

As previously discussed (I think) the libraries and examples for the console builds are not in my GitHub project. I have never been able to work out a satisfactory way to do that, given the way the console builds were shoehorned into the BBCSDL project long after it was created.

If the console versions were in BBCSDL/console_lib/ (or similar), then pico_examples.cfg could be revised to copy files from there.

Unfortunately the console builds aren't consistent in the way the SDL builds are. For example socklib.bbc isn't the same for the Pico W build as it is for the other console builds (at least, I assume the standard socklib won't work on the Pico W). Similarly the examples for the Pico version aren't the same as for the other console builds (they include sound and GPIO examples that are only relevant to the Pico).

I assumed the reason for the PicoBB/console/pico/examples/ directory was precisely to provide somewhere to put example programs specific to the Pico, which is why I was expecting a PicoBB/console/pico/lib/ (or maybe PicoBB/console/pico/examples/lib) directory for libraries specific to the Pico.

I suppose the other option would be for the Pico code to implement SDL_malloc (as a call to malloc).

That was just an example of how incompatibilities between the libraries can arise. socklib.bbc is completely different (although compatible) between the SDL builds and the console builds so would always have to be separate.

Memotech-Bill commented 2 months ago

As previously discussed (I think) the libraries and examples for the console builds are not in my GitHub project. I have never been able to work out a satisfactory way to do that, given the way the console builds were shoehorned into the BBCSDL project long after it was created.

  1. I really don't see the problem. You already have the BBCSDL/console folder containing console specific items, so what is the problem with creating BBCSDL/console/examples and BBCSDL/console/lib folders? It is the same as what you are suggesting for my repository.
  2. Or as one of many alternatives, create new folders for the BASIC code: 
    BBCSDL/basic
BBCSDL/basic/bin
    BBCSDL/basic/bin/examples
    BBCSDL/basic/bin/lib
BBCSDL/basic/console
    BBCSDL/basic/console/examples
    BBCSDL/basic/console/lib
  3. If you really feel that the console stuff does not live in BBCSDL, then create a separate repository for it. You would have to decide what to do about the common files. So you may end out with three repositories, as per your Venn diagram:
    • BBCcore
    • BBCSDL
    • BBCconsole
  4. Or create a separate repository for the BBC BASIC file (BBCprogs perhaps?). This could contain all the BBC BASIC files, or just those for the console versions.
  5. You could give me the files to host in my repository. However that would make maintenance difficult.
  6. The really messy solution would be for me to write a script that:
rtrussell commented 2 months ago
  1. I really don't see the problem. You already have the BBCSDL/console folder containing console specific items, so what is the problem with creating BBCSDL/console/examples and BBCSDL/console/lib folders?

There's no problem creating those folders, but as I said it does not solve the issue at hand because the Pico does not use the same examples and libraries as the other Console Mode editions. I would have to add (for example) BBCSDL/console/pico/examples and BBCSDL/console/pico/lib and then we would be back to me having Pico-specific files in my repository, which we found before wasn't very satisfactory.

You could give me the files to host in my repository. However that would make maintenance difficult.

But the examples for the Pico are currently in your repository, not mine, so I don't see that maintenance would be made significantly more difficult by also putting the libraries for the Pico in your repository. We decided a long time ago to extract the Pico version from my GitHub account and put it in yours, which I still think is right.

The Pico (and Pico W) are always going to be unique and need different examples and libraries, not least because they have so much less memory (and are so much slower) than any of the other Console Mode editions. They also differ in other respects such as the inclusion of the SOUND and ENVELOPE statements and, of course, the networking capabilities of the Pico W.

Presumably you are also continuing to maintain the self-contained (VGA + keyboard) Pico editions, which I assume also need their own unique set of examples and libraries, several of which probably don't have anything in common with mine anyway (for example graphics examples and libraries).

I think we just have to accept that the Pico versions of BBC BASIC are sufficiently different from all the other versions derived from my source code that there is no perfect solution to the problem of the examples and libraries. It seems to me that the 'least worst' solution is simply to do with the libraries the same thing that you did with the example programs, i.e. include them in your project rather than mine.

Memotech-Bill commented 2 months ago

I was not suggesting that you host any Pico specific code in your repository. I agree that this is best in my repository, where it currently is.

But the whole point of BBC BASIC is that it is standardised. While there are some differences, every attempt has been made to minimise them. Therefore many of the generic console mode programs and libraries will work unmodified on the Pico.

It would be nice if I could pick up any improvements or modifications you make to such programs without having to manually check each time.

With regard to the libraries that you currently supply with the RPi console version of BBC BASIC:

rtrussell commented 2 months ago

It would be nice if I could pick up any improvements or modifications you make to such programs

But it's every bit as likely (if not more likely) that you - or somebody else - will make improvements or modifications to those programs that I might want to pick up and incorporate! Indeed this is especially so since I never use the Console Mode editions myself.

In an ideal world there would be a Console Mode 'champion', somebody who regularly uses it and has a personal interest in the upkeep and maintenance of the libraries and example programs. That is definitely not me!

The following libraries seem to be completely generic to both GUI and console versions, and as far as I can tell should work on the Pico:

Fine. You've already made provision for incorporating them in the Pico build which seems to work, and I'm happy for that to remain. I admit it's a shame about arraylib which is almost generic and could be made so by you supporting SDL_malloc etc.

This discussion has caused me to spot that classlib currently includes a SYS "memmove" which should be SYS "SDL_memmove" so that needs to be fixed, putting it into the same category. So although I was initially unsupportive perhaps you should consider adding the SDL_ functions to those exported by the Pico.

The outlier is socklib which is always going to need to be different for the SDL editions, the Console editions and the Pico W edition. If that's the only library in that category I'm sure some ad-hoc solution can be found (I'd have no major objection to including the Console version in the main BBCSDL/lib directory as socklib_console.bbc).