How to get libc on Openwrt? - linux

I'm trying to get libc on OpenWrt as a package, but I can't seem to find it in any of the repositories. I am only able to find the .ipk here.
How do I get it on my configuration as I'm compiling it instead of using opkg?

I am not sure that I correctly understand your question.
If you are compiling the Openwrt, the .ipk should be under <buildroot/bin>. If you would like to just download it, please select the right architecture, for example using ar71xx use the link below: ar71xx - 15.05.1
On the other hand I cant imagine a system without libc installed, please type the following:
opkg list-installed | grep libc

Download the OpenWrt SDK.
Update and install the packages.
cd ~/OpenWrt-SDK-15...
./scripts/feeds update -a
./scripts/feeds install -a
Compile the libc package
make package/libc/compile -j1 V=s
Find it in bin/packages/...
If it fails find the libc package for OpenWrt and copy to /feeds/packages/libs. Update the package by typing ./scripts/feeds/update -i && ./scripts/feeds/install libc and go to the step 4 again.

Related

How to link mach-o format object files on linux?

I have been attempting to link a MACHO formatted object file on Linux, but I have failed miserably. So far, I have created the object file by running:
nasm -fmacho -o machoh.o hello.o
I have tried linking using:
clang --target=x86_64-apple-darwin machoh.o
but that failed. I have attempted using GCC, LD, and other linkers but I have still failed miserably. Are there any ideas on how I could solve my problem?
Thank you very much.
The most accessible solution would be lld, the LLVM linker.
lld does not ship with clang, but is a separate package.
sudo apt install lld
If you installed a version of clang that isn't the default (e.g. clang-12 explicitly), then you should use the same version for lld (i.e. lld-12).
Get a MacOS SDK from somewhere. This GitHub repo archives them.
If you're uncomfortable using the above, the "legitimate" way of obtaining it without a Mac would be:
Create an Apple ID
Go to https://developer.apple.com/download/all/
Download the "Command Line Tools for Xcode <version>"
Mount or extract the dmg
Extract the XAR package
For each ".pkg" folder inside, run pbzx <Payload | cpio -i
Find the Library/Developer/CommandLineTools/SDKs/MacOSX.sdk inside.
Feed both of the above to clang:
clang --target=x86_64-apple-darwin -fuse-ld=lld --sysroot=path/to/MacOSX.sdk machoh.o
I have tried linking using: clang --target=x86_64-apple-darwin machoh.o
but that failed.
Failed how? Details matter.
Anyway, there are 3 commonly used linkers on Linux: BFD-ld, Gold, and (newest) LLD.
Of these, Gold is an ELF-only linker, and will not work for Mach-O.
BFD-ld is only configured to support a few emulations (use ld --help to see which ones) in my distribution. BFD does appear to support Mach-O, so it's probably possible to build a Linux BFD-ld cross-linker with such support.
LLD should support Mach-O out of the box, but you are probably not using LLD.
So your first step should be to figure out which linker clang --target=x86_64-apple-darwin ... uses, and then make it use the one which does support Mach-O.

How to build libcurl-gnutls.so from source code

Where can I find the source code and instructions for building libcurl-gnutls.so?
I'm working on a project that needs libcurl-gnutls.so. I am required to build it from source code - I am not allowed to simply install it with "apt-get install libcurl". Unfortunately, my google-fu is failing me and I can't find a source code repository or instructions to build libcurl-gnutls.so anywhere.
Here's what I have found:
Linux-from-scratch has well-documented instructions for building libcurl.so, here: https://www.linuxfromscratch.org/blfs/view/svn/basicnet/curl.html. That lets me build libcurl.so with gnutls, but not libcurl-gnutls.so.
The curl website (curl.se), has detailed instructions on its various options here: https://curl.se/docs/install.html. Those show me how to build libcurl with gnutls, but the end product is still libcurl.so, not libcurl-gnutls.so.
When I run ldd -r on my project, it identifies the functions it needs (curl_easy_init, curl_easy_setopt, curl_easy_perform, and curl_easy_cleanup). I can find those symbols in both libcurl.so and a pre-built libcurl-gnutls.so. This leads me to suspect that libcurl-gnutls.so is libcurl.so, published under a different name. However, renaming libcurl.so to libcurl-gnutls.so is not sufficient to meet the dependency requirements. I could try altering the libcurl project to set its name and version to libcurl-gnutls (not that I know how to do it - I would poke around until I figure it out), but I don't know how appropriate that would be.
I found one other question on Stack Overflow about libcurl-gnutls (How to create lib curl-gnutls.so.4), but the answers to that are to install a pre-built version via apt-get install, which I am not allowed to do.
libcurl-gnutls.so actually just comes from a cURL built with gnutls support. You can find the repository here: https://github.com/curl/curl
Check out the docs/INSTALL.md. It has all the information you need to build cURL, specifically the part about Building from git.
Here is a snippet you might need:
./configure --with-openssl [--with-gnutls --with-wolfssl]
make
make test (optional)
make install
Here's a complete answer cobbled together from everyone's input (Thanks especially to Knud Larsen and Wassim Dhif):
libcurl-gnutls.so is just libcurl.so built with gnutls support. Archives for the project are here: https://curl.se/download
Change the SONAME that libcurl.so is built with by editing ltmain.sh to change:
if test -n "$soname_spec";
then eval soname=\"$soname_spec\"
To:
if test -n "$soname_spec"; then
soname=libcurl-gnutls.so.4
I'm sure there's a more elegant way to do it, but this works and I need to move on.
Alternatively, you can modify the the SONAME after libcurl.so is built with:
patchelf –set-soname libcurl-gnutls.so.4 libcurl.so
Check your client (the program or shared library that requires libcurl-gnutls.so as a dependency), to see if it requires version information.
For instance, when I run objdump -p myprogram, I get this:
Version References:
required from libcurl-gnutls.so.4:
0x0b103d23 0x00 14 CURL_GNUTLS_3
To build libcurl-gnutls.so with this version information:
2a. Set the version information to version 3:
In lib/libcurl.vers.in change:
CURL_#CURL_LT_SHLIB_VERSIONED_FLAVOUR#4
To:
CURL_#CURL_LT_SHLIB_VERSIONED_FLAVOUR#3
2b. Use --enable-versioned-symbols when configuring the libcurl project. This adds the required version information.
./configure --with-gnutls --enable-versioned-symbols [other arguments as needed]
The final product may be named libcurl.so, but can be renamed. It will have its SONAME set to libcurl-gnutls.so.4 and will have the required version information.

arm-none-eabi-objdump: error while loading shared libraries: libdebuginfod.so.1: cannot open shared object file

If you have an answer for this, or further information, I'd welcome it. I'm following advice from here, to offer some unsolicited help by posting this question then an answer I've already found for it.
I have a bare-metal ARM board for which I'm building a cross-toolchain, from sources for GNU binutils, gcc and gdb, and for SourceWare's Newlib. I got those four working and cross-built a DoNothing.c into an ELF file - but I couldn't disassemble it with this:
$ arm-none-eabi-objdump -S DoNothing.elf
The error was:
$ arm-none-eabi-objdump: error while loading shared libraries: libdebuginfod.so.1: cannot open shared object file: No such file or directory
I'll follow up with a solution.
The error was correct - my system didn't have libdebuginfod.so.1 installed - but I have another cross-binutils, installed from binary for a different target, and its objdump -S works fine on the same host. Why would one build of objdump complain about missing that shared library, when clearly not all builds of objdump need it?
First I tried rebuilding cross binutils, specifying --without-debuginfod as a configure option. No change, which seems odd: surely that should build tools that not only don't use debuginfod but which don't depend on it in any way. (If someone can answer that, or point out what I've misunderstood, it may help people.)
Next I figured debuginfod was inescapable (for my cross-tools built from source at least), so I'd install it to get rid of the error. It's a component of the elfutils package, but installing the latest elfutils available for my Ubuntu 20.04 system didn't bring libdebuginfod.so.1 with it.
I found a later one, for Arch Linux, whose package contents suggested it would - but its package format doesn't match Ubuntu's and installing it was going to involve a lot of work. Instead I opted to build it from the Arch Linux source package. However, running ./configure on that gave a couple of infuriatingly similar errors:
configure: checking libdebuginfod dependencies, --disable-libdebuginfod or --enable-libdebuginfo=dummy to skip
...
configure: error: dependencies not found, use --disable-libdebuginfod to disable or --enable-libdebuginfod=dummy to build a (bootstrap) dummy library.
No combination of those suggestions would allow configure for elfutils-0.182 to run to completion.
The problem of course was my own lack of understanding. The solution came from the Linux From Scratch project: what worked was to issue configure with both of the suggested options, like this:
$ ./configure --prefix=/usr \
--disable-debuginfod \
--enable-libdebuginfod=dummy \
--libdir=/lib
That gave a clean configure; make worked first time, as did make check and then sudo make install which of course installed libdebuginfod.so.1 as required. I then had an arm-none-eabi-objdump which disassembles cross-compiled ELF files without complaining.

How to compile c++ programs in the new c++ driver provided by Datastax in Linux

I am new to Cassandra. I installed c++ driver from Datastax. Can some one please provide me the steps like in which path I have to create the ‘.c’ file and how I can compile it. I can see some example programs in example folder. Can anyone plz tell me how to compile the example programs.
The cpp-driver uses cmake and depends on libuv. So the first steps would be to ensure you have cmake installed as well as libuv. Depending on your linux distribution it may be as simple as using package manager like apt or yum (i.e. sudo apt-get install cmake libuv-dev)
Building is just a matter of running the following steps in the cpp-driver directory:
cmake .
make
sudo make install
This will install libcassandra.so to somewhere in your lib path. You can then link by providing '-lcassandra' in your parameters to clang or gcc (i.e. clang myfile.c -o myfile -lcassandra)
There is very comprehensive documentation on building from source here.

asm/errno.h: No such file or directory

While building gcc, I get this error:
In file included from /usr/include/bits/errno.h:25,
from /usr/include/errno.h:36,
from ../.././gcc/tsystem.h:96,
from ../.././gcc/crtstuff.c:68:
/usr/include/linux/errno.h:4:23: error: asm/errno.h: No such file or directory
make[2]: *** [crtbegin.o] Error 1
make[2]: Leaving directory `/opt/gcc-4.1.2/host-x86_64-unknown-linux-gnu/gcc'
I am building gcc 4.1 from source. I think I have to install build-essential. However installing that package in ubuntu 12.04 will automatically download and install gcc 4.6 and I don't want that.
Is there any other way?
I think the package you want is linux-libc-dev . I encountered this when building 32-on-64; so I needed linux-libc-dev:i386 .
This worked for me:
ln -s /usr/include/asm-generic /usr/include/asm
This worked for me:
sudo ln -s /usr/include/asm-generic /usr/include/asm
The reason being that what GCC expects to be called /usr/include/asm is renamed to /usr/include/asm-generic in some distros.
This fixed it for me.
sudo apt-get install linux-libc-dev:i386
This solved it for me on Debian 10, even though I was compiling with an LLVM-based compiler:
sudo apt install gcc-multilib
/usr/include/asm/errno.h is part of the linux headers. I can't speak directly to Ubuntu 12.04, but in general you can download the linux sources as a package for your distro and it shouldn't require you to download/install gcc. Failing that, you can manually download the linux headers for the version of your kernel (uname -a) and use an include directive to CFLAGS to specify the directory to look for those.
Edit: sudo apt-get install linux-headers-generic may work for you.
You are missing part of the development packages. I don't know Ubuntu, but you should be able to ask it's package management system to install the package containing /usr/include/asm/errno.h.
Do not copy some file with a similar name from somewhere on your system (or, even worse, from somewhere else). Missing files might mean that some package is damaged; again, ask your package manager to check everything and (re)install missing/broken pieces.
Unless you are running some LTS release, upgrade. Your Ubuntu is some 2 years old, i.e., ancient.
While we are at this, why on this beautiful planet are you building such an ancient compiler? Current GCC is just released 4.9.0, anything before 4.7 is ancient history, not longer supported.
On Ubuntu 16.04 x86_64 you could try this:
ln -s /usr/include/x86_64-linux-gnu/asm /usr/include/asm
This works on my server.
If you want to use errno.h that is in the asm file, simply go to /usr/(ctrl + l, type /usr/) and then search for errno.h and errno-base.h. Once you did find them, copy the code in these two files, and place them in your include folder. And be careful, in "errno.h" the file includes "errno-base.h" as:
#include <asm-generic/errno-base.h>
Either create a directory with the same name above or change the code above to something different which is suitable for you to use.
If you can find:
usr/include/asm-generic/errno.h
by executing:
find /usr/include -name errno.h
then try to execute:
cp --archive /usr/include/asm-generic /usr/include/asm
It may fix that problem.
I had this issue while compiling Asterisk 1.8.24.0 and solved it with:
mkdir /usr/include/asm-generic
cp /usr/include/asm/errno-base.h /usr/include/asm-generic/
Don't know if it is the "right way" but i've read the comments above and that gave me the idea... and it worked :)

Resources