I know we can always use eselect to change the compiler version. My question is that possible to bind different version to different users. For example, I would like root to use stable version for sure. and meanwhile, I would like my normal user to use some edge-cutting version.
I expect some clean solution instead of switch manually by using eselect
Thanks
I really hope you're not using eselect for this. eselect-compiler was killed off years ago because it was experimental and had many problems. gcc-config is what you should be using. Unfortunately it doesn't have per-user support like we have for Java. You can always call the specific version explicitly (e.g. gcc-4.6.2 instead of just gcc). If you're building software with autotools then you can do it with...
CC=gcc-4.6.2 ./configure
make
You can use gcc-config to print the environment variables necessary to use a specific GCC version. For example, to use gcc-7.2.0 for the remainder of your shell session:
eval "$(gcc-config --print-environ x86_64-pc-linux-gnu-7.2.0)"
Related
I am trying to build the apcupsd package under a newer version of MacOS and Xcode, but the configure script supplied with the current version of apcupsd breaks under Xcode 12.4 (though it worked under Xcode 11.2).
The error is gethostbyname_r is required. Now, configure tests for this function, and ordinarily it adapts to systems that do not provide it. On the newer Xcode version, however, configure just exits with an error. I THINK it has something to do with Apple making the -Werror setting mandatory. I've found that I can get a successful build by commenting out the broken test in configure, then running it and explicitly passing the flag that configure is supposed to set. But that's not very satisfactory.
Is there is a general way to pass an override to configure for the compiler? I tried setting -Wno-error in the CPPFLAGS and CFLAGS environment for configure, but the configtest program seems to ignore those. What seems to be going on is configure is seeing that gethostbyname_r doesn't exist and sets it to no but then later on still tests for it. I'm just wondering if there's a flag or something to get past this error, as it seems to me that whatever Apple did to break (or fix) Xcode after version 11.2 would have broken a lot of people's projects.
I am looking for a solution that does not involve modifying the program sources or the Autotools input files. The project manual is not helpful in this regard.
As an update: someone on the apcupsd list told me that this issue is fixed in a later version of Xcode. I have not tried that yet but when I do if that is what it proves out to be I'll post a followup
Is there is a general way to pass an override to configure for the
compiler? I tried setting -Wno-error in the CPPFLAGS and CFLAGS
environment for configure, but the configtest program seems to ignore
those.
If you set the CFLAGS or CPPFLAGS variable in configure's environment, then not only should configure use those flags when it builds test programs, but it should also memorialize the variable so that you don't need to specify it again to make. Indeed, this ...
What seems to be going on is configure is seeing that
gethostbyname_r doesn't exist and sets it to no
... suggests that it is doing so in your case.
In that event, if it seems to test again later, or else to fail in some other way despite determining that the function is not present, then that suggests a flaw in the project's own autotooling.
I'm just wondering if there's a flag or something
to get past this error,
You have already tried the most likely candidate (CFLAGS). Alternatively, you might also be able work around the issue through use of a cache file. That's still hacky, but I think less so than modifying the configure script. I'm afraid I have no specific guidance on doing this.
as it seems to me that whatever Apple did to
break (or fix) Xcode after version 11.2 would have broken a lot of
people's projects.
It did. That does not imply that there is a quick or easy solution, though it would be good news if indeed Apple solved the issue in a later version of Xcode.
SO!
Let's say I have a number of settings (GCC compiler 9.3.0 built from source, as the distribution I have to use has a very old one, along with environment setup) for a new Kit in QtCreator.
I have managed to setup an environment for compilation and execution of compiled binaries, and made a script to make it work (like qmake -nocache -recursive/make/sudo make install, direct execution of g++, and other stuff).
One thing that script can't do at the moment, is that it cannot create a kit for QtCreator with new compilers and environment being set as required, so after running a script, its user has to go through setting it up himself through GUI, which is bad, because this can cause misconfiguration.
This thing I'm trying to create is going to be used by around ~200 people in my company, so leaving readme.txt with instructions just doesn't go well enough for me - I don't want running around fixing missing "{" and "}" in Environment description in created Kits, and other stuff.
Are there ways to create Kits for QtCreator automatically from command line? Maybe, there's some files to edit?
I've looked into this one a few years back (I wanted to do something similar for registering Buildroot toolchains automatically in QtCreator), and I was unable to find an off the shelf solution. So i think there are 2 ways to implement this:
a) Implementing a command line utility the manipulate the ~/.config/QtProject/qtcreator/{toolchains,profiles}.xml files. Maybe by (re)using the existing C++ implementation within QtCreator, or just re-implement it ie. in Python. Back than I didn't start to work on this as there was no real business need.
b) Switching to qbs, as qbs has support for setting up toolchains from the command line ( see: https://doc.qt.io/qbs/cli-setup-toolchains.html)
If you decide to go with solution a), please let me know and maybe we can partner up to implement it.
Check out the command line sdktool bundled with QtCreator:
The SDK tool can be used to set up Qt versions, tool chains, devices
and kits in Qt Creator.
There still is a lot of knowledge about Qt Creator internals required
to use this tool!
I haven't tried it yet, but I did find the executable under Tools/QtCreator/libexec/qtcreator subdirectory of the Qt Creator installation directory. ./sdktool --help works for me under Linux.
I want to various projects for various platforms, and as such I've concluded that the easiest way to to this is probably going to just have buildroot create the toolchain and then alter the environment to use said toolchain.
From section 8.14.1 of the buildroot manual:
For your convenience, by selecting the option
BR2_PACKAGE_HOST_ENVIRONMENT_SETUP, you can get setup-environment
script installed in output/host/and therefore in your SDK. This script
can be sourced with . your/sdk/path/environment-setup to export a
number of environment variables that will help cross-compile your
projects using the Buildroot SDK: the PATH will contain the SDK
binaries, standard autotools variables will be defined with the
appropriate values, and CONFIGURE_FLAGS will contain basic ./configure
options to cross-compile autotools projects. It also provides some
useful commands. Note however that once this script is sourced, the
environment is setup only for cross-compilation, and no longer for
native compilation.
Alright, that sounds pretty much like exactly what I want. However, I have not figured out how to set BR2_PACKAGE_HOST_ENVIRONMENT_SETUP. I found no mention of anything similar when looking through make menuconfig, I tried to grep the entire buildroot source tree for that string with no luck, and simply exporting it as an environment variabl did not produce a different result either. So, how do I set BR2_PACKAGE_HOST_ENVIRONMENT_SETUP, exactly?
I just stumbled across the same problem. The option was submitted in April 2020, so buildroot-2020.02.8 (the long term support version as of writing) doesn't support it, whereas the PDF available online is newer -- I suspect you are using the same version; the buildroot download page presents the longer term support version first.
In menu-config, you do a search ("/") of HOST_ENVIRONMENT and then you find your answer:
screenshot
I love coding in Haskell, but often am on a computer where I cannot install software, and which has some restrictions about what you can run. I would like to write Haskell code and test it while on this computer. Does anyone know of version of Haskell, interpreted or compiled, written in Java, JavaScript, Ruby, Python, or another interpreted language available in the default install on a Mac? A standalone version of Haskell which can be installed at the user level works too, but compiling Haskell myself is not an option.
The GHC binary distributions (the ones that come as tarballs, not installers) all can be installed locally trivially easily.
./configure --prefix=$HOME/ghc
make install
Then update your path to include $HOME/ghc/bin
If you want cabal, get the tarball from hackage, then untar it and run bootstrap.sh.
GHC works really well as a local install. In fact, I never use it as a system install.
I do this on my workstation, too, so that the distribution I'm on (Debian in my case) doesn't suddenly start upgrading stuff without me noticing in a simple apt-get upgrade.
This solution installs a full ghc and haskell-platform as well as ~/.cabal prefix.
First of all, I have a ~/local directory that I use in order to put custom-compiled programs in my home directory. I usually dislike the sudo make install step, because I'm giving some random Makefile root access to my system, and that makes me feel queasy.
Then I download the ghc binary distribution from the ghc site. NOTE that I linked you to 7.4.2. I hear there's some segfault bug on Mac OS X, but I'm not aware of the details. You should check that out or get the newer ghc instead, but be aware that there are many packages on hackage that are not yet fixed to work with 7.6. Also, ignore that "STOP!" warning, you're the 1% who actually want a non-distrib GHC binary.
You can just cd into the ghc directory, then do ./configure --prefix=$HOME/local/haskell or so, followed by make install (no compiling necessary, it's just going to install, not compile.)
At this point, you should add ~/local/haskell/bin to your path. Here's the code that I put in my ~/.zshrc, which will add all ~/local/*/bin directories to your path.
You can then get the Haskell Platform, and do the same ./configure --prefix=$HOME/local/haskell && make && make install dance. This step will need compilation. It means that you will need some header libraries installed. I find the random openGL headers that are necessary particularly annoying.
You can also of course skip haskell-platform, and just download cabal-install directly, then install what you need. You should in any case not forget to add ~/.cabal/bin to your $PATH!
Do a cabal update and you should be good to go.
NOTE: there's one important part that the binary distribution of GHC needs, which can sometimes be a pita on old Linux systems: libgmp. It's linked dynamically against it, and if you get some errors about the shared libgmp not being found on OS X, too, you can… well, ask that question in a comment, and I shall explain how to get there. Basically, you'll have to compile libgmp + deps yourself.
But I don't think that should be a problem on OS X. It's just been a problem on a couple old debian boxes I've tried this on.
For single files, you can use codepad.
When compiling from source, I never know which configure flags to use to optimize the compilation for my environment. Assume the following hardware/OS:
Single Core, 2 GHz Intel
512MB Ram
Debian 4
I usually just go with
./configure --prefix=/usr/local
Should I be doing anything else?
I always use Debian packages. Compiling from sources can break your development environment during libraries conflicts and such problems are hard to detect.
You might want to check those few options out, which may be required by a Ruby On Rails environment, in which case they should be compiled. Just make sure the directory corresponds to your current settings.
--with-openssl-dir=/usr --with-readline-dir=/usr --with-zlib-dir=/usr
I recommend mixing in a few packages from Debian Unstable feeds. They tend to be pretty stable, despite the name. They're also very up to date.