I'm an unexperienced linux and rtems user trying to build and configure rtems 4.11 environment on a Linux Mint host. I want this environment to compile a RTEMS application for an ERC32 chipset. I'm following the instructions given by the 4.11 version of the RTEMS Source Builder Manual. I've done the suggested steps but when it comes to the building command:
../source-builder/sb-set-builder --log=l-sparc.txt \ <1>
--prefix=$HOME/development/rtems/4.11 \ <2>
4.11/rtems-sparc
it fails and returns:
"Rtems Source Builder - Set Builder, 5 (35c533f545c8) Build set:
4.11/rtems-sparc error: no build set file found: 4.11/rtems-sparc.bset Build FAILED"
I used the command:
../source-builder/sb-set-builder --list-bset
in the list appears:
5/rtems-sparc.bset 6/rtems-sparc.b
set
So I found another question related to this:
no build set file found 4.11/rtems-sparc on rtems (VB)
The answer says to use the following command:
../source-builder/sb-set-builder \
--log=1-sparc.txt \
--prefix=${HOME}/rtems-4.11-work/tools 5/rtems-sparc
note that the 4.11 was replaced by 5. I used this command and the build
worked, however all executables now are like "sparc-rtems5-something".
I tried to compile a hello_world.c example with "sparc-rtems5-gcc" but it
is missing rtems.h
I thought that after the building steps everything including dependencies
would be in their proper directories and the compiler would recognize it.
Also, I've searched for the rtems.h file and I haven't found it in any part of
the system.
After all the history, I have some questions:
1) Is it good or technically appropriate to replace 4.11 by 5 in that
step ? Given that a supposedly I have a 4.11 environment.
2) What is that 5 and 6 directories with each one a sparc bset ?
Why two sparc bsets ?
3) Have been the 4.11 git directories changed over years ? Even
though it is old.
4) Could someone explain how to build properly the rtems 4.11 system
or at least recommend some guide?
It is worth noting that I found the documentation too confusing for a beginner. There are three different explanations of the environment, two in the user guide (quick start and installation sections) and one in the Source Builder docs. Also they differ in instructions. So I don't know which one or which part of each one to follow.
My uname -a command output:
Linux michel-COM 4.15.0-45-generic #48~16.04.1-Ubuntu SMP Tue Jan 29
18:03:48 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux
Short answer first: If you want to build a RTEMS 4.11 toolchain, you have to check out the 4.11 branch of the source builder. Try git checkout -t origin/4.11 in the rtems source builder directory. After that, a ../source-builder/sb-set-builder --list-bsets should list the 4.11/rtems-sparc.bset.
Now for the four questions:
1) Is it good or technically appropriate to replace 4.11 by 5 in that step ? Given that a supposedly I have a 4.11 environment.
If you want a 4.11 toolchain, you should not replace 4.11 by 5. Instead use the 4.11 release branches.
2) What is that 5 and 6 directories with each one a sparc bset ?
Why two sparc bsets ?
The current development version of RTEMS is 5. I would recommend to use RTEMS 5 for most new developments. In general the development version works quite stable and most active projects that I know of use a snapshot of that version. It's also the one with the best community support.
6 is a experimental version of the toolchain only. While 5 uses gcc releases (most of the time), 6 is updated automatically to snapshots. See https://lists.rtems.org/pipermail/devel/2018-December/023954.html for details how that one was created.
3) Have been the 4.11 git directories changed over years ? Even though it is old.
4.11 has been moved to branches.
4) Could someone explain how to build properly the rtems 4.11 system or at least recommend some guide?
You should be able to follow the documentation with the difference, that you have to use the 4.11 branches of all repositories.
It is worth noting that I found the documentation too confusing for a beginner. There are three different explanations of the environment, two in the user guide (quick start and installation sections) and one in the Source Builder docs. Also they differ in instructions. So I don't know which one or which part of each one to follow.
I have to be honest: I haven't started my RTEMS work with the documentation. So I'm not really sure about it's quality. I know that at least some of the points have been addressed in the current (version 5) documentation. For example, the source builder manual has been eliminated.
Related
I'm using CentOS 7 64bit. I'm trying to download multiple packages with their dependencies using yumdownloader. However I'm facing the problem that packages that I do not need are getting downloaded.
When I'm installing a package using yum install <package> only one package is getting installed: either x86_x64 (if available), or i686 (if 64bit is not available) or noarch. I'm trying to mimic the same behavior to download only the best matching packages with yumdownloader. However this does not work as expected and both x86_x64 and i686 are getting downloaded for packages that have 2 architectures available. Adding --archlist=x86_64 does not make any difference. Setting multilib_policy=best in a config file does not make any difference either.
I also checked repoquery tool. If I set --archlist=x86_64 then only x86_64 packags would be listed. Those that have only i686 or noarch versions will not be picked up. If I set --archlist=x86_64,i686,noarch then the result is similar to yumdownloader, i.e. multiple architectures are being picked up.
Is there a way to list or download only best matching package?
The only option I see is to do it completely manually - prepare lists using repoquery and remove duplicates. But I would prefer to find more neat and robust approach.
What you can do, is use the standard yum option for excluding packages. It is "inherited" by yumdownloader.
Example:
yumdownloader libX11 --archlist=x86_64 --exclude="*.i686"
Note that i686 is sort of "subset" to x86_64 due to multilib, and especially applies to libraries (nearly all have i686 equivalent). Make sure you won't have any software that actually requires i686 libraries later on... The only notable example of such i686-only software I've seen is steam.i686 (there is simply no x86_64 version), but then again who plays that on RHEL? (aside from myself).
I'm trying to use VSCode Remote extension to connect to a remote host that runs on RHEL/CentOS 6, but it fails to connect since CentOS 6 ships with GLIBC 2.12 and GLIBCXX 3.4.1. As mentioned in this post, in order to get the extension to work, the workaround is to install GLIBC>=2.17 and GLIBCXX>=3.4.18.
Unfortunately, I don't have sudo access for the server, so I won't be able to update these libraries using the bash script provided in the link. Also, in this SO post, the author says not to update the system GLIBC since it can break down system applications. That being said, I've tried something different -- I extracted those rpm packages, as described in this blog, inside my home folder. I've then updated the env variables PATH and LD_LIBRARY_PATH in ~/.bash_profile to point to these new locations. But the node binary (in VS Code Remote) still can't find these libraries.
Is there a way to let the node binary know where to look for these libraries? More precisely, can someone explain how I can make this extension work without sudo access?
I've got it to work by installing gcc and glibc using Linuxbrew. See this post for more details: https://github.com/microsoft/vscode-remote-release/issues/103#issuecomment-546551293.
Couple of things to take note of:
Node binary versions in VS Code Server may vary between commits. In the GitHub comment above, the author uses node#10 -- you may replace it with node#12; everything would still work.
Make sure glibc and gcc are properly installed using linuxbrew. This step is key.
I need to install SUMO 0.30.0 to be used with the VEINS_INET subproject in veins 4.6. I have tried following the instructions here and suggestions from forums but haven't had any luck being able to install sumo. I run ./configure (trying various tool/library options) then run sudo make but all I get is target marouter failed or nothing to be done for 'install-exec-am' 'install-data-am'.
Does anyone know how to install sumo-0.30.0 from source and/or make the veins_inet subproject work with the latest version of sumo-0.32.0?
Don't run sudo make.
Don't run sudo make.
Your problem is probably related to a dependency/packaging change in 16.04, which is explicitly pointed out in the veins tutorial:
Note that Ubuntu 16.04 no longer includes libproj0; this can be worked around by temporarily adding the packet repository of, e.g., Ubuntu Vivid when installing this package.
Short answer: Unfortunately this means that long-term, you're going to either have to package SUMO yourself, use the versions someone else compiled (see this launchpad for example) or rely on an old version.
Long answer:
In general, I would recommend building SUMO from source by building its' dependencies from source, since I've encountered this problem on various distributions. In particular, the fox, proj and gdal libraries tend to be packaged in different versions, and along with changes in the SUMO source code. I currently use this script (with the package versions downloaded) to compile SUMO -- but this is for 0.30.0, and it breaks if any of the referenced source packages are moved (which happens quite often). My general recommendation would be to either use a completely isolated version of SUMO (i.e., compiling by hand as much as possible) or relying on a pre-packaged version (see above), as long as that version is recent enough to work with VEINS.
I have installed the latest version of Eclipse on my Windows 7 64-bit machine and the mingw compiler. In setting up a Hello World project, all goes well until I am asked for the Cross Settings what the Prefix is and the Path. The Path is obvious, it's the path to the compiler. However, I haven't the slightest idea what the Prefix is and Googling for much of the day hasn't enlightened me other than finding that a lot of other people have asked the question. Unfortunately the answers I've found appear to be for specific hardware. All I want to do is to produce an executable that will run on a Windows 32 bit or 64 bit machine.
So, what is the Prefix and how do I find what it should be?
What is probably happening here is that CDT is not locating your MingW or GCC installations.
simple - but unlikely reason - covering bases
There can be many reasons, from the simple - but unlikely at this point:
You don't have mingw installed
You don't have GCC installed
This can be tested easily by starting a shell and running gcc --version.
CDT heuristic not working
To more complicated reasons relating to your installation not being detected because the heuristic in CDT did not work on your machine. To find the correct settings, CDT will do:
Check $MINGW_HOME/bin for existence
Check <Eclipse install location>/mingw/bin for existence
Look for mingw32-gcc.exe or x86_64-w64-mingw32-gcc.exe on the PATH
Check C:\MinGW for existence
If CDT cannot find any of the above, you may lead to the situation you are in.
So, how to fix it!
Option 1
Start Eclipse from within a mingw set up shell. i.e. the one you can successfully run gcc --version from. That way Eclipse will inherit an environment that can launch GCC successfully.
Option 2
Set your environment up so that MINGW_HOME is properly defined. You can do this at the system level or within the build settings in Eclipse CDT. For example, on my machine in the build settings for the project (Right-click on the project, choose Properties, then choose C/C++ -> Environment) I have set:
MINGW_HOME to C:\MinGW
MSYS_HOME to C:\MinGW\msys\1.0
PATH to ${MINGW_HOME}\bin;${MSYS_HOME}\bin;<my normal path>
and this allows Eclipse to launch gcc as part of the build process.
NOTE The above setting were done automatically on my machine because mingw was correctly located by the heuristic.
Here is a screenshot of the build settings if it helps:
Prefix: Under the hood
To try and answer part of your original question about what Prefix is, I provide the below information. It is unlikely to be particularly helpf
Prefix, in GCC parlance, refers to the directory under which all the related GCC files are placed. With different prefixes you can have multiple GCC installed on your machine.
From the GCC FAQ:
It may be desirable to install multiple versions of the compiler on
the same system. This can be done by using different prefix paths at
configure time and a few symlinks.
The concept comes from autotools in general. Autotools is the standard GNU make system (where you do ./configure && make - simplified). The prefix is the command line option to the configure stage (--prefix) to specify where to install the tool to. GCC above uses the --prefix to allow multiple GCCs on your system.
If you really want to know more about this, read the autobook. The section on configuring covers --prefix:
‘--prefix=prefix’
The –prefix option is one of the most frequently
used. If generated ‘Makefile’s choose to observe the argument you pass
with this option, it is possible to entirely relocate the
architecture-independent portion of a package when it is installed.
For example, when installing a package like Emacs, the following
command line will cause the Emacs Lisp files to be installed in
‘/opt/gnu/share’:
$ ./configure --prefix=/opt/gnu
It is important to stress that this behavior is dependent on the generated files making use of this
information. For developers writing these files, Automake simplifies
this process a great deal. Automake is introduced in Introducing GNU
Automake.
Additionally, Mingw takes advantage of all this prefix options. Read more about that on mingw's site. But the short of it is that the main prefix for mingw is /mingw.
To install RTEMS and all the requirements, I need the install bin to work correctly and it seems not to be the case.
Indeed, when I try "install -c -d tmp/foo/bar" it doesn't create the directories as it should.
On the RTEMS doc, they say I need to upgrade GNU fileutils, but how should I do so? I've search the internet but found nothing...
You can see the concerned RTEMS getting started page here.
I'm running a centos 6.3 virtual machine.
Thanks,
Guillaume
For the original issue, you need to install an updated GNU coreutils. Nowadays, you should use the RTEMS Source Builder (RSB) to get started with RTEMS, because RSB will build all the dependencies you need in a host-independent fashion.