if( len > 0 ) <------------------this
{
/* skip the dot at end if any */
if( len > 0 ) <------------------ and this
if( p[len-1] == '.' )
p[len-1] = '\0';
}
/* -----------------------------------could become */
if( len > 0 ) {
if( p[len-1] == '.' ) {
p[len-1] = '\0';
}
}
The C compiler optimizer probably spots this but anyway...
Today I noticed that we provide binaries for many different Linux versions per Distro. I'm totally not a Linux expert, so please excuse me if this is a silly question, but why is this necessary? Shouldn't it be enough to compile against a old-enough libc and any newer system (using a newer libc version) should be compatible anyways? So why the effort to compile against multiple different Ubuntu versions, for example? Or are there other differences as well? (libcurses/libtinfo would be one dependency I could think of that may changed between different ubuntu versions, but it definitely didn't change for every ubuntu version and still wouldn't explain the amount of binaries we currently have)
The question came up when I saw the aarch64 binaries targeting a pretty new libc version, see viewtopic.php?p=289749#p289749
St_W wrote: ↑Feb 16, 2022 17:34
Today I noticed that we provide binaries for many different Linux versions per Distro. I'm totally not a Linux expert, so please excuse me if this is a silly question, but why is this necessary?
I believe that one package for Debian derived distro's should be enough. However, Arch-based distro's are different in that they are much more up-to-date, which results in library issues such as ncurses5 (still used by Debian) vs ncurses6 (Arch). So binaries compiled against ncurses5 will not run out of the box on Arch derived distro's. Worse, ncurses5 needs to be built from the AUR and that also won't work directly due to a missing verification key. All in all, this is too much effort for those who simply want to install FB and use it.
On top of that, Manjaro has switched to compiling against LTO objects, which fbc cannot. Hence, the current fbc 1.09 from the Arch repository doesn't work (cannot compile source code). This is why I recompiled with LTO turned off (see viewtopic.php?p=289357#p289357)
I use ubuntu for testing and building fbc because the the maintenance cost is low: it's easy to set-up a new version, and it automatically detects my LAN and other resources. Whenever ubuntu asks me to update, I answer yes. New versions (upgrades) get a new virtual machine.
Ideally for me would be that I don't release any binary versions: just the source and a bootstrap package. Then package maintainers (or users) can build their own for whatever version of OS they have. And submit their changes back to developers if they had to change or fix something.
Using Ubuntu is fine I guess as it's probably the most common Linux distro (although I'd probably choose Debian for building). Always upgrading to the latest version makes sense from a developer perspective, but doesn't so much from a build-system perspective. The reason for that is that builds are usually forward-compatible, but rarely backwards-compatible. So if you use the toolchain of a very recent version the binaries will only work on that version or newer versions, which most likely represent a small user-base.
coderJeff wrote: ↑Feb 19, 2022 10:12Ideally for me would be that I don't release any binary versions: just the source and a bootstrap package. Then package maintainers (or users) can build their own for whatever version of OS they have. And submit their changes back to developers if they had to change or fix something.
While I don't think asking the users to compile it themselves could be a reasonable way to go (don't forget about the B in BASIC, as we already heard several times recently ), the proposal of having package maintainers sounds like something that could work.
Not sure where the Arch package maintainer stands currently; I have not yet heard from him nor is there an official updated fbc 1.09 in the arch repo. But I'm happy to offer custom builds for Arch-based distro's (primarily Manjaro) as long as I'm able to build them.
hello coderJeff
the link for the z archive of the 64-bit FB package for inclusion into existing gcc toolchain doesn't work https://downloads.sourceforge.net/fbc/f ... z?download
the zip archive is ok as are the links for the 32-bit version
srvaldez wrote: ↑Mar 25, 2022 15:36
the link for the z archive of the 64-bit FB package for inclusion into existing gcc toolchain doesn't work
Thanks, I believe I have fixed the download links. There were typos in the original news release. If it wasn't obvious, it should be noted that the freebasic packages are for winlibs toolchain and may give troubles using with other toolchains.
I noticed that msys2 project has significantly improved their toolchain options and documentation on their webpages over the last year or so. The packages available for creating native windows applications (i.e. not dependant on msys-2.0-dll) has also improved. None of the freebasic releases I have made to date are specific to msys2's family of toolchains.
Could you include gendef.exe in the next release? It's already a part of winlibs gcc that fbc is using. It's very useful when you don't have to install the whole mingw distro only to use a single binary.