My g++ version is Ubuntu 5.4.0:
g++ --version
g++ (Ubuntu 5.4.0-6ubuntu1~16.04.12)
From the man page, I see this:
c++14
c++1y
The 2014 ISO C++ standard plus amendments. The name c++1y is deprecated.
gnu++14
gnu++1y
GNU dialect of -std=c++14. The name gnu++1y is deprecated.
c++1z
The next revision of the ISO C++ standard, tentatively planned for 2017. Support
is highly experimental, and will almost certainly change in incompatible ways in
future releases.
Does that mean "-std=c++1z" for c++17? I am confused what should be used for c++17 because some programs just use "-std=c++17" directly and compiled successfully using this g++.
These 3 steps can update Ubuntu gcc/g++ from default 5.4.0 to 8:
sudo add-apt-repository ppa:ubuntu-toolchain-r/test
sudo apt-get update
sudo apt-get install gcc-8 g++-8
Related
I followed the instructions according to https://tug.org/texlive/quickinstall.html
I am using Ubuntu 22.04.1 LTS on Windows 11 WSL.
I cannot get past this error when doing anything with tlmgr. Beforehand, I needed to run tlmgr init-usertree.
$ sudo tlmgr install adjustbox
(running on Debian, switching to user mode!)
(see /usr/share/doc/texlive-base/README.tlmgr-on-Debian.md)
tlmgr: Local TeX Live (2021) is older than remote repository (2022).
Cross release updates are only supported with
update-tlmgr-latest(.sh/.exe) --update
See https://tug.org/texlive/upgrade.html for details.
$ sudo tlmgr update --self
(running on Debian, switching to user mode!)
(see /usr/share/doc/texlive-base/README.tlmgr-on-Debian.md)
tlmgr: Local TeX Live (2021) is older than remote repository (2022).
Cross release updates are only supported with
update-tlmgr-latest(.sh/.exe) --update
See https://tug.org/texlive/upgrade.html for details.
As far as I can tell, I have installed the most up-to-date version:
$ tex --version
TeX 3.141592653 (TeX Live 2022)
kpathsea version 6.3.4
Copyright 2022 D.E. Knuth.
There is NO warranty. Redistribution of this software is
covered by the terms of both the TeX copyright and
the Lesser GNU General Public License.
For more information about these matters, see the file
named COPYING and the TeX source.
Primary author of TeX: D.E. Knuth.
$ tlmgr --version
tlmgr revision 63068 (2022-04-18 07:58:07 +0200)
tlmgr using installation: /usr/local/texlive/2022
TeX Live (https://tug.org/texlive) version 2022
I have tried removing everything TeX and trying again but receive the same error. Any help is appreciated!
I found the silly error, my version of tlmgr was in fact outdated, but only when using sudo:
$ tlmgr --version
tlmgr revision 63068 (2022-04-18 07:58:07 +0200)
tlmgr using installation: /usr/local/texlive/2022
TeX Live (https://tug.org/texlive) version 2022
$ sudo tlmgr --version
tlmgr revision 60693 (2021-10-04 04:24:25 +0200)
tlmgr using installation: /usr/share/texlive
TeX Live (https://tug.org/texlive) version 2021
I want to install janus-gateway on CentOS7.
I read the following document and tried installation.
https://github.com/meetecho/janus-gateway/blob/master/README.md
git clone https://github.com/meetecho/janus-gateway.git
cd janus-gateway
sh autogen.sh
./configure --prefix=/opt/janus
However, configuring janus-gateway will cause an error. The error is as follows.
checking if libtool supports shared libraries... yes
checking whether to build shared libraries... yes
checking whether to build static libraries... no
checking for pkg-config... /bin/pkg-config
checking pkg-config is at least version 0.9.0... yes
checking for JANUS... no
configure: error: Package requirements (
glib-2.0 >= 2.34
libconfig
nice
jansson >= 2.5
libssl >= 1.0.1
libcrypto
) were not met:
No package 'nice' found
Consider adjusting the PKG_CONFIG_PATH environment variable if you
installed software in a non-standard prefix.
Alternatively, you may set the environment variables JANUS_CFLAGS
and JANUS_LIBS to avoid the need to call pkg-config.
See the pkg-config man page for more details.
I installed libnice(libnice-0.1.3-4.el7.x86_64) in the following way.
yum install libnice
How can I solve it?
Thank you.
try this and rebuild
echo "export PKG_CONFIG_PATH=/usr/lib/pkgconfig" >> ~/.bashrc
source ~/.bashrc
Disclaimer: I am using Ubuntu 18.04 when testing this.
If you are using Ubuntu system and trying to install Janus and running this code
./configure --prefix=/opt/janus
And then getting this error: No package 'nice' found
Make sure you have been installation of the nice from aptitude.
sudo install aptitude
aptitude install libmicrohttpd-dev libjansson-dev \
libssl-dev libsrtp-dev libsofia-sip-ua-dev libglib2.0-dev \
libopus-dev libogg-dev libcurl4-openssl-dev liblua5.3-dev \
libconfig-dev pkg-config gengetopt libtool automake
For some reason installation of nice using the answer from Frank, Ahmet or Zallfire doesn't work in Ubuntu. It has to be installed using aptitude.
You should download libnice source code to install.
https://gitlab.freedesktop.org/libnice/libnice
You need the development libnice.
yum install libnice-devel
abigail#abilina:~/Downloads$ sudo dpkg -i cuda-repo-ubuntu1604_8.0.61-1_amd64.deb
Selecting previously unselected package cuda-repo-ubuntu1604.
(Reading database ... 205999 files and directories currently installed.)
Preparing to unpack cuda-repo-ubuntu1604_8.0.61-1_amd64.deb ...
Unpacking cuda-repo-ubuntu1604 (8.0.61-1) ...
Setting up cuda-repo-ubuntu1604 (8.0.61-1) ...
Warning: The postinst maintainerscript of the package cuda-repo-ubuntu1604
Warning: seems to use apt-key (provided by apt) without depending on gnupg or gnupg2.
Warning: This will BREAK in the future and should be fixed by the package maintainer(s).
Note: Check first if apt-key functionality is needed at all - it probably isn't!
Warning: apt-key should not be used in scripts (called from postinst maintainerscript of the package cuda-repo-ubuntu1604)
OK
abigail#abilina:~/Downloads$ sudo apt-get install cuda
Reading package lists... Done
Building dependency tree
Reading state information... Done
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:
The following packages have unmet dependencies:
cuda : Depends: cuda-8-0 (>= 8.0.61) but it is not going to be installed
E: Unable to correct problems, you have held broken packages.
My ubuntu version is 17.04. Does this mean my Linux currently can't install CUDA? I want to install TensorFlow with GPU support.
Per suggestion:
abigail#abilina:~/Downloads$ sudo apt-get -f install
Reading package lists... Done
Building dependency tree
Reading state information... Done
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
https://launchpad.net/ubuntu/zesty/amd64/nvidia-cuda-toolkit
above is the correct one.
apt-get install nvidia-cuda-toolkit
but remember the cuda installed through apt were installed in different location. manually create ln -s at /usr/local/cuda for include,lib64,and bin
I have successfully installed CUDA 8.0 + the latest patch from NVIDIA on Ubuntu 17.04:
Download the .run file from https://developer.nvidia.com/cuda-downloads, choosing Ubuntu 16.04 (Base Installer)
You will not be able to install it by just running, because it is looking for a file called InstallUtils.pm which is not present in Ubuntu 17.04, but curiously, is present in the .run file - so: unpack the .run file using ./cuda*.run --tar mxvf
copy InstallUtils.pm (should be in the /bin path) to /usr/lib/x86_64-linux-gnu/perl-base
Run the installer (You may want to say no to the driver install step to keep the one you install through apt - I'm using 381.22, because 375.26, which is provided by the .run file does not support my 1080ti)
gcc 6 is incompatible with CUDA, but this is easily remedied for compiling the sample files: just add export EXTRA_NVCCFLAGS="-Xcompiler -std=c++98" to your bashrc file, and comment out
from one of the headers (I think it was host_config.h, but you'll see it once you try to compile) - comment out these lines:
#if __GNUC__ > 5 || (__GNUC__ == 5 && __GNUC_MINOR__ > 3)
#error -- unsupported GNU version! gcc versions later than 5.3 are not supported!
This is all from memory, so hopefully it's accurate enough.
I managed to find this solution thanks to these useful posts:
https://devtalk.nvidia.com/default/topic/983777/can-t-locate-installutils-pm-in-inc/
https://devtalk.nvidia.com/default/topic/949770/cuda-8-0rc-supporting-gcc6-/
For ubuntu 17.04, I had to use cuda 9.0 (deb version)
https://developer.nvidia.com/cuda-release-candidate-download
I couldn't get it to work otherwise. Cuda 8.0 needs gcc 5.3.1 but cuda 9.0 is compatible with gcc 6.3.0 which is installed on ubuntu 17.04 automatically.
More precisely, this is what I did:
On Ubuntu 17.04, install CUDA 9.0 — you can currently download the beta version
https://developer.nvidia.com/cuda-release-candidate-download
I downloaded the .deb file and haven’t had any problems — follow the steps they recommend when you download cuda 9.0
sudo dpkg -i cuda-repo-ubuntu1704-9-0-local-rc_9.0.103-1_amd64.deb
sudo apt-key add /var/cuda-repo-9.0-local-rc/7fa2af80.pub
sudo apt-get update
sudo apt-get install cuda
Then follow the post installation steps from the nvidia instructions (i.e., setting PATH and LD_LIBRARY_PATH)
http://docs.nvidia.com/cuda/cuda-installation-guide-linux/index.html#post-installation-actions)
export PATH=/usr/local/cuda-9.0/bin${PATH:+:${PATH}}
export LD_LIBRARY_PATH=/usr/local/cuda-9.0/lib64 ${LD_LIBRARY_PATH:+:${LD_LIBRARY_PATH}}
Cuda 9 is compatible with gcc 6.3.0 (which comes with 17.04). I used arch=sm_52 and sometimes for my make files have to go ‘make clean’.
Installing Cuda 9.0 was the simplest solution in my case.
Alternatively, if you'd prefer cuda 8, you can download the deb file and then use the command
dpkg-deb -x cuda_8.*.deb /usr/local/cuda-8.0
to extract the contents from the deb file and have them placed in the desired directory.
Source: http://docs.nvidia.com/cuda/cuda-installation-guide-linux/index.html#advanced-setup)
I'm trying to install libQt5Core from an rpm and I get:
Error: nothing provides libicui18n.so.52.1()(64bit) needed by libQt5Core5-5.5.1-4.1.x86_64
There is newer version:
dnf whatprovides libicui18n*
Last metadata expiration check performed 0:00:14 ago on Fri Jan 29 13:58:14 2016.
libicu-54.1-5.fc23.x86_64 : International Components for Unicode - libraries
Repo : #System
Where do you install the libQt5Core from? The official repositories should not require packages versions that are not available.
Don't use that RPM to install the QT 5 core libraries. I'm guessing that you have a package for openSUSE (because that's what comes up when I Google for "libQt5Core rpm"). In Fedora, the package you want is qt5-qtbase. Install that with:
sudo dnf install qt5-qtbase
It happens that our version in Fedora 23 is also version 5.5.1, so I think that'll be what you really need here.
If you're doing software development, you might want to pull in the KDE Frameworks 5 development group, which is mostly QT stuff and which will get you set up for building programs against that, which might be what you're trying to do:
sudo dnf groupinstall kf5-software-development
I downloaded and built GNUstep libobjc2 1.6.1,
svn co http://svn.gna.org/svn/gnustep/libs/libobjc2/1.6.1/ rep
cd rep
make
and got this error when I tried to compile a Objective-C code.
hoon#ubuntu:~/work/objc2$ clang -fobjc-nonfragile-abi -fobjc-arc -fblocks *.m *.a -l pthread; ./a.out
Objective-C ABI Error: Loading modules from incompatible ABIs while loading
a.out: loader.c:38: __objc_exec_class: Assertion `objc_check_abi_version(module)' failed.
Aborted (core dumped)
It seems I need to build libobjc.a with some different configurations. What is the problem and what should I do to fix this error?
Env: Ubuntu 12.04 LTS
This is a good question because LLVM and CLang and GNUstep don't claim to be hard or complicated to use. They do ask their users to read (and reread) their documentation though. I've just discovered this combination for Ubuntu myself and it is very intriguing. And there are a lot of moving parts at the moment.
If the OP got an answer on one of the gnustep mailing lists, then it would be nice to hear here how it was resolved.
Without suggesting the normal route of starting over and only installing the latest from LLVM and GNUstep directly, here's my take.
The OP is trying to use ARC and blocks with the runtime provided by the gunstep/libobjc2 project.
libobjc2 should probably be built with clang version 3.2 - or maybe the top of tree.
clang -v will tell you what version you have on your machine. I've found even Ubuntu 12.10 doesn't provide clang-3.2. So I download it from the LLVM website. They have prebuilt binaries for Ubuntu 12.04 LTS. To get make to use clang for this build step, I've seen instructions to set and export CC=clang and CXX=clang++.
Once libobjc2 is built, care must be taken where it gets installed. If the system already has an older libobjc.so.x.y library (this provides the runtime environment for Obj-C), clang or the linker may be picking up the wrong one when you start compiling your own source. I found libobjc.so.4.6.0 built from the libobjc2 source was installed to /usr/local/lib both on Ubuntu 12.04 and 12.10 when I ran the make install step. This path was not setup by the libobjc2 install step.
To get this library picked up, I had to add /usr/local/lib to the env variable LD_LIBRARY_PATH. It wouldn't hurt to try 'locate libojbc.so' to see if there are other versions on the system.
Finally, the libobjc2 readme, https://github.com/gnustep/gnustep-libobjc2#readme, says this new version of the gnustep library supports two ABIs, and each ABI supports ARC and blocks. The advice I've seen about compiling with libobjc2 is to also provide the runtime version expected to be compiling and linking with: -fobjc-runtime=gnustep. Clang on Ubuntu still defaults to the older ABI. -fobjc-nonfragile-abi may accomplish the same thing but I've seen it mentioned that flag was or will be deprecated.
The OP error may actually come from the step where a.out is being run, rather than where clang was compiled. Perhaps the dynamic loader is picking up the legacy libobj.so. Again, I would use locate to see if the system even has more than one.
This is just a guess, but I'm gonna go out on a limb and guess that GNUstep is going to build with GCC by default. A good first step might be to reconfigure the GNUstep build to use Clang. I can't say what variety of issues that will expose, but...
Alternately, you could try building your application with GCC instead of Clang.
This is a fairly late answer, but I have found a way to get everything working (on Elementary OS specifically so I imagine it should be fine on Ubuntu and similar distros).
As mentioned, it is better/easier to build everything from source because you get to pick the prefix, build options, etc. The general method:
Install cmake (if it's not already installed) --> sudo apt-get install cmake
Download, build and install llvm and clang as per the instructions here (or see attached build script). For speed, use the --enable-optimized flag. Tests are "optional" ;-)
The default build scripts for compiler-rt do not include the Blocks runtime. You could modify the build scripts, or rejoice that someone else has already done it (particularly if, like me, your cmake isn't great). Download, build and install libBlocksRuntime from this git repo (it is essentially a clone of the latest compiler-rt Blocks runtime code with custom build scripts). FOLLOW THEIR COMPILATION AND TESTING METHOD.
Download, build and install libobjc2 from GNUStep. The instructions for correct building are actually inside the now-deprecated makefile.
Run ldconfig (if required - though there's no harm in running it even if it isn't).
As #WeakPointer you may still need to edit the LD_LIBRARY_PATH environment variable to pick up your new libraries. Another option is to make some quick and dirty symlinks so clang can find your new libraries.
Final note: I haven't done any comparisons between GNUStep's libobjc2 and GCC's libobjc, the latter of which DOES contain some Objective-C 2.0 features... Be careful with your library selection if you keep both on your system at the same time!
The following script should do it all (untested!):
#!/bin/bash
# Temporary base directories
basedir="./clangllvm_temp"
basedir2="./libBlocksRuntime_temp"
basedir3="./libObjc2_temp"
# Clang, llvm, compiler-rt
mkdir $basedir
cd $basedir
svn co http://llvm.org/svn/llvm-project/llvm/trunk llvm
cd llvm/tools
svn co http://llvm.org/svn/llvm-project/cfe/trunk clang
cd ../..
cd llvm/tools/clang/tools
svn co http://llvm.org/svn/llvm-project/clang-tools-extra/trunk extra
cd ../../../..
cd llvm/projects
svn co http://llvm.org/svn/llvm-project/compiler-rt/trunk compiler-rt
cd ../..
mkdir build
cd build
../llvm/configure --prefix=$PREFIX --enable-optimized
make
sudo make install
cd ../..
# libBlocksRuntime
git clone https://github.com/mackyle/blocksruntime.git $basedir2
cd $basedir2
sudo ./buildlib
sudo ./checktests
sudo ./installlib
# Test!
clang -o sample -fblocks sample.c -lBlocksRuntime && ./sample
cd ..
# libobjc2
https://github.com/gnustep/gnustep-libobjc2.git $basedir3
cd $basedir3
mkdir Build
cd Build
cmake .. -DCMAKE_C_COMPILER=clang -DCMAKE_CXX_COMPILER=clang++
sudo make && sudo -E make install
cd ../..
# Cleanup
rm -rf $basedir
rm -rf $basedir2
rm -rf $basedir3
# ldconfig
sudo ldconfig
# Additional symlink/LD_LIBRARY_PATH stuff here if required.
# EOF
Key difference was using Clang for build. Take care not to use GCC which is system default compiler. I removed gobjc and g++ packages from system to avoid this issue.
export CC=clang
export CXX=clang++
svn co http://svn.gna.org/svn/gnustep/libs/libobjc2/1.6.1/
cd 1.6.1
make
This answer was hinted from this mailing list thread:
http://lists.gnu.org/archive/html/discuss-gnustep/2012-12/msg00036.html
Described script is posted here:
http://wiki.gnustep.org/index.php/GNUstep_under_Ubuntu_Linux
Now it compiles simple ARC code.
It seems GCC and Clang generated codes are incompatible.
Update
I wrote scripts to setup libobjc2 on FreeBSD and CentOS.
The scripts are mostly copied from a blog.