I have a static library (C++) (say, libmylib_DARWIN.a and libmylib_LINUX.a for 2 architectures) compiled on my Mac using clang (Apple LLVM version 9.0.0 (clang-900.0.39.2) if is of any relevance).
Right now, there are two problems:
The static library (using a current build configuration) contains debug symbols
It also shows names of the object files that were used for the archive
otool -Iv libmylib_DARWIN.a
Archive : libmylib_DARWIN.a
libmylib_DARWIN.a(firstobjectfile.cpp.o)
libmylib_DARWIN.a(secondobjectfile.cpp.o)
....
I would like to remove both the debug symbols and archived filenames from this library. I wonder if there is a convenient way to do it without changing my build configuration.
will strip on Mac do it for both DARWIN- and LINUX-built libraries? Anything I should pay attention too?
strip doesn't seem to remove the archive filenames
There are some similar questions on SO; however, the ones I found deal with either iOS, Objective C, do not talk about multiplatform, and do not mention archive names.
This script implements Sigismondo's suggestion (unpacks the archive, strips each object file individually, renames them 1000.o, 1001.o, etc., and repacks). The parameters for ar crus may vary depending on your version of ar.
#!/bin/bash
# usage: repack.sh file.a
if [ -z "$1" ]; then
echo "usage: repack file.a"
exit 1
fi
if [ -d tmprepack ]; then
/bin/rm -rf tmprepack
fi
mkdir tmprepack
cp $1 tmprepack
pushd tmprepack
basename=${1##*/}
ar xv $basename
/bin/rm -f $basename
i=1000
for p in *.o ; do
strip -d $p
mv $p ${i}.o
((i++))
done
ar crus $basename *.o
mv $basename ..
popd
/bin/rm -rf tmprepack
exit 0
Related
I've built GCC 4.9.3 from sources and installed into my home directory with some prefix, e.g. gcc4.9.
Now I want to use a newer version of binutils along with GCC 4.9.3. I've built them and installed separately in my home directory, with prefix binutils2.26.
How I can force gcc-ar from gcc4.9 to use ar from binutils2.26 instead of system one? It always calls /usr/bin/ar and looks like there is no options to specify. Replacing /usr/bin/ar somehow is not an option - I don't have root access on this machine.
Use GCC's -B flag and point it at the directory that contains the ar you want to execute. See the GCC manual for more details on this flag.
gcc-ar -B/path/to/your/dir ...
It seems to work for me:
$ strace -f -eexecve gcc-ar rc foo.a /dev/null |& grep /ar
[pid 14485] execve("/usr/lib/gcc/x86_64-pc-linux-gnu/5.3.0/../../../../x86_64-pc-linux-gnu/bin/ar", [...]) = 0
$ strace -f -eexecve gcc-ar rc foo.a /dev/null -B/usr/bin |& grep /ar
[pid 14493] execve("/usr/bin/ar", [...]) = 0
$ strace -f -eexecve gcc-ar rc foo.a /dev/null -B/usr/x86_64-pc-linux-gnu/binutils-bin/2.26/ |& grep /ar
[pid 14500] execve("/usr/x86_64-pc-linux-gnu/binutils-bin/2.26/ar", [...]) = 0
I managed to fix this issue.
Using strace, I found that gcc-ar looks for ar in several directories, including <gcc install dir>/libexec/gcc/x86_64-redhat-linux/4.9.3.
So the obvious solution is to create links in this directory targeting corresponding binutils2.26 executables:
cd "<gcc install dir>/libexec/gcc/x86_64-redhat-linux/4.9.3"
for file in ~/binutils2.26/bin/* ; do ln -s "${file}" ; done
After that all, executables in ~/binutils2.26/bin will be replicated as links in the GCC 4.9.3 directory and will be used automatically when building by that GCC version.
I'm trying to do a Makefile.am who find all the dependency (c and cpp files) at runtime (make).
I test this command :
example_SOURCES=$(shell find . -type f | grep -E '\.c|\.cpp' | awk '{L[NR]=$$0} END {{for (i = 1; i <=NR-1;i++) print L[i]"\\"}; {print L[NR]}}')
The command works fine ( I have controlled with the add of a redirection in a file and the sources are fine).
But the makefile, doesn't use any sources :
gcc -g -O2 -o example
How can I archive my objective for auto-founds all sources ?
p.s I have read that automake must know all sources at call, this is correct ? This can be an explanation why my script doesn't work.
More details :
I have modify the Makefile generate and place an echo on example_sources and he contain all my files.
I have check the differences between the Makefile with my script and without and the main point is this part :
With script :
am_example_OBJECTS =
With manual dependency :
am_example_OBJECTS = ./main.$(OBJEXT)
He appear the automake need to know the sources files himself for generate the makefile.
So I have found a workaround,
I use a sed to change the Makefile.am during the configure.
# Source + dependency.
files=`find ./src/ -type f | grep -E '\.h$$|\.hpp$$|\.c$$|\.cpp$$' | sed 's/\/src//g'`
sed -i '/.*_SOURCES.*/c\'"$soft"'_SOURCES = '"$files"'' src/Makefile.am
It's work fine, when we add sources, we just need to do ./configure to update the dependency list.
I need to include node.h in my c++ project, I tried to build node from source code using:
./configure
sudo make
I got a node executable and some object files and .a files, I need to build as .so file to use it in my c++ code.
I tried to build libnode, but I got cmakelists error and this is not official nodejs project.
if anybody know how to build nodejs from source code as .so file will be great, a similar question in a google group but the answer is not working.
Support for building as a shared library has been added in to node mainline. Please see PR 6994 and specifically this comment.
I just ran
git clone https://github.com/nodejs/node.git
cd node
git checkout v6.9.4
./configure --shared
make -j4
which produced:
ubuntu#server:~/node$ find . -name libnode.so\* -exec ls -la {} \;
-rwxrwxr-x 2 ubuntu ubuntu 31576776 Jan 6 18:57 ./out/Release/lib.target/libnode.so.48
-rw-rw-r-- 1 ubuntu ubuntu 387 Jan 6 18:57 ./out/Release/.deps/home/ubuntu/node/out/Release/lib.target/libnode.so.48.d
-rw-rw-r-- 1 ubuntu ubuntu 4202 Jan 6 18:57 ./out/Release/.deps/home/ubuntu/node/out/Release/obj.target/libnode.so.48.d
-rwxrwxr-x 2 ubuntu ubuntu 31576776 Jan 6 18:57 ./out/Release/obj.target/libnode.so.48
ubuntu#server:~/node$
I think it is easier to build in a static library as shared requires the addition of '-fpic'.
For my projects (under Linux) I use this script to built a static node.js library:
#!/bin/sh
# This script is LGPL feel free to use it!
if test ! "$#" = "1"; then
echo "Run with the archive in parameter:"
echo "\t${0} ./node-v0.XX.XX.tar.gz"
echo "\nIt will build a ./libnode_static.a in current dir"
return
fi
HERE=$PWD
#Extract Tarball
tar xf $1 | exit 1
DIRNAME=`echo $1 | sed s/.tar.gz//g`
cd $DIRNAME
#Patch node.gyp to build in static
sed -i "s/'type': 'executable',/'type': 'static_library',/g" ./node.gyp
#Patch node_main.cc to rename the main in node_main
sed -i "s/int main(/int node_main(/g" ./src/node_main.cc
#Build Node.js
./configure
make -j8
#Move to build directory
cd ./out/Release
#Extract .a
#Cleanup if previous build
rm -fr *.tmpd
echo "== Extracting *.a =="
#Make sure we create a directory
#for each.a as some .o might
#have the same name
for a in `ls *.a`
do
echo "\t${a}..."
mkdir "$a.tmpd"
cd "$a.tmpd"
ar x ../$a
cd ..
done
#Repack in a single .a
find . -iname "*.o" | xargs ar rcs libnode_static.a
#Cleanup
rm -fr *.tmpd
echo "== DONE =="
#Move in start directory
mv ./libnode_static.a ${HERE}/
cd ${HERE}
#Sanity CHECK
echo "== Performing Sanity Check =="
TMP_FILE=`mktemp /tmp/XXXXXX.cxx`
TMP_EXE=`mktemp /tmp/XXXXXX`
cat << . > ${TMP_FILE}
int node_main( int argc, char **argv);
int main(int argc, char ** argv )
{
node_main( argc, argv );
return 0;
}
.
#Try compiling
g++ ${TMP_FILE} -o ${TMP_EXE} -lnode_static -ldl -pthread -L.
#Try running
RET=`${TMP_EXE} -e "console.log('okfromnode')"`
if test "x${RET}" = "xokfromnode"; then
echo "== Sanity check OK =="
else
echo "== Sanity check FAILED =="
exit 1
fi
rm ${TMP_FILE} ${TMP_EXE}
echo "== Node.js is now built statically in ./libnode_static.a =="
exit 0
Run it as follows :
sh script.sh node-v0.10.XX.tar.gz
If everything goes well you should get a libnode_static.a in current directory.
Use it with a code like this:
int node_main( int argc, char **argv);
int main(int argc, char ** argv )
{
/* Here we spawn a node.js instance */
return node_main( argc, argv );
}
And compile like this:
g++ ./test.cxx -o ./my_node -lnode_static -ldl -pthread -L.
And you have embedded node :
./my_node -e "console.log('Hello World')"
#Outputs
Hello World
Hope this helps.
This is how i did it in windows. Except for the build procedures, everything should be same.
Nodejs uses node-gyp for building. You can read this for building and installation. Or just git clone the repository.
Open node.gyp in the node-vX.XX.XX and find
'targets': [
{
'target_name': 'node',
'type': 'executable',
change the executable to shared_library.
Run vcbuild.bat in windows or for other platforms follow instructions.
Update:
https://gist.github.com/aklen/849f3460b7a028c9aed8a84e1d4cecb7
Windows
.\vcbuild release vs2017 dll x64
.\vcbuild release vs2017 dll x86
.\vcbuild debug vs2017 dll x64
.\vcbuild debug vs2017 dll x86
Linux / MacOS
./configure --shared --release
make -j4
./configure --shared --debug
make -j4
Other build options
https://github.com/nodejs/node/blob/master/BUILDING.md
I am trying to build gcc 4.7.2 using a custom prefix $PREFIX
I have built and installed all the prerequisites into my prefix location, and then successfully configured, built and installed gcc.
The problem that I now have is that $PREFIX is not in the library search path, and therefore the shared libraries cannot be found.
$PREFIX/bin $ ./g++ ~/main.cpp
$PREFIX/libexec/gcc/x86_64-suse-linux/4.7.2/cc1plus: \
error while loading shared libraries: \
libcloog-isl.so.1: \
cannot open shared object file: No such file or directory
What works, but isn't ideal
If I export LD_LIBRARY_PATH=$PREFIX/lib then it works, but I'm looking for something which works without having to set environment variables.
If I use patchelf to set the RPATH on all the gcc binaries then it also works; however this involves searching out all elf binaries and iterating over them calling patchelf, I would rather have something more permanent.
What I think would be ideal for my purposes
So I'm hoping there is a way to have -Wl,-rpath,$PREFIX/lib passed to make during the build process.
Since I know the paths won't need to be changed this seems like the most robust solution, and can be also be used for when we build the next gcc version.
Is configuring the build process to hard code the RPATH possible?
What I have tried, but doesn't work
Setting LDFLAGS_FOR_TARGET prior to calling configure:
All of these fail:
export LDFLAGS_FOR_TARGET="-L$PREFIX/lib -R$PREFIX/lib"
export LDFLAGS_FOR_TARGET="-L$PREFIX/lib"
export LDFLAGS_FOR_TARGET="-L$PREFIX/lib -Wl,-rpath,$PREFIX/lib"
Setting LDFLAGS prior to calling configure:
export LDFLAGS="-L$PREFIX/lib -Wl,-rpath,$PREFIX/lib"
In any event I worry that these will override any of the LDFLAGS gcc would have had, so I'm not sure these are a viable option even if they could be made to work?
My configure line
For completeness here is the line I pass to configure:
./configure \
--prefix=$PREFIX \
--build=x86_64-suse-linux \
--with-pkgversion='SIG build 12/10/2012' \
--disable-multilib \
--enable-cloog-backend=isl \
--with-mpc=$PREFIX \
--with-mpfr=$PREFIX \
--with-gmp=$PREFIX \
--with-cloog=$PREFIX \
--with-ppl=$PREFIX \
--with-gxx-include-dir=$PREFIX/include/c++/4.7.2
I've found that copying the source directories for gmp, mpfr, mpc, isl, cloog, etc. into the top level gcc source directory (or using symbolic links with the same name) works everywhere. This is in fact the preferred way.
You need to copy (or link) to those source directory names without the version numbers for this to work.
The compilers do not need LD_LIBRARY_PATH (although running applications built with the compilers will need an LD_LIBRARY_PATH to the $PREFIX/lib64 or something like that - but that's different)
Start in a source directory where you'll keep all your sources.
In this source directory you have your gcc directory either by unpacking a tarball or svn...
I use subversion.
Also in this top level directory you have, say, the following source tarballs:
gmp-5.1.0.tar.bz2
mpfr-3.1.1.tar.bz2
mpc-1.0.1.tar.gz
isl-0.11.1.tar.bz2
cloog-0.18.0.tar.gz
I just download these and update to the latest tarballs periodically.
In script form:
# Either:
svn checkout svn://gcc.gnu.org/svn/gcc/trunk gcc_work
# Or:
bunzip -c gcc-4.8.0.tar.bz2 | tar -xvf -
mv gcc-4.8.0 gcc_work
# Uncompress sources.. (This will produce version numbered directories).
bunzip -c gmp-5.1.0.tar.bz2 | tar -xvf -
bunzip -c mpfr-3.1.1.tar.bz2 | tar -xvf -
gunzip -c mpc-1.0.1.tar.gz | tar -xvf -
bunzip -c isl-0.11.1.tar.bz2 | tar -xvf -
gunzip -c cloog-0.18.0.tar.gz | tar -xvf -
# Link outside source directories into the top level gcc directory.
cd gcc_work
ln -s ../gmp-5.1.0 gmp
ln -s ../mpfr-3.1.1 mpfr
ln -s ../mpc-1.0.1 mpc
ln -s ../isl-0.11.1 isl
ln -s ../cloog-0.18.0 cloog
# Get out of the gcc working directory and create a build directory. I call mine obj_work.
# I configure the gcc binary and other outputs to be bin_work in the top level directory. Your choice. But I have this:
# home/ed/projects
# home/ed/projects/gcc_work
# home/ed/projects/obj_work
# home/ed/projects/bin_work
# home/ed/projects/gmp-5.1.0
# home/ed/projects/mpfr-3.1.1
# home/ed/projects/mpc-1.0.1
# home/ed/projects/isl-0.11.1
# home/ed/projects/cloog-0.18.0
mkdir obj_work
cd obj_work
../gcc_work/configure --prefix=../bin_work <other options>
# Your <other options> shouldn't need to involve anything about gmp, mpfr, mpc, isl, cloog.
# The gcc build system will find the directories you linked,
# then configure and compile the needed libraries with the necessary flags and such.
# Good luck.
I've been using this configure option with gcc-4.8.0, on FreeBSD, after building and installing gmp, isl and cloog:
LD_LIBRARY_PATH=/path/to/isl/lib ./configure (lots of other options) \
--with-stage1-ldflags="-rpath /path/to/isl/lib -rpath /path/to/cloog/lib -rpath /path/to/gmp/lib"
and the resulting gcc binary does not need any LD_LIBRARY_PATH. The LD_LIBRARY_PATH for configure is needed because it compiles a test program to check for the ISL version, which would fail if it didn't find the ISL shared lib.
I tried it on Linux (Ubuntu) where it failed during configuring because the -rpath args were passed to gcc instead of ld. I could fix this by using
--with-stage1-ldflags="-Wl,-rpath,/path/to/isl/lib,-rpath,/path/to/cloog/lib,-rpath,/path/to/gmp/lib"
instead.
Just using configure --with-stage1-ldflags="-Wl,-rpath,/path/to/lib" was not enough for me to build gcc 4.9.2, bootstrap failed in stage 2. What works is to pass he flags directly to make via
make BOOT_LDFLAGS="-Wl,-rpath,/path/to/lib"
I got this from https://gcc.gnu.org/ml/gcc/2008-09/msg00214.html
While it still involves setting environment variables, what I do is that I define LD_RUN_PATH, which sets the rpath. That way the rest of the system can keep using the system provided libraries instead of using the ones that your gcc build generates.
I am going to make a suggestion that I believe solves your problem, although it definitely does not answer your question. Let's see how many downvotes I get.
Writing a generic wrapper script to set LD_LIBRARY_PATH and then to run the executable is easy; see https://stackoverflow.com/a/7101577/768469.
The idea is to pass something like --prefix=$PREFIX/install to configure, building an install tree that looks like this:
$PREFIX/
install/
lib/
libcloogXX.so
libgmpYY.so
...
bin/
gcc
emacs
...
bin/
.wrapper
gcc -> .wrapper
emacs -> .wrapper
.wrapper is a simple shell script:
#!/bin/sh
here="${0%/*}" # or use $(dirname "$0")
base="${0##*/}" # or use $(basename "$0")
libdir="$here"/../install/lib
if [ "$LD_LIBRARY_PATH"x = x ] ; then
LD_LIBRARY_PATH="$libdir"
else
LD_LIBRARY_PATH="$libdir":"$LD_LIBRARY_PATH"
fi
export LD_LIBRARY_PATH
exec "$here"/../install/bin/"$base" "$#"
This will forward all arguments correctly, handle spaces in arguments or directory names, and so forth. For practical purposes, it is indistinguishable from setting the rpath like you want.
Also, you can use this approach not only for gcc, but for your entire my-personal-$PREFIX tree. I do this all the time in environments where I want an up-to-date suite of GNU tools, but I do not have (or want to admit to have) root access.
Try to add your $PREFIX to /etc/ld.so.conf and then run ldconfig:
# echo $PREFIX >> /etc/ld.so.conf
# ldconfig
This will recreate cache that is used by runtime linker and it will pick up your libraries.
WARNING: This operation will cause ALL applications to use your newly compiled libraries in $PREFIX instead of default location
I am working on a project which requires the understanding of llvm compiler source-code. To browse source code of llvm, I tried to use cscope with following command in the root directory of the source:
cscope -R *
But it doesn't work. As there are mainly .cpp and .h files but some .c files are also there. So now I don't have a clue how to make cscope work? Can someone please help?
You can use following commands to do the required task from the root directory of llvm source tree:
touch tags.lst
find | grep "\.c$" >> tags.lst
find | grep "\.cpp$" >> tags.lst
find | grep "\.h$" >> tags.lst
cscope -i tags.lst
It would create cscope.out file which is used with cscope to browse the code. Hope it helps!
A convenient way to list all C++ files in a project is to use the ack tool: a grep-like command optimized for source code searching (In some distributions, for instance Ubuntu, the tool is called ack-grep). You can run it like this:
ack -f --cpp > cscope.files
The output are paths to all .cpp, .h, .cc .hpp files
Just because this is still the most popular entry. The stdin thingy may have been added in the meantime or not, but it makes it kind of elegant:
find -regex '.*\.\(c\|h\|cpp\|cxx\|hh\|hpp\|hxx\)$' | cscope -i- -b -q
I have following in my .bashrc which make things easier. Run cscope_build() to generate data base and cscope to start cscope tool.
# Use vim to edit files
export CSCOPE_EDITOR=`which vim`
# Generate cscope database
function cscope_build() {
# Generate a list of all source files starting from the current directory
# The -o means logical or
find . -name "*.c" -o -name "*.cc" -o -name "*.cpp" -o -name "*.h" -o -name "*.hh" -o -name "*.hpp" > cscope.files
# -q build fast but larger database
# -R search symbols recursively
# -b build the database only, don't fire cscope
# -i file that contains list of file paths to be processed
# This will generate a few cscope.* files
cscope -q -R -b -i cscope.files
# Temporary files, remove them
# rm -f cscope.files cscope.in.out cscope.po.out
echo "The cscope database is generated"
}
# -d don't build database, use kscope_generate explicitly
alias cscope="cscope -d"
To cover our large code base I have a script that looks a bit like this to build cscope indexes. The reason I change to / is so that I have full file paths to the source files which makes things work a little smoother.
cd /
find -L /home/adrianc/code -name "*.c" -o -name "*.cc" -o -name "*.h" > /home/adrianc/code/cscope.files
cd /home/adrianc/code
/usr/local/bin/cscope -b -icscope.files -q -u
Also it may be worth checking out
http://cscope.sourceforge.net/cscope_vim_tutorial.html