I'm having some trouble building the csv library libcsv.
I'm using Windows XP, MinGW compiler and MSYS command shell.
It configures ok (./configure) but when I go to build it I get the below error. I realise it has to do with autoconf (it requires 2.65 or above) So what do I do here. Do I download autoconf and have it in a separate directory marked c:\autoconf and have an environmental variable pointing to it? Or,, does it go in the MSYS folder.
I have downloaded the binaries for autoconf and I just get a bunch of files. The binary files are in a SHARE folder and a 'bin' folder. Do I put their contents into the MsYS share and bin folders? Looking around the web I'm also seeing references to putting the autoconf binaries into my MinGW/bin folder. I'm really not sure what to do here?
Can anyone help? Thank you.
xxxx#XXXX-2FEF09FD39 ~
$ cd C:\libcsv-3.0.3
xxxx#XXXX-2FEF09FD39 /c/libcsv-3.0.3
$ make
CDPATH="${ZSH_VERSION+.}:" && cd . && /bin/sh /c/libcsv-3.0.3/missing --run autoconf
/bin/m4: unrecognized option `--gnu'
Try `/bin/m4 --help' for more information.
autom4te: /bin/m4 failed with exit status: 1
make: *** [configure] Error 1
xxxx#XXXX-2FEF09FD39 /c/libcsv-3.0.3
$
Related
I am trying to compile google/woff2 for 3 days but getting error "libbrotli needed". I was able compile brotli by running CMakeLists.txt in brotli folder and got .so files. I am beginner so I don't know to link both together. I want to compile and add brotli from CMakeLists.txt in woff2 folder or at least somehow compile linux build for woff2.
Thanks
It seems like you need to compile and install brotli on your machine before you can compile google/woff2. The installation process is actually copying the .so and header file to somewhere on your system path that CMake is able to find it.
For example, you can you use this command to install the library to "/home/myuser/installdir"
cmake --install . --prefix "/home/myuser/installdir"
Build woff2 with libbrotli included in the executable
woff2/README.md says:
git clone --recursive https://github.com/google/woff2.git && cd woff2/ && make clean all
I.e. the woff2 executable´s can be built and used in the woff2/ directory, or can be copied to any location.
cd new-Folder/
git clone --recursive
https://github.com/google/woff2.git
cd woff2/
make clean all ## brotli libs and woff2 are built ... together
## executable: {woff2_compress, woff2_decompress, woff2_info}
## compress example
./woff2_compress satluj.ttf
Processing satluj.ttf => satluj.woff2
Compressed 45526 to 21423.
P.S.: Many of the "Linux OS" have woff2 (and libbrotli) available as a package, name = woff2 or woff2-tools.
I am attempting to cross compile a project for my raspberry pi (32 bit armv8) on my ubuntu machine. I set up a toolchain using crosstool-NG and compiling works, but linking fails. My CMake toolchain file is as follows:
SET(CMAKE_SYSTEM_NAME Linux)
SET(CMAKE_SYSTEM_VERSION 1)
set(CMAKE_SYSROOT /home/stone/development/raspberry_pi/armv8-rpi3-linux-gnueabihf/armv8-rpi3-linux-gnueabihf/sysroot)
SET(CMAKE_C_COMPILER /home/stone/development/raspberry_pi/armv8-rpi3-linux-gnueabihf/bin/armv8-rpi3-linux-gnueabihf-gcc)
SET(CMAKE_CXX_COMPILER /home/stone/development/raspberry_pi/armv8-rpi3-linux-gnueabihf/bin/armv8-rpi3-linux-gnueabihf-g++)
SET(CMAKE_FIND_ROOT_PATH /home/stone/development/raspberry_pi/armv8-rpi3-linux-gnueabihf)
SET(CMAKE_FIND_ROOT_PATH_MODE_PROGRAM NEVER)
# for libraries and headers in the target directories
SET(CMAKE_FIND_ROOT_PATH_MODE_LIBRARY ONLY)
SET(CMAKE_FIND_ROOT_PATH_MODE_INCLUDE ONLY)
set(CMAKE_FIND_ROOT_PATH_MODE_PACKAGE ONLY)
I have a few libraries that are not being found by the linker. The problem is with my sysroot. I copied over /usr and /lib from the pi to my sysroot folder that was created by crosstool-NG. The libraries that are being linked reside in sysroot/usr/lib/arm-linux-gnueabihf.
However, the linker is not checking that directory, it checks sysroot/usr/lib and a few others, but for some reason it does not check the arm-linux-gnueabihf directory.
On the pi, I can run ld -lasound --verbose and get the following output:
attempt to open //usr/local/lib/arm-linux-gnueabihf/libasound.so failed
attempt to open //usr/local/lib/arm-linux-gnueabihf/libasound.a failed
attempt to open //lib/arm-linux-gnueabihf/libasound.so failed
attempt to open //lib/arm-linux-gnueabihf/libasound.a failed
attempt to open //usr/lib/arm-linux-gnueabihf/libasound.so succeeded
so its finding it correctly on the pi.
When I do the same using the ld generated by crosstool-NG:
attempt to open /home/stone/development/raspberry_pi/armv8-rpi3-linux-gnueabihf/armv8-rpi3-linux-gnueabihf/bin/../sysroot/home/stone/x-tools/armv8-rpi3-linux-gnueabihf/armv8-rpi3-linux-gnueabihf/lib/libasound.so failed
attempt to open /home/stone/development/raspberry_pi/armv8-rpi3-linux-gnueabihf/armv8-rpi3-linux-gnueabihf/bin/../sysroot/home/stone/x-tools/armv8-rpi3-linux-gnueabihf/armv8-rpi3-linux-gnueabihf/lib/libasound.a failed
attempt to open /home/stone/development/raspberry_pi/armv8-rpi3-linux-gnueabihf/armv8-rpi3-linux-gnueabihf/bin/../sysroot/usr/local/lib/libasound.so failed
attempt to open /home/stone/development/raspberry_pi/armv8-rpi3-linux-gnueabihf/armv8-rpi3-linux-gnueabihf/bin/../sysroot/usr/local/lib/libasound.a failed
attempt to open /home/stone/development/raspberry_pi/armv8-rpi3-linux-gnueabihf/armv8-rpi3-linux-gnueabihf/bin/../sysroot/lib/libasound.so failed
attempt to open /home/stone/development/raspberry_pi/armv8-rpi3-linux-gnueabihf/armv8-rpi3-linux-gnueabihf/bin/../sysroot/lib/libasound.a failed
attempt to open /home/stone/development/raspberry_pi/armv8-rpi3-linux-gnueabihf/armv8-rpi3-linux-gnueabihf/bin/../sysroot/usr/lib/libasound.so failed
It fails to find it because it doesnt look in the arm-linux-gnueabihf directory. I copied the library .so file from sysroot/usr/lib/arm-linux-gnueabihf to sysroot/usr/lib and it compiles and links successfully, but I would like to make it so that I do not have to do that. How can I make the linker check that arm-linux-gnueabihf directory?
EDIT: I also copied /etc/ld.so.conf and /etc/ld.so.conf.d from the pi into my sysroot, but it does not seem to affect the linker.
EDIT: After further research it looks like this might be due to something with gcc-multiarch. I am not sure what that is but hopefully I can figure this out
EDIT: I verified that indeed the linker is not searching the arm-linux-gnueabihf path:
./armv8-rpi3-linux-gnueabihf-ld --verbose | grep -i "search"
outputs:
SEARCH_DIR("=/home/stone/x-tools/armv8-rpi3-linux-gnueabihf/armv8-rpi3-linux-gnueabihf/lib"); SEARCH_DIR("=/usr/local/lib"); SEARCH_DIR("=/lib"); SEARCH_DIR("=/usr/lib");
Alright I got it all figured out. The repo where I learned the tricks to getting this to work can be found here. I am grateful for this repo, without it I would not have gotten this to work.
The issue lies with the linker. The linker that comes with plain old binutils that gets pulled in by crosstool-ng does not search the arm-linux-gnueabihf subdirectories. These directories exist because of Debian multiarch, and in order to get a linker that looks in such a directory, binutils needs to be patched. The instructions that follow assume you have already generated a ct-ng config based on the rpi3 sample.
On the raspberry pi, I installed the binutils-source package:
$ sudo apt install binutils-source
This will give access to a patch file located in /usr/src/binutils/patches.
On the host machine, you need to add a patches directory in the directory where you are building your toolchain (where the ct-ng config file is). It must have a specific structure that reflects the structure of packages in the crosstool-ng repo (ie. inside patches/ you must have a directory with the package name, inside that you must have the version number, and inside that is where you place the patch.):
$ cd your_toolchain_directory
$ mkdir -p patches/binutils/2.31.1/
Now we can copy the patch file from the pi to the host. The specific patch we need is 129_multiarch_libpath.patch:
$ cd patches/binutils/2.31.1/
$ scp pi#raspberrypi:/usr/src/binutils/129_multiarch_libpath.patch
Now that we have the patch, we need to update the config file to tell ct-ng to include local patches as well as enable the multiarch flag for gcc. You can do this using ct-ng menuconfig so change back to the directory with the config file and run:
$ ct-ng menuconfig
In the paths and misc options you need to change the patches origin to bundled then local, and then add ${CT_TOP_DIR}/patches as the local patch directory. This should produce the following lines under the extracting section of the .config file:
CT_PATCH_BUNDLED_LOCAL=y
CT_PATCH_ORDER="bundled,local"
CT_PATCH_USE_LOCAL=y
CT_LOCAL_PATCH_DIR="${CT_TOP_DIR}/patches"
Next you need to add the --enable-multiarch flag in the gcc options. Again using menuconfig, go to the C compiler settings. Add --enable-multiarch to the gcc extra config setting. The config file should have the following in the gcc settings:
CT_CC_GCC_EXTRA_CONFIG_ARRAY="--enable-multiarch"
Save the config. The last thing we need to do is export a variable.
$ export DEB_TARGET_MULTIARCH=arm-linux-gnueabihf
Now we can build the toolchain:
$ ct-ng build
Once its done, you can change into the bin directory of the generated toolchain and run:
$ ./ld --verbose | grep -i "search"
and you should see that the arm-linux-gnueabihf directory is now in the search paths. What a process.
You need to use static library instead. then the executable will include the binary of the libraries.
But keep in mind the executable file will be bigger ( depends obviously which lib...).
When you using cross compile, you should check that the libraries you use exist in the other environment you execute the program.
The solution will be to add STATIC word according to CmakeList.txt file
I've found the lightweight DSP c library - Soundpipe.
I want to use some filters from it. I do not really need binary files, but the problem is that the repository doesn't have its main header file - soundpipe.h. As I understand, this is because the library uses specific modules ported from Csound and FAUST languages. Also the repository's readme doesn't have installation guide for Windows. It says:
By default, Soundpipe needs libsndfile, and a standard build
environment. Other modules that use other external libraries will need
to be explicitly compiled by modifying config.mk (note: but the Makefile's folder doesn't contain config.mk, there is only config.def.mk)
To compile:
make
sudo make install
Ok, I've downloaded and installed libsndfile.
Then I have tried to use MSVC's nmake - it doesn't work:
makefile(7) : fatal error U1036: syntax error : too many names to left of '='
Stop.
Here is the beginning of the makefile:
> .PHONY: all clean install docs bootstrap
>
> default: all
>
> VERSION = 1.5.0
>
> INTERMEDIATES_PREFIX ?= . PREFIX ?= /usr/local
> ...
After that I've downloaded MinGW, mingw32-make result:
config.mk: No such file or directory
mingw32-make: *** No rule to make target 'config.def.mk', needed by 'config.mk'. Stop.
Ok, when I try to run the configure command, it doesn't work on my Win7 x 64 (sh: ./configure: No such file or directory, etc...)
I have the paths in mt system path variable:
C:\MinGW\bin;C:\MinGW\msys\1.0\bin
Links that I've read:
How Do I Run ./configure with MinGW?
Getting mingw-get to install correctly - mingw/msys path missing plus more!
MinGW's configure doesn't work after reinstalling Git for Windows and GCC_TDM too (No idea how to run configure).
Any ideas how to build the library or at least find missing source files (or make through CSound, Faust, ...) ?
The Soundpipe build system is designed to be used with POSIX environments, of which there are a few to choose from on Windows.
I've been able to build Soundpipe using both MSYS2 and Windows Bash on Windows 10.
... Sorry, this has to be a duplicate, but I'm just running across answers for people who are making their own projects and can change the build system setup.
Can I always compile a program in a separate build directory, or must it be supported by the program's build system?
For vim, you compile using: "./configure && make && sudo make install". If I'm in vim.hg.build and run "../vim.hg/configure .....", I get :
../vim.hg/configure: line 6: cd: src: No such file or directory
For git, you compile using: "make configure && ./configure && make && sudo make install". I was hoping being in git.git.build and running "make --directory=../git.git configure" would work, but that leaves the configure file in ../git.git. Well, maybe just configure left behind isn't so bad, so I then tried "../git.git/configure" which successfully created config.status, config.log, and config.mak.autogen in the build directory. But running make gives:
make: *** No targets specified and no makefile found. Stop.
... Yes, the only Makefile is in git.git itself.
I even tried symlinking the entire directory by running:
for fl in `ls -a ../vim.hg`; do
echo "$fl"
ln -s ../vim.hg/$fl $fl
done
... But, vim's configure and make only modify existing files and subdirectories, so even though I can build this way, the build directory is left with nothing more than symlinks -- no actual separation.
Go cmake!
Out-of-tree building is a feature of Autotools that requires both Autoconf and Automake.
Vim and Git both only use Autoconf and not Automake, so they can't take advantage of that feature.
As a more general answer to your question: simple Autotools projects should work with out-of-tree builds automatically. When using certain advanced features, a bit of care must be taken to ensure that out-of-tree builds continue to work. Sometimes projects don't do this.
(Running make distcheck will test out-of-tree building, so it's a good idea to run it at least once before making a release.)
I am trying to install Subversion on my computer. I have a source code I am supposed to compile, just like a C library, which I find tricky because I am not used to it.
In the folder, there are, among other files:
configure.ac
Makefile.in
In the readme, it says I have to use the standard GNU procedure to compile:
$ ./configure
$ make
# make install
But when writing gcc ./configure.ac in the command line, it says
C:\Users\SC5\Downloads\subversion-1.8.9\subversion-1.8.9>gcc configure.ac
c:/strawberry/c/bin/../lib/gcc/x86_64-w64-mingw32/4.7.3/../../../../x86_64-w64-m
ingw32/bin/ld.exe:configure.ac: file format not recognized; treating as linker s
cript
c:/strawberry/c/bin/../lib/gcc/x86_64-w64-mingw32/4.7.3/../../../../x86_64-w64-m
ingw32/bin/ld.exe:configure.ac:1: syntax error
collect2.exe: error: ld returned 1 exit status
Any idea? A general path on how to install with .config files in general?
Thanks very much for any help.
If you are using windows, just download the .exe and hit enter on it.