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.
Related
I'm attempting to build an image with the phytec bsp 18.2 from here: https://wiki.phytec.com/productinfo/phycore-i-mx7/bsp-yocto-fsl-imx7/
I require a newer version of systemd (> 234) and so am substituting the systemd recipe for version 234 from rocko, found here: http://cgit.openembedded.org/openembedded-core/tree/meta/recipes-core/systemd?h=rocko by putting this in a custom layer. However, during the do_rootfs step, I receive an error that "No package provides libsystemd.so.0(LIBSYSTEMD_219). I've tried a work-around recommended here: Smart can't install...no package provides shared object file and it didn't solve the issue. I've tried echoing libsystemd.so.0, LIBSYSTEMD_219, and libsystemd.so.0(LIBSYSTEMD_219) to both ${rootfs}/etc/rpm/sysinfo/Providename and ${rootfs}/var/lib/rpm/Providename and had no luck. Does anyone have an idea on how to fix this? I'd appreciate any help that could be offered, and please let me know if I can offer any more information.
I don't know about the yocto wrapper, etc, but in standard RPM-land, this error:
Computing transaction...error: Can't install python3-systemd-234-r0.0#cortexa7hf_neon: no package provides libsystemd.so.0(LIBSYSTEMD_219)
means that there is a .so or executable in the RPM named python3-systemd-234-r0.0 that was compiled with a specific version of libsystemd.so.0 that had the flag LIBSYSTEMD_219. That flag is the "ELF Symbol Versioning" and it's seen most with GLIBC_XX when you try to install an RPM that's too new for a target system (e.g. CentOS 7 RPM on CentOS 6).
The systemd on your target machine is too old, so it only defines the versions it is compatible with, e.g. libsystemd.so.0(LIBSYSTEMD_210) or similar.
What you need to do is build your python3-systemd-234-r0.0 on a machine with the same version of systemd as the target (or cross-compile appropriately), or create a systemd RPM that includes the functionality you're attempting.
So you need to figure out how to apply one of these solutions to your build system; sorry I don't know enough about yocto to help there.
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.
Is there a way to install multiple versions of the same package in CentOS/RHEL (7/8) if the package installs separate files in each version?
We have an application we've recently converted to using RPM instead of a home-built package manager based on tar. In order to make atomic-like switches between versions, each version installed in separate directories with the version number in the name, and a symlink with the unversioned name pointed to the current, or previous, version at any given moment in time. The application, of course, used the unversioned name to get init script, configuration files, interpreter version and code. I'm thinking that the alternatives package would be the basis for this, although we wouldn't use the alternatives command to manage symlinks (although there's no technical reason not to).
Not exactly as you describe.
Some packages allow this (Kernel and Kernel-devel being two of them) but i beilieve this is an exception added within the package manager.
Certain Applications like PHP and Python which is perfectly acceptable to have multiple version (Python2.X and 3.X) do this by changing the base name of the application/rpm.
Take a look at: https://rpm.org/user_doc/multiple_versions.html
It gives a good insight on how to achieve what you want
I am trying to build some source code on ubuntu 16.04 where one of the classes relies hierarchy_simplify_point_set.h header file, which is part of CGAL's point set package. After following instruction on the installation page, I have installed libcgal-dev and libcgal-qt5-dev via apt-get. The package manager has installed libcgal-dev 4.7 which should include the point set library. However, the particular header file seems to be missing (it seems to have some files from the point set library and not others - I am looking in /usr/include/CGAL). Does anyone know what I am doing wrong?
ps: For good measure, I have already tried uninstalling and reinstalling both the packages, but no luck.
This header has been introduced in CGAL 4.8 while it seems you are using CGAL 4.7.
You can get the latest version of CGAL here. Since the latest versions can be used as a header-only library, simply extract the release archive somewhere and set CGAL_DIR to that location when calling cmake to configure your example and it should work directly.
I want to setup a cross compile environment on Linux for the Raspberry Pi 1.
Especially I want to try bleeding edge version, i.e. Raspbian testing + Qt5 dev branch.
This question:
How can I create a modern cross compile toolchain for the Raspberry Pi 1?
...explains how to get a gcc compiler, which can create code for the Raspberry Pi 1. Are there changes necessary on Raspbian itself to use it? If so, which ones?
A full toolchain is what you need
A toolchain is a set of tools working together to generate binaries for your system. Depending on how you build your toolchain, it might end up in being only functional for your own image, that's not, in fact a problem, you just clone your image and upgrade it at will.
First, understand what you need:
Functional flagship system. This is your reference board and your reference distro bundle, your packages and your stuff. You might want a standard Raspbian or you might want some extra stuff, like OpenCV or less stuff like removing Xorg. You say you want bleeding edge, so fit your taste.
Sysroot. Ideally this is a copy of your Functional Flagship System with the added development headers. In my case its exactly the same, for Raspbian this is an image of your second partition, the one that hosts /.
Cross compiler. This is a compiler that generates code for ARM while running on x86 or x86_64. This is generally a specialized gcc.
Cross compiled qmake. For Qt you need a cross qmake, this is a qmake that will generate Qt binaries and uses things you need to generate your arm Qt software.
ARM Qt libraries. This is part of your Functional Flagship System, I just enumerate it here for the sake of clarity. They will get compiled by you using your sysroot and your cross compiler.
Qt Libraries for Cross Compiling. This are a product of the steps you will follow when generating your cross compiling qmake and ARM Qt Libraries. This will be installed in your host x86 system.
So how do you get all of this?
Gather Your Very Own Toolchain
Functional Flagship System (FFF). Just get your raspbian image and install your additional software at will, whatever you want to be in, just install it on a live Raspberry.
Sysroot. Once you have your FFF, then use dd to generate an image of your second raspbian partition. Get your card off, insert it into a x86 system and use dd. There are other ways using mount and offsets but this is a lot simpler.
Cross compiler. Unless you really know what you are doing, just refrain from creating it yourself. There are functional cross compilers.
Qmake for cross compiling, ARM Qt and Qt Libraries. This is the interesting part...
Cross Compiling Qt 5
You can go as bleeding edge as you please with Qt as you get it from git. As this is not really a Wiki I will just enumerate the steps. This guide explains it with a lot more detail.
Get your FFF, image and cross compiler working.
git clone your Qt, pick a tag (version)
mount your sysroot
Get ia32-libs if you are under x64
Compile qtbase then make install. IMPORTANT: After you get qtbase it generates it's own qmake, use it from now on.
Use the generated and installed qmake from qtbase to build any other Qt module you want.
Remember to use make install on all Qt modules you build. All these 'installs' will copy those binaries to your sysroot.
Get your Qt into your FFF. Either you copy the folder and avoid messing with permissions, or more easily just umount your sysroot, then use dd to dump the modified image to the very same physical partition you got it from. These are the ARM Qt Libraries.
When building qtbase it will install some stuff into your own x86 system. This is Qmake for cross compiling, use it into Qt Creator to generate cross compiled binaries along with your cross compiler.
Some notes nobody tells you
There seem to be no toolchains ready to download. This is because they depend a lot on your specific setup.
Do not use system or regular qmake to cross compile. Use your generated qmake, as it fits perfectly with your FFF, it has paths and other specific stuff baked in.
I repeat, do not bother creating your cross compiler
What if you need additional development files? Install them on your FFF, then copy your partition to have your new sysroot.
Yes, you can auto-deploy with Qt and even debug remotely on a live Pi.
Installing a bleeding edge development system/toolchain is a bit of a problem... It is a moving target. The following steps did work for me March 2015. If they still 100% work or how long they will work... But if one have read and understood the following 'walktrough' it should not be difficult to adjust the process for future Raspian or Qt5 versions.
Fist step should be to update Raspian. I upgraded to testing. To do this, change the repository in /etc/apt/sources.list to:
deb http://mirrordirector.raspbian.org/raspbian/ testing main contrib
non-free rpi
Followed by the usual 'apt-get update, apt-get upgrade, apt-get dist-upgrade'. Or an analogue aptitude command. After this step one has upgraded to the most recent Raspian. With all the risks and benefits of a testing release.
Next a couple of packages needs to be installed. Probably not all necessary, e.g. xcb does not work on a RPi, and the RPi hat its own set of opengl files. But some Raspian packages don't know this and might pull them in anyways. The packages below allow to compile a Qt5 with QMultimedia and
apt-get install -y "^libxcb.*" libx11-xcb-dev libglu1-mesa-dev libxrender-dev libxi-dev libicu-dev libxslt1-dev
apt-get install -y libssl-dev libxcursor-dev libxrandr-dev libfontconfig1-dev libcap-dev libbz2-dev libgcrypt11-dev
apt-get install -y libpci-dev libnss3-dev libxtst-dev libasound2-dev libcups2-dev libpulse-dev libudev-dev
apt-get install -y libgstreamer1.0-dev libgstreamer-plugins-base1.0-dev libproxy-dev libmtdev-dev libts-dev
apt-get install -y libxkbcommon-x11-dev libxkbcommon-dev libinput-dev libgbm-dev libjpeg8-dev libgif-dev libopenjpeg-dev
apt-get install -y libgstreamer0.10-dev libgstreamer-plugins-base0.10-dev sqlite3 libsqlite3-dev libwayland-dev
apt-get install -y libdirectfb-dev libegl1-mesa-dev libsystemd-journal-dev libharfbuzz-dev xutils-dev libcairo2-dev
apt-get install -y libffi-dev libpam0g-dev
The next and most important step is also the most unpleasant one. A couple of libraries in Raspian are symbolic links with absolute paths. This is bad since those libraries are later on not found when Qt5 is compiled. All symlinks of relevant libs must be turned into symlinks with relative paths. With Google's help a script can be found, which did this almost automatically, but for some reason it did not work for me. Therefore I did it manually. If I have to do this more often, I certainly will write my own. This is also the step, which is most likely to break. Library versions change... so don't blindly copy/paste the commands below.
Not all of the libs below are necessary to compile Qt5, but all of them could be a problem eventually. After this step the Raspberry Pi is ready to be used. Next step is to compile and install Qt5.
EDIT: One of the side effects of writing such a mini-tutorial: One thinks again about certain things one has done. There is a much easier way to convert absolute links into relative links: symlinks.
So:
apt-get install symlinks
And then in /usr/lib/ on the Raspberry Pi:
symlinks -cr .