I am trying to build Erlang on Solaris 10. The build process fails with the message that it can not find libncurses.so.5.
I have installed libncurses from sunfreeware.com, which I have build from scratch and has installed itself in /usr/local/lib/.
I have tried to set LDFLAGS with -L/usr/local/lib/ but have still had no luck.
What am I missing so that make picks up the library?
I am using GNU Make 3.81 and GCC 3.4.6.
Could you post the relevant bit from config.log?
Did you also set the include path with -I in either CPPFLAGS or CFLAGS?
Update: You could also try installing Erlang from OpenCSW instead.
Related
I have spent a few hours trying to get the built-from-sources version of clang (v15) to work with the memtag sanitiser. For those of you who don't know what that is, it is simply a version of the address sanitiser that leverages the Memory Tagging features of ARM.
Anyway, while I can use it normally with the repository version of clang (v10), using the version built from sources just does not work.
Here is the command I use for both: clang main.c -S -march=armv8+memtag -fsanitize=memtag with clang which is either the repository-version or the built-from-sources version. Although the former works seamlessly, the latter does not.
I've tried to built llvm with different parameters, but none seemed to have done the trick. Here's my current building configuration:
cmake -G Ninja -DCMAKE_BUILD_TYPE=Release -DLLVM_ENABLE_PROJECTS="clang;clang-tools-extra;lld;lldb;openmp;polly;pstl;compiler-rt" -DLLVM_TARGETS_TO_BUILD="AArch64" ../llvm
I wonder if there is some parameter I have to specify to build clang with this sanitiser enabled.
PS: using the -fsanitize=memtag flag does not give any error: with the built version of clang it simply does not insert the instrumentation code.
If anybody is able to give me some insight I would really appreciate it. Thanks ;)
We want to use a Mac Mini with the M1 processor as an agent in our CI pipeline to make sure that developers with new Macs can compile the project. We duplicated the setup that we have for x86, but cmake cannot find libraries such as boost:
CMake Error at /opt/homebrew/Cellar/cmake/3.19.7/share/cmake/Modules/FindPackageHandleStandardArgs.cmake:218 (message):
Could NOT find Boost (missing: Boost_INCLUDE_DIR container system
date_time)
Weirdly, this is not an issue when connecting to the machine directly via ssh. Even manually setting the environment variables does not change anything.
The Jenkins agent uses Java. If you install Java via brew (e.g., adoptopenjdk8), you might get an x64 version (as of March 2021) that is run using the Rosetta translation layer. You can verify this by executing sysctl sysctl.proc_translated. In the "normal" SSH connection, this should return 0, when executed as sh "sysctl sysctl.proc_translated" in Jenkins, you will see a 1.
Preferred Option (install native JDK)
Instead of using, e.g., adoptopenjdk8, you can install the zulu JDK, which is available natively, via
brew install --cask zulu
After this, you should be able to verify that proc_translated is 0 within Jenkins. You can verify that a native binary is built as described below.
Hotfix (without changing the JDK)
The following is a hotfix if you cannot install a native JDK.
We were able to force cmake to run natively (and thus to find the native libraries) by modifying our Jenkinsfile as follows:
old:
sh "cmake .."
sh "make hyriseTest"
new:
sh "PATH=/opt/homebrew/bin:$PATH arch -arm64 cmake .."
sh "arch -arm64 make hyriseTest"
Having to repeat the arch command over and over is not really pretty. Maybe someone has a better solution.
Verification of the result
We can verify that our generated binary is a native ARM binary:
sh "file hyriseTest"
Result:
+ file ./hyriseTest
./hyriseTest: Mach-O 64-bit executable arm64
Compiler warnings
Note: We are still seeing linker warnings about "ltmp3" and "ltmp4". I have not found any information about that online and it does not seem to affect the correctness of the result. Example:
ld: warning: direct access in function 'ltmp4' from file 'CMakeFiles/hyriseMvccDeletePlugin.dir/Unity/unity_0_cxx.cxx.o' to global weak symbol
I need to upgrade glib for a specific project. It currently uses glib 2.28.8. I have three problems.
I've never used meson and ninja before, so I checked glib's INSTALL.in and it just said to run meson _build followed by ninja -C _build. So I ran meson _build and got the following output:
$ meson _build
The Meson build system
Version: 0.47.2
Source dir: /srv/devel/build/glib-2.65.0
Build dir: /srv/devel/build/glib-2.65.0/_build
Build type: native build
meson.build:227: WARNING: Identifier 'in' will become a reserved keyword in a future release. Please rename it.
meson.build:227:14: ERROR: Expecting eol got id.
if vs_crt_opt in ['mdd', 'mtd']
So the basic build doesn't work. Why?
For our purposes, we use the following configure command:
PKG_CONFIG_PATH=$(OUTPUT_DIR)/lib/pkgconfig ./configure --prefix=$(OUTPUT_DIR) --disable-dtrace --disable-selinux ac_cv_path_MSGFMT=/bin/true CPPFLAGS="-fPIC -I$(OUTPUT_DIR)/include" LDFLAGS="-L$(OUTPUT_DIR)/lib" --enable-static --disable-shared
How do I specify that in meson?
I will also need to build in Windows. Any gotchas there?
Thanks!
EDIT: I tried older versions of glib, going back to 2.62.0 and when I run meson _build I get the error meson.build:1:0: ERROR: Meson version is 0.47.2 but project requires >= 0.49.2.. So that's probably a big part of the problem for question (1). This is running on CentOS 6 & 7, so I'll probably have to get and install a current meson package.
So the basic build doesn't work. Why?
You correctly figured this out in your edit: GLib 2.64 requires Meson 0.49.2, and it seems that Meson 0.47.2 is so old as to not be able to correctly parse GLib’s meson.build.
It looks from your build output that you’re trying to build GLib 2.65.0. Note that 2.65 is an unstable release series. Even minor versions of GLib (2.62.x, 2.64.x, etc.) are stable; odd ones are unstable. Using an unstable release is fine, as long as you know what you’ve signed up for: it may contain bugs, and new APIs introduced in that unstable series may change or be removed before the first stable release (in the case of 2.65.x, the corresponding first stable release will be 2.66.0).
For our purposes, we use the following configure command:
You’ll want something like:
meson --prefix "$(OUTPUT_DIR)" -Dselinux=disabled -Ddefault_library=static _build
You can see from the b_staticpic option’s default value that -fPIC is the default for static libraries, so (I believe) doesn’t need to be explicitly specified.
There should be no need to disable dtrace support since it’s disabled by default. If you did need to disable it, you’d do that with -Ddtrace=false.
The custom -L and -I arguments should be covered by use of --prefix.
Overriding the msgfmt tool to disable internationalisation is not a supported way of building GLib and you’re on your own with that one.
There is some good documentation on the built-in options in Meson here and here.
I will also need to build in Windows. Any gotchas there?
That’s too broad a question to be answered on StackOverflow.
I am trying to install a cross-compiler following instructions that I found here. I am using the 64 bit version of Ubuntu 13.10. As soon as I entered the command to configure the binutils I get:
Configuring for a x86_64-unknown-linux-gnu host.
Invalid configuration `x86_64-unknown-linux-gnu': machine `x86_64-unknown' not recognized
Invalid configuration `x86_64-unknown-linux-gnu': machine `x86_64-unknown' not recognized
Unrecognized host system name x86_64-unknown-linux-gnu.
Is there really a 64-bit version of the binutils? If not, can anyone tell me what commands to enter to avoid this error?
After a little googleing I found a post. In this post the author explains that all you have to do in order to install the binutils on a 64-bit linux system is fool the system by typing "linux32" before your command. For example in this case it would be:
linux32 ./configure
linux32 make
linux32 make install
to build for a regular compiler and this:
linux32 ./configure --target=$TARGET --prefix="$PREFIX" --disable-nls
linux32 make
linux32 make install
to build for a cross-compiler.
I got the same error with binutils-2.9.I just used binutils-2.28(a lower version) and it worked for me.
On RedHat Enterprise Linux 5 the latest Ruby version available via RPM is 1.8.5. My Rails app requires 1.8.6 or above so I need to compile Ruby from source.
I have tried the following to build it and it seems to build ok, but then I'm seeing gcc compilation errors when trying to run a plug-in which requires RubyInline.
There seems to be a lack of decent documentation for building Ruby from source, suitable for running Rails apps.
Here's how I compiled Ruby:
./configure --prefix=/usr --with-openssl-include=/usr/include/openssl --with-openssl-lib=/usr/lib64/openssl/engines
make
sudo make install
I wonder whether there are specific compile flags I need to build this on a 64-bit system. The actual error I'm seeing is
error executing "gcc -shared -fPIC -g -O2 -I /usr/lib/ruby/1.8/x86_64-linux -I /usr/include -L/usr/lib -o \"/home/deploy/.ruby_inline/Inline_ImageScience_aa58.so\" \"/home/deploy/.ruby_inline/Inline_ImageScience_aa58.c\" -lfreeimage -lstdc++ ":
Any advice would be greatly appreciated
The best way would probably be to just "steal" a Ruby 1.8.6 RPM from Fedora. The second best way would be to steal a Ruby 1.8.6 SRPM from Fedora and build it yourself.
However, there is one thing you could do: add a --disable-pthread flag to the configure line and remove --enable-pthread if it's there. --enable-pthread makes MRI significantly slower, and is only needed if you want to use Ruby/Tk and your system's Tk library was built with --enable-pthread.
Ruby packages for Fedora (including SRPM)
Couldn't post as a comment on the correct answer so added here - editors feel free to tidy-up.