I'm trying to get ld to see a path where I have a .so installed. There's another similar post here which I've been following.
In my case, I need the paths controlled by environment variable, just like the other person posting.
There's also another answer in a different post which recommends using pkg-config to auto-find the paths needed. But again, that won't work for me because it'd require changing source code, and the solution needs to be configuration-based (environment variable, ideally).
What I Tried
Setting LIBRARY_PATH and/or LD_LIBRARY_PATH to the directory doesn't work.
Using -L does work but I can't use it, because the solution must be configuration-based (no execution flags)
ld -lxcb-keysyms --verbose -L`echo $LD_LIBRARY_PATH` # This finds the path I need
LIBRARY_PATH=$LD_LIBRARY_PATH ld -lxcb-keysyms --verbose # This doesn't find it.
I've also tried modifying my path to include or not include the "lib64" folder in the environment variable like one of the answers pointed out. This doesn't work. Anyone know what I need to do to get this working?
System specs
$lsb_release --all
LSB Version: :core-4.1-amd64:core-4.1-noarch
Distributor ID: CentOS
Description: CentOS Linux release 7.6.1810 (Core)
Release: 7.6.1810
Codename: Core
Related
If I compile custom executables (binaries), or use executables from buildroot, busybox shell keeps saying applet not found For instance, I can select coremark from the included packages list, but then if I try running coremark, I get:
~ # coremark
coremark: applet not found
Is there some setting within busybox or buildroot that tells busybox to be willing to load non-busybox executable files? I'm currently running with RISC-V 32-bit rv32 Linux 5.18 and tip of master buildroot.
I found the issue! On my particular system, only flat binaries are usable. So, you either need to add -Wl,-elf2flt=-r to the link invocation or use elf2flt in order to make executable files.
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'm having trouble cross compiling PostgreSQL for my TI Sitara AM335x EVM SK. My host system is an i386 machine running Ubuntu 12.04.
My application is written in C++ using Qt. When I try and compile, I get the error that libpq.so is incompatible. I believe this is because the cross compiler is trying to use the host libpq.so instead of one for the target system (which as I have found out, doesn't exist).
I've downloaded the source for PostgreSQL with the intention of cross compiling that in order to give me the libpq.so library that will be compatible with my target system, however there is virtually no information on how to do this.
I have tried using the CC argument with the configure file to change my compiler to the following: CC=/home/tim/ti-sdk-am335x-evm-06.00.00.00/linux-devkit/sysroots/i686-arago-linux/usr/bin/arm-linux-gnueabihf-gcc but the configure script gives me this error: configure: error: cannot run C compiled programs. If you meant to cross compile, use --host.
The configure file makes a small reference to the --host option, but the only information in the file that I could find is in reference to mingw and windows, which isn't what I want.
I've done some quick searching through the configure file, and it references the --host option, but with no explanation of what is a valid host. I'm assuming that with --host option there will be an associated --target.
What arguments can I give the configure script so that it will cross compile with the correct compiler to generate a library that my target device can use? Are there any resources out there that I haven't found in regards to how the --host/--target works or how to use them?
OK, so after fiddling around for a little while, I think I was actually able to cross compile PostgreSQL and answer my own question.
Before I went any further, I had realized I had forgotten to add the path to my cross compiler to the PATH environment variable. I used the command export PATH=/path/to/cross/compiler:$PATH to insert the compiler path to the PATH environment variable.
Next, I did some experimenting with the --host option. To start off with I tried using ./configure --host=arm-linux-gnueabihf and running the configure script. The configure script seemed to accept this as the host argument. I then went to the next step of running the makefile. Running this makefile resulted in errors being generated. The errors were selected processor does not support Thumb mode. I did a quick search to see what information I could find about this error and came to this webpage: http://www.postgresql.org/message-id/E1Ra1sk-0000Pq-EL#wrigleys.postgresql.org.
This webpage gave me a bit more information since it seemed like the person was trying to do something very similar to me. One of the responders to the post mentioned that --disable-spinlocks is intended for processors that aren't supported by default by PostgreSQL. I emulated the arguments that were used in the website listed above and used the command: ./configure --host=arm-linux CC=arm-linux-gnueabihf-gcc AR=arm-linux-gnueabihf-ar CPP=arm-linux-gnueabihf-cpp --without-readline --without-zlib --disable-spinlocks to generate my makefile. This makefile actually generated all of the files, including the libpq.so library file I was needing.
Hope this helps somebody else in the future!
I have installed dmd and ddt as instructed:
DMD64 D Compiler v2.066.0
Copyright (c) 1999-2014 by Digital Mars written by Walter Bright
Documentation: http://dlang.org/
but when I create a dub project in eclipse, I dot an error that says standard libray not found:
(source: p.im9.eu)
any ideas?
OS: Mac OSX 10.9
Eclipse: 4.4
DDT: 0.10.2
I've also posted a temporary workaround in the discussion group (link):
# cd /usr/share/dmd
# mkdir dummy
# mkdir dummy/bin
# touch dummy/bin/dmd
# launchctl setenv DUB_COMPILERS_PATH /usr/share/dmd/dummy/bin
# killall Dock
Note that the DUB_COMPILERS_PATH variable shouldn't point to the binary itself, it acts like an additional PATH variable, i.e should contain bin dirs.
To make this survive a reboot, add the launchctl line to /etc/launchd.conf:
launchctl setenv DUB_COMPILERS_PATH /usr/share/dmd/dummy/bin
You might need to create it if it doesn't already exist.
This seems to be a reported bug of DDT:
https://github.com/bruno-medeiros/DDT/issues/75
Basically, it boils down to the directory structure of the installed dmd. As they are many distributions and many installers, each one with its own convention, DDT missed some.
They should be added and recognized shortly, in the pending release.
Please follow the reported issue on github/DDT page.
Yes, I know this thread is really old, and yes DDT seems to be no longer in development.
However, for those of us who are new to D, Eclipse and DDT, and relatively new to using Linux (I'm using Mint 19.3), I have the following solution which worked for me. No doubt this is common knowledge somewhere, but I had to scratch around quite a lot to discover this. (Of course, your dmd version number may be different.)
Note that dub is automatically installed along with dmd in:
$HOME/dlang/dmd-2.090.1/linux/bin64/dub
The command
source ~/dlang/dmd-2.090.1/activate
will modify the $PATH variable to allow access to the compiler.
NOTE that this only changes the path for the shell where the command is issued... and only for the current session!
If you want the path change to be permanent (who doesn't?), add the following to ~/.profile using a text editor, e.g. nano ~/.profile or xed ~/.profile , etc.:
# Add dlang dmd compiler path
if [ -d "$HOME/dlang/dmd-2.090.1/linux/bin64" ] ; then
PATH="$HOME/dlang/dmd-2.090.1/linux/bin64:$PATH"
fi
This corrects the Eclipse error:
"D Standard Library [Error: none found]"
in the Project tree, and also allows dub to be run from any directory, e.g. from a terminal.
HTH.
I am creating rpm for apc. While writing spec file, I realized that some commands may have path which can keep on changing which are required during the compilation time. For eg. these commands are required to be executed during the building time.
$ /usr/local/php/bin/phpize
$ ./configure --with-php-config=/usr/local/php/bin/php-config
But the complete path of phpize and php-config file may change. So how can i prevent this dependencies so that i should not hard-code these path in my spec file.
Because these commands are used at building time, the ideal solution to this problem is here:
Find packages on distribution which provide these commands or paths e.g php-config is provided by php-devel package on Fedora operating system. In fedora you can find it using yum whatprovides "*/php-config" or if they are already installed on system then using rpm -qf /path/to/command.
Once you know the packages add them as BuildRequire tag in spec file. Step 2 will make sure that paths are always present whenever you build the package from spec file even if you use hard coded paths (which isn't ofcourse best way to do it).
In place of /usr/ you can use %{_prefix}, it depends entirely on macros available on distribution you are building this rpm on. Check macro files for path macros. One link which has common macro definitions is here.