I've always been able to compile sources from git repository https://github.com/GNOME/vala.git on my PC running "Linux Mint 18.3 Cinnamon 64-bit". I have the latest valac (0.42.4-0ubuntu1~16.04~valateam0) installed.
The last successful compile I did was from version 0.40.0.257-40b5-dirty. Today, I downloaded the latest vala.git, but when i run ./configure I get:
./configure: line 12579: syntax error near unexpected token `$flag,TEST_CFLAGS="$TEST_CFLAGS $flag"'
./configure: line 12579: ` AX_CHECK_COMPILE_FLAG($flag,TEST_CFLAGS="$TEST_CFLAGS $flag")'
Do I need to make additional environment changes? Not sure were to go from here.
Compiling Vala from source is a good start in contributing back to the Vala project. Vala currently uses autotools as its build system. For Ubuntu AX_CHECK_COMPILE_FLAG is provided by a separate package: autoconf-archive. See the autotools syntax error with ax_check_compile_flag answer on Stack Overflow for more details. So you should just need to install autoconf-archive.
By the way the main repository for Vala is in GNOME's GitLab instance: https://gitlab.gnome.org/GNOME/vala You may want to clone that one instead. The GitLab instance also allows issues to be raised and merge requests to be submitted.
Related
I have a docker image with texlive installed (via apt not tlmgr). I have a pgfplot in my project which needs a newer pgfplot version. I'm searching for ways to update my pgplots because I can't update it with tlmgr because of base install via apt.
Initial error message if I try to compile with texlive 2014:
! Package pgfkeys Error: Choice '1.16' unknown in choice key '/pgfplots/compat/
anchors'. I am going to ignore this key.
See the pgfkeys package documentation for explanation.
Type H <return> for immediate help.
...
l.7 \pgfplotsset{compat=1.16}
?
! Emergency stop.
...
l.7 \pgfplotsset{compat=1.16}
I downloaded the pgfplots.tds and did the following steps like the manual said:
docker cp pgfplots.tds docker_container_name:/root/texmf/pgfplots
export TEXINPUTS=/root/texmf/pgfplots/tex//:
export TEXDOCS=/root/texmf/pgfplots/doc//:
export LUAINPUTS=/root/texmf/pgfplots//:
texhash
Of course the export and texhash were done inside the container and not on the host system.
After this, the error message is gone, but I have a new issue:
package pgfplots notification 'compat/show suggested version=true': you might b
enefit from \pgfplotsset{compat=1.18} (current compat level: 1.16).
! Illegal parameter number in definition of \pgfmaththisrow#.
<to be read again>
I searched online and got the response that this is because of a broken pgfplots installation. In many articles the fix was just to install the texlive new. But I can't do that.
The issue should also not be in the tex code itself. If I install texlive on my host system, which is the most recent Ubuntu distro, the tex compiles just fine.
Can somebody help me in fixing this or lead me to a better way of upgrading pgfplots?
Resolution:
The pgfplots package 1.18.1 and also 1.16 were to recent. It had conflicts with the pgf package. I tried to go further back and landed on \pgfplotsset{1.14} and version 1.14 of pgfplots.tds.
This works fine now. I was probably pretty lucky that my plot looks and functions the same with this version as in 1.18.
This approach probably won't work for you if your more bound to version 1.18.
Introduction:
I have to create a pip wheel of Tensorflow 2.2.0 with cuda libraries dynamically linked(specifically cudart.so). To accomplish this i am currently using the tensorflow-dev docker image.
I am able to build the tf wheel file, an able to install and use it while inside the build container.
Issue:
The issue is that importing the generated wheel file in a CentOS server, i get the following error:
ImportError: /lib64/libm.so.6: version `GLIBC_2.27' not found (required by /home1/private/mavridis/Vineyard/tensorflowshared/test/lib64/python3.6/site-packages/tensorflow/python/_pywrap_tensorflow_internal.so)
Having looked around, the issue is caused by the build container using a newer libc:
ldd --version
ldd (Ubuntu GLIBC 2.27-3ubuntu1) 2.27
Compared to CentOS older version:
ldd --version
ldd (GNU libc) 2.17
Expected behavior:
Having already tried the 'vanilla' tenorflow 2.2.0 version with no issues, installed using pip:
pip install tensorflow==2.2.0
I expected my own build to also work.
So i assume there is some configuration option or docker configuration to allow me to use the docker built wheel file, in a CentOS setup, just like the pip installed version. As this wheel file is intended to be deployed to setups beyond my control, solutions involving alternate OSes and/or libc replacement are not applicable.
Build configuration:
During build i use the following configuration/ command line:
export TF_NEED_CUDA=1
export TF_USE_XLA=0
export TF_SET_ANDROID_WORKSPACE=0
export TF_NEED_OPENCL_SYCL=0
export TF_NEED_ROCM=0
bazel build --config=opt --config=cuda --output_filter=DONT_MATCH_ANYTHING --linkopt=-L/usr/local/cuda/lib64 --linkopt=-lcudart --linkopt=-static-libstdc++ //tensorflow/tools/pip_package:build_pip_package
Regarding options used:
--output_filter=DONT_MATCH_ANYTHING : Silence warnings
--linkopt=-L/usr/local/cuda/lib64 --linkopt=-lcudart : Dynamic linking of cudart.so
--linkopt=-static-libstdc++ : Static link libstc++ as libstc++ also caused the libc error, this however is not possible for libm
I expected my own build to also work.
That expectation is (obviously) incorrect. The symbols your program or library requires from GLIBC depend on exactly which functions you call.
Consider the following program:
int main() { exit(0); }
When compiled/linked on a GLIBC-2.30 system, this program only depends on GLIBC_2.2.5 (because it doesn't call any newer symbols).
Now change the program slightly:
int main() { gettid(); exit(0); }
Compile/link it again, and all of a sudden this program now requires GLIBC_2.30 (because that's where gettid() was added to GLIBC), and will not work on any system which has older GLIBC.
So i assume there is some configuration option or docker configuration
Sure: your Docker image must have GLIBC that is not newer than what your target system have, i.e. GLIBC-2.17. Your current image contains GLIBC-2.27 (or newer).
You need a different Docker image, and you'll likely have to build it yourself, since GLIBC-2.17 is over 7 years old, and predates TensorFlow by many years.
Update:
What i don't understand is how come the pip tensorflow package (which i assumed was build with the docker image i am using) works with CentOS?
It works by accident, just like my first program would work on CentOS, but the second one wouldn't.
In short i wanted to generate a pip package that would work on 'any' linux/libc version
That is an impossible goal: Linux predates GLIBC, and it is impossible to build a single package that will work on a Linux distribution which didn't include GLIBC and on a distribution that did.
You have to draw a line somewhere. The developers of tensorflow-dev docker image drew a line at GLIBC-2.27. Packages built on this image should work on any system with 2.27 or later, and might (but are not at all guaranteed to) work on older systems.
just like the pip installed version.
You claim that the pip installed version has no "only GLIBC-xx or later" requirement, but that is not true. I am 99.9% sure that it requires at least GLIBC-2.14.
To find which GLIBC versions that package requires, run this command:
readelf -WV _pywrap_tensorflow_internal.so | grep GLIBC_
I assumed, the pip installed version was built using the publicly available tensorflow-devel docker image.
That is quite likely. And like I said, it happens to work on CentOS, but minute changes may make it not work anymore.
Update 2:
So running the readelf command as you suggested, does show the most recent required versions to be: - pip version: GLIBC_2.12 - mine : GLIBC_2.27 So from what i understand the pip version uses an older version even from CentOS, which explains why it works.
It doesn't "use" older version, it uses whatever version is available.
It requires a minimum version 2.12, while your build requires a minimum version 2.27.
How do they achieve this? Do they use a different image that has an older libc? If so, where can i get it? Or do they use the public image, but build with some bazel flag, that 'limits' symbols to the ones contained up to libc 2.12?
You are still not getting it.
The version that your program requires depends on exactly which functions you call. In my example program, if I only call exit, my program requires vesion 2.2.5, but if I also call gettid, then my program requires version 2.30. Note: these two programs are built on the same system with the same flags.
So no: they (most likely) didn't use a different Docker image, and didn't use "magic" bazel flags. They just happened to not call any functions which require GLIBC version > 2.12, and you did.
P.S. You can find which symbol(s) are causing "bad" dependency in your build like so:
readelf -Ws _pywrap_tensorflow_internal.so | egrep 'GLIBC_2.2[0-9]'
readelf -Ws _pywrap_tensorflow_internal.so | egrep 'GLIBC_2.1[89]'
This would produce output similar to (using my second program):
readelf -Ws a.out | egrep 'GLIBC_2.[23][0-9]'
2: 0000000000000000 0 FUNC GLOBAL DEFAULT UND gettid#GLIBC_2.30 (2)
48: 0000000000000000 0 FUNC GLOBAL DEFAULT UND gettid##GLIBC_2.30
The output above shows that the only symbol my binary requires from GLIBC 2.20 or above is gettid.
To make a counter point to what Employed Russian wrote:
The version that your program requires depends on exactly which functions you call. In my example program, if I only call exit, my program requires vesion 2.2.5, but if I also call gettid, then my program requires version 2.30. Note: these two programs are built on the same system with the same flags.
I don't think that's quite accurate. My understanding, which is corroborated by https://github.com/wheybags/glibc_version_header, is that things work like so (quoting that project, emphasis mine):
Glibc uses something called symbol versioning. This means that when you use e.g., malloc in your program, the symbol the linker will actually link against is malloc#GLIBC_YOUR_INSTALLED_VERSION (actually, it will link to malloc from the most recent version of glibc that changed the implementaton of malloc, but you get the idea).
So my guess (I have not checked) would be that the Tensorflow releases are built against an older glibc (perhaps by way of being built on an older release of their target Linux distro).
I am trying to migrate a huge project having visual studio and maven projects to bazel. I need to access our in house maven server which is encrypted. To get access I need the load the maven_jar skylark extension since the default impl does not support encryption (get error 401). using the extension leads to a lot of troubles, like:
ERROR: BUILD:4:1: no such package '#org_bouncycastle_bcpkix_jdk15on//jar': Traceback (most recent call last):
File ".../external/bazel_tools/tools/build_defs/repo/maven_rules.bzl", line 280
_maven_artifact_impl(ctx, "jar", _maven_jar_build_file_te...)
File ".../external/bazel_tools/tools/build_defs/repo/maven_rules.bzl", line 248, in _maven_artifact_impl
fail(("%s: Failed to create dirs in e...))
org_bouncycastle_bcpkix_jdk15on: Failed to create dirs in execution root.
The main issue seems to be the shell that needs to be provided to bazel in BAZEL_SH environment variables:
I am working under windows
I am using bazel 0.23.2
bazel seems to run a bash command using "bash" directly and not the one provided by env variable.
I got a ubuntu shell installed in windows. bazel was using everything from ubuntu, especially when using maven (settings.xml was using from ubuntu ~/.m2 and not from windows user)
after uninstalling ubuntu and making sure that bash in a cmd ends up in "command not found" I also removed the BAZEL_SH env var and bazel throws the message above
after setting the BAZEL_SH variable again it fails with the same error message
I am assuming that bazel gets a bash from somewhere or is ignoring the env variable. My questions are:
1. How to setup a correct shell?
2. Is BAZEL_SH needed when using current version?
For me the doc at bazel website about setup is outdated.
Cheers
Please consider using rules_jvm_external to manage your Maven dependencies. It supports both Windows and private repositories using HTTP Basic Authentication.
For me the doc at bazel website about setup is outdated.
The Bazel team is aware of this and will be updating our docs shortly.
Is it possible to use Erlang with ZMQ on Windows? I have tried to use erlzmq2, but rebar fails to compile it with cryptic linker errors. Of course i can invest some time and investigate makefiles, but maybe other way exists?
Update
Whose who are interested in compilation errors can download latest erlang for windows and try to build erlzmq2 (Visual Studio 2012 compiler, msys sh and make). Error looks like:
cl : Command line error D8021 : invalid numeric argument '/Wl,-DLL,-IMPLIB:.libs
\zmq.dll.lib'
Makefile:541: recipe for target 'libzmq.la' failed
make[3]: *** [libzmq.la] Error 2
Please note that other erlang libs are compiling with this setup without any problems.
Your problem lies in compiling ZeroMQ for Windows. You haven't actually gotten to any Erlang yet. Here are some of the clues that tell you this:
Makefile:541: recipe for target 'libzmq.la' failed
This line says there's a problem on line 541 of the Makefile. But in erlzmq2, you can see that neither the main Makefile nor the c_src Makefile (which is what would build libzmq.la) has anything close to that many lines.
make3: * [libzmq.la] Error 2
The [3] means that you're 3 invocations deep into Make. Specifically, you started at the top-level Makefile, which called Rebar, which ran make -C c_src, which downloads ZeroMQ version 3.2.2 and tries to do a ./configure && make
To fix this Unix-style, go into the deps directory of erlzmq2 and figure out how to correctly compile ZeroMQ. Hopefully, you will just need to pass some arguments to configure. Then you can edit c_src/Makefile and set ZMQ_FLAGS to whatever you had to do for configure, clean, and make.
To fix it more Windows-style, follow the Windows build instructions for ZeroMQ. Put the compiled libzmq under deps and just edit the c_src Makefile to a no-op.
Finally, if you don't actually need to run this code on Windows, but are just using Windows as your development environment, I think you'll have the easiest time by running the build inside a Linux VM (not a hard thing at all with tools like Vagrant). Sorry, but Unix is the real system for this stuff; Windows support is an afterthought.
Update:
Tried November CTP release. Same error message.
Forgot to mention that this server has the Ubuntu server edition installed. I don't have this issue on my Ubuntu desktop that runs Desktop 10.10.
So I suspected that it could be some command line related libraries missing. After I installed libreadline-dev and libreadline5, the error message disappeared. However, the issue that fsi stuck is still there.
Update2:
Tried the new Mono 2.8.1. Same FSI stuck issue.
Update3:
As this issue is very reproducible, I reported it as a bug in fsi.exe to Microsoft. Let's see how it goes.
Update4:
Got quick response from Don Syme. The solution he suggested resolved this issue. I created the answer myself.
Hi,
I installed F# 2.0 in a server running Ubuntu 10.10 and Mono 2.8. fsc.exe runs perfect, I have no problem in compiling fs files. However, when I run fsi.exe as follows:
mono /usr/local/FSharp/bin/fsi.exe
I got the FSI prompt, but an error message keep repeating
"Failed to install ctrl-c handler - Ctrl-C handling will not be available. Error was:
Exception has been thrown by the target of an invocation"
Am I missing anything here?
The Mono 2.8 was compiled and installed from source.
Feel really awkward to answer my own question. Anyway, I'll answer it so other people can benefit from.
First of all, install libreadline-dev and libreadline5 so you can get rid of the following error message
Failed to install ctrl-c handler - Ctrl-C handling will not be available. Error was: Exception has been thrown by the target of an invocation
If you encounter fsi.exe stuck issue, try
fsi --gui-
It works perfectly in my case.
Here is my understanding of why such an issue happened. If you look into the code, you will find out fsi.exe actually references System.Windows.Forms, which further links to the Window system. In my case, I ran fsi in a server without X system installed. Consequently, fsi stuck there trying to talk to the nonexistent X. That explains why I don't have the issue in my desktop.
F# has never worked for me under Linux. Today with Mono 2.8 and the November 2010 drop of F# (which confusingly has the exact same version number as the previous release?!) I get:
$ sudo ./install-mono.sh
In order to add FSharp.Core.dll to the Mono GAC the DLL needs to be
re-signed with the mono.snk key. The mono.snk key is available from
the 'Mono Sources'.
http://www.mono-project.com/
http://github.com/mono/mono/raw/master/mcs/class/mono.snk
For example, run:
wget -O mono.snk http://github.com/mono/mono/raw/master/mcs/class/mono.snk
Then re-run this script.
An alternative to installing the DLLs in the Mono GAC is to add the
FSharp bin directory to the MONO_PATH variable. For more information
on 'How Mono Finds Assemblies' see http://www.mono-project.com/Gacutil
If I run the wget command that it suggests then it dies:
$ wget -O mono.snk http://github.com/mono/mono/raw/master/mcs/class/mono.snk
--2010-11-23 17:02:43-- http://github.com/mono/mono/raw/master/mcs/class/mono.snk
Resolving github.com... 207.97.227.239
Connecting to github.com|207.97.227.239|:80... connected.
HTTP request sent, awaiting response... 301 Moved Permanently
Location: https://github.com/mono/mono/raw/master/mcs/class/mono.snk [following]
--2010-11-23 17:02:44-- https://github.com/mono/mono/raw/master/mcs/class/mono.snk
Connecting to github.com|207.97.227.239|:443... connected.
ERROR: certificate common name `*.github.com' doesn't match requested host name `github.com'.
To connect to github.com insecurely, use `--no-check-certificate'.
Unable to establish SSL connection.
Now if I rerun the F# installer I get a different error:
$ sudo ./install-mono.sh
-- Resigning FSharp.Core.dll with mono.snk
ERROR: Invalid number of parameters.
Usage: sn [-q | -quiet] options [parameters]
-q | -quiet Quiet mode (minimal display)
Help options
-? | -h Show this help screen about the tool
-? | -h config Configuration options
-? | -h csp Crypto Service Provider (CSP) related options
-? | -h convert Format convertion options
-? | -h sn StrongName signing options
-- Installing FSharp DLLS into the GAC
Failure adding assembly bin/FSharp.Core.dll to the cache: Strong name cannot be verified for delay-signed assembly
If I copy the mono.snk file from the Mono 2.8 directory into the F# directory by hand then the installer seems to work:
$ sudo ./install-mono.sh
-- Resigning FSharp.Core.dll with mono.snk
Assembly bin/FSharp.Core.dll signed.
-- Installing FSharp DLLS into the GAC
Installed bin/FSharp.Core.dll into the gac (/usr/local/lib/mono/gac)
But F# itself still fails to work in exactly the same way that it did before (appearing to hang whenever input is entered):
$ mono bin/fsi.exe
Microsoft (R) F# 2.0 Interactive build 2.0.0.0
Copyright (c) Microsoft Corporation. All Rights Reserved.
For help type #help;;
> 1+2*3;;
I have to use CTRL+Z to regain control and then kill %1 to kill the rogue process.