I'm working on a project in the D language and I want to use a module from the standard library called std.sumtype. I'm on debian oldstable, and I've tried both GDC and LDC. DMD is unavailable, because I'm using a machine with an armhf architecture. Neither of these compilers can find std.sumtype, despite it being in the standard library. I also tried downloading 3 different versions of sumtype.d from the phobos repositories of all three D compilers. Each of these would not compile. How can I use this? Am I on the wrong version?
std.sumtype is a pretty new package that was added in 2.097.0: https://dlang.org/changelog/2.097.0.html#std-sumtype so the debian oldstable packages probably don't have it yet as you would need at least:
DMD 2.097.0
LDC 1.27.0 (beta.1 or above)
upcoming GDC in May 2022 (see announcement)
If you want to use the latest compiler you could always download the latest LDC archive and extract it somewhere and run it from there or use the install.sh script from the download page for portable and multiple simultaneous installs.
std.sumtype is an adoption of the dub package sumtype so if you are using dub, you can depend on that as well and not need to get another compiler outside the package manager.
Related
I am programming the Raspberry Pi Pico-W and I would like to link against the C++ STL, in order to use some of the Standard Library functionalities and containers.
I have found the package on Ubuntu, which I used in a professional development environment and I therefore also wanted to install it on Fedora 36, but found it missing in the official and unofficial repositories.
Following packages are available to me currently, so it is really just the libstdc++ that is missing, since the C Library (newlib) is there.
arm-none-eabi-binutils-cs.x86_64
arm-none-eabi-gcc-cs.x86_64
arm-none-eabi-gcc-cs-c++.x86_64
arm-none-eabi-newlib.noarch
libstdc++.i686
libstdc++.x86_64
libstdc++-devel.x86_64
One option I got recommended was to get the headers manually from arm itself, which also includes the rest of the toolchain.
Is there some package I am missing in the Fedora repositories, or is it just really not available as one package?
Fedora does not seem to provide such packages and I have also not been able to find copr repos for that.
Therefore the only solution left, was to install directly from arm.
This link gives a short guide for those that need it.
Additionally, since I am using NeoVim with its built-in lsp, I need to add a flag to the clangd configuration, namely --query-driver=/*/*/bin/*gcc, which globs for the compiler found in the compile commands. But this only as a side note.
After that everything seems to work as one would expect.
C++17 is coming out, and I'm hoping to use it in some upcoming projects. How can I install GCC-7.1.0 on windows without relying on Cygwin? I have a version of mingw already installed on my computer, and I've downloaded and unpacked the folder containing the source code for gcc-7.1.0. How can I use my current version of the gcc compiler to compile gcc-7.1.0? Is there a sequence of commands I can carry out in the windows command prompt to do this?
The easiest way to install a recent GCC is to use the MinGW distribution provided by Stephan T. Lavavej at https://nuwen.net/mingw.html
He provides a download of precompiled-binaries as well his build script. So you can either download the current version or use his build scripts to compile your chosen version.
Right now I compile my C++ software on a certain old version of linux (SLED 10) using the provided gcc and it can run on most newer versions as they have a newer glibc. Problem is, that old gcc doesn't support C++11 and I'd really like to use the new features.
Now I have some ideas, but I'm sure others have the same need. What's actually worked for you?
Ideas:
Build on a newer system, static link to newer glibc. (Not possible, right?)
Build on a newer system, compile and link against an older glibc.
Build on an older system using an updated gcc, link against older glibc.
Build on a newer system, dynamic link to newer glibc, set RPath and provide our glibc with installer.
As a bonus, my software also support plugins and has an SDK. I'd really prefer that my customers could compile against my libraries without a huge hassle.
Thanks in advance. Ideas welcome, proven solutions preferred.
Build with the newer gcc. Either install the new compiler on the old machine or comile on your new machine and install the necessary dynamic libraries on the old machine.
Note that multiple versions of libc (and also libstdc++) are supported on a single machine since they are typically versioned (i.e. libc.so.5, libc.so.6, etc)
My question is simple... How could I check the version of GMP installed on my machine? What about MPFR? And What about CamlIDL?
Thank you very much
To check for GMP(MPIR) version, access string __gmp_version(__mpir_version) in dynamic library called libgmp.so.X.Y.Z(libmpir.so.X.Y.Z). Your standard library directory might contain more than one such file (this happens if you install newer version of GMP or MPIR but your package manager chooses to keep old version because it is still needed).
Cutting off a small Python code fragment from benchmark_det_Dixon.py:
import ctypes
so_name='/usr/lib/libgmp.so' # or /usr/lib64/libgmp.so, etc
var_name='__gmp_version'
L=ctypes.cdll.LoadLibrary(so_name)
v=ctypes.c_char_p.in_dll(L,var_name)
print(v.value)
The code above only works under Linux/Unix; it should be possible to port it to other OS supported by ctypes Python package.
To get MPFR version, call mpfr_get_version():
M=ctypes.cdll.LoadLibrary('/usr/lib/libmpfr.so') # or /usr/lib64, etc
M.mpfr_get_version.restype=ctypes.c_char_p
print(M.mpfr_get_version())
The standard Autoconf way to do this is to pick some library function that's in required minimum version X and not in version X-1, then see if you can successfully compile a tiny program that calls that function. It's not as elegant as querying some oracle for a version string, but it has the advantage of demonstrating that the build environment is actually correct.
Is it possible to have different GCC installations working with one MinGW installation?
By MinGW I mean the common base which is always needed regardless which version of GCC compiler we're going to install and use;
MinGW runtime
binutils
make
MinGW API for MS-Windows
and many other components which are part of MinGW but are not even required by GCC.
MinGW is a GCC installation. Are you asking "can I have multiple versions of MinGW installed?" - Yes you can. Simply download and install the different MinGW vertsions in different directories. MinGW comes with a .BAT file that when run sets up the local environment for that particular version.
If this isn't the answer you are after, please expand your question.
To anwer which:
There is no MinGW runtime - it uses the Windows libraries.
if you don't want make, delete it or use an alternative
binutils - there may be dependencies between these and the compiler, I'd recommend keeping separate versions for each MinGW installation.
The Windowsheaders? I guess you could centralise them.
But why would you want to do this? It's much easier and convenient to have completely separate installations. And the space they take up is nothing on even a half-modern PC.
Do you mean you want to have multiple versions of GCC available to your MinGW environment? I don't believe that would be a problem, GCC is just a set binaries that come with a MinGW install.
You should be able to download older/newer versions of the binaries and put them in the $BIN path and they should work properly. You'd obviously have to make sure to have different names for the different versions.
Otherwise, I'm not completely sure what you mean about multiple "GCC installations."