I have problem building Port Audio on windows machine. I am following this tutorial: http://portaudio.com/docs/v19-doxydocs/compile_windows_mingw.html
Running make after ./configure runs build process and finally outputs this message and that is where build process stop.
/bin/sh ./libtool --mode=link gcc -shared -rpath /usr/local/lib -no-undefined -
export-symbols-regex "(Pa|PaMacCore|PaJack|PaAlsa|PaAsio|PaOSS)_.*" -version-inf
o 2:0:0 -o lib/libportaudio.la src/common/pa_allocation.lo src/common/pa_convert
ers.lo src/common/pa_cpuload.lo src/common/pa_dither.lo src/common/pa_debugprint
.lo src/common/pa_front.lo src/common/pa_process.lo src/common/pa_stream.lo src/
common/pa_trace.lo src/hostapi/skeleton/pa_hostapi_skeleton.lo src/hostapi/wmme/
pa_win_wmme.lo src/os/win/pa_win_hostapis.lo src/os/win/pa_win_util.lo src/os/wi
n/pa_win_waveformat.lo -lwinmm
*** Warning: linker path does not have real file for library -lwinmm.
*** I have the capability to make that library automatically link in when
*** you link to this library. But I can only do this if you have a
*** shared version of the library, which you do not appear to have
*** because I did check the linker path looking for a file starting
*** with libwinmm but no candidates were found. (...for file magic test)
*** The inter-library dependencies that have been dropped here will be
*** automatically added whenever a program is linked with this library
*** or is declared to -dlopen it.
*** Since this library must not contain undefined symbols,
*** because either the platform does not support them or
*** it was explicitly requested with -no-undefined,
*** libtool will only create a static version of it.
libtool: link: lib -OUT:lib/.libs/libportaudio.lib src/common/pa_allocation.o s
rc/common/pa_converters.o src/common/pa_cpuload.o src/common/pa_dither.o src/com
mon/pa_debugprint.o src/common/pa_front.o src/common/pa_process.o src/common/pa_
stream.o src/common/pa_trace.o src/hostapi/skeleton/pa_hostapi_skeleton.o src/ho
stapi/wmme/pa_win_wmme.o src/os/win/pa_win_hostapis.o src/os/win/pa_win_util.o s
rc/os/win/pa_win_waveformat.o
./libtool: line 1115: lib: command not found
make: *** [lib/libportaudio.la] Error 127
I am newbie in building libraries so i dont understand what is wrong here.
Any help is appreciated.
Related
My goal is to compile my C program to wasm with emscripten (which I installed via emsdk). It uses libxml2. I am following the steps outlined here https://github.com/kripken/xml.js/blob/master/script/libxml2 to build
libxml2 from source with the appropriate emscripten parameters.
When I run emmake make, I get the following warnings and errors:
...
CCLD libxml2.la
emcc: warning: linking a library with `-shared` will emit a static object file.
This is a form of emulation to support existing build systems.
If you want to build a runtime shared library use the SIDE_MODULE setting. [-Wemcc]
emcc: warning: ignoring unsupported linker flag: `--version-script=./libxml2.syms` [-Wlinkflags]
wasm-ld: error: cannot open libxml2.so.2: No such file or directory
emcc: error: '/home/willy/emsdk/upstream/bin/wasm-ld -o .libs/libxml2.so.2.9.9 .libs/SAX.o .libs/entities.o .libs/encoding.o -L/home/willy/emsdk/upstream/emscripten/system/local/lib .libs/error.o -L/home/willy/emsdk/upstream/emscripten/system/lib .libs/parserInternals.o -L/home/willy/emsdk/upstream/emscripten/cache/wasm .libs/parser.o .libs/tree.o .libs/hash.o .libs/list.o .libs/xmlIO.o .libs/xmlmemory.o .libs/uri.o .libs/valid.o .libs/xlink.o .libs/HTMLparser.o .libs/HTMLtree.o .libs/debugXML.o .libs/xpath.o .libs/xpointer.o .libs/xinclude.o .libs/nanohttp.o .libs/nanoftp.o .libs/catalog.o .libs/globals.o .libs/threads.o .libs/c14n.o .libs/xmlstring.o .libs/buf.o .libs/xmlregexp.o .libs/xmlschemas.o .libs/xmlschemastypes.o .libs/xmlunicode.o .libs/xmlreader.o .libs/relaxng.o .libs/dict.o .libs/SAX2.o .libs/xmlwriter.o .libs/legacy.o .libs/chvalid.o .libs/pattern.o .libs/xmlsave.o .libs/xmlmodule.o .libs/schematron.o .libs/xzlib.o /home/willy/emsdk/upstream/emscripten/cache/wasm/libc.a libxml2.so.2 --relocatable -mllvm -combiner-global-alias-analysis=false -mllvm -enable-emscripten-sjlj -mllvm -disable-lsr' failed (1)
make[2]: *** [Makefile:1065: libxml2.la] Error 1
make[2]: Leaving directory '/home/willy/CWasmSandbox/libxml2-2.9.9'
make[1]: *** [Makefile:1484: all-recursive] Error 1
make[1]: Leaving directory '/home/willy/CWasmSandbox/libxml2-2.9.9'
make: *** [Makefile:897: all] Error 2
The only thing I can gather with my limited understanding of emscripten is that it tries to access libxml2.so.2 which under normal circumstances would be generated from libxml2.la. But libxml2.so.2 was not generated because emscripten does not produce shared objects. Is this assesment correct? I tried passing the option CFLAGS="-s SIDE_MODULE=1" to make, but it didn't fix the error and was probably a stupid idea born from my limited knowledge of build systems. I also tried copying libxml2.so.2 from a previous installation into the appropriate directory, but no luck, and also kind of dumb since emscripten would have no use for .so files? What should my next steps be?
Easiest way is to resign from shared lib.
There is an important limitation with shared one (side module): it will not work if you are going to use threads in your main application.
So just make a change of ./script/libxml2
-emconfigure ../libxml2/configure --with-http=no --with-ftp=no --with-python=no --with-threads=no
+emconfigure ../libxml2/configure --with-http=no --with-ftp=no --with-python=no --with-threads=no --enable-shared=no
Build and link ./build/.libs/libxml2.a with your main application.
I'm writting a extension for pyton3.6. My develop machine run gcc7.3, and production environment os is centos6. I use the following link option to static link glibc to avoid upgrade glibc2.12 to glibc2.14+.
-Wl,-Bdynamic -lpython3.6m -Wl,-Bstatic -lboost_python36
But get error:
[ 50%] Linking CXX shared module helloext.so
/usr/bin/x86_64-linux-gnu-ld: cannot find -lgcc_s
/usr/bin/x86_64-linux-gnu-ld: cannot find -lgcc_s
collect2: error: ld returned 1 exit status
CMakeFiles/helloext.dir/build.make:94: recipe for target 'helloext.so' failed
make[2]: *** [helloext.so] Error 1
CMakeFiles/Makefile2:67: recipe for target 'CMakeFiles/helloext.dir/all' failed
make[1]: *** [CMakeFiles/helloext.dir/all] Error 2
Makefile:83: recipe for target 'all' failed
make: *** [all] Error 2
Anyone known? Thanks.
The reason might be although libgcc is present it may not be in the paths known to ldconfig. Check this by doing
/sbin/ldconfig -p | grep libgcc
Does the output show that there is a link to libgcc corresponds to paths that you have listed above?
A work around for you may be to add the link to the relevant library to your compile command e.g.
... -L /usr/lib/gcc/x86_64-linux-gnu/4.6/
Another may be to create a symbolic link to the library yourself.
ln -s /usr/lib/gcc/x86_64-linux-gnu/4.6/libgcc_s.so /usr/lib/gcc/libgcc_s.so
You have not informed us about Linux you are using. Update 4.6 with the proper number in the command above.
I am installing software on a server with no root privileges. I come across the following error during installation:
make[1]: *** [hgaprec] Error 1
make[1]: Leaving directory `/seq/.../SOFTWARE/hgaprec/src'
make: *** [all-recursive] Error 1
Making install in src
make[1]: Entering directory `/seq/.../SOFTWARE/hgaprec/src'
g++ -O3 -o hgaprec ratings.o main.o log.o hgaprec.o -larpack -llapack -
lblas -lgsl -lpthread -lgslcblas
/.../software/free/Linux/redhat_6_x86_64/pkgs/gcc_5.2.0/bin/ld: cannot
find -larpack
collect2: error: ld returned 1 exit status
make[1]: *** [hgaprec] Error 1
make[1]: Leaving directory `/seq/.../SOFTWARE/hgaprec/src'
make: *** [install-recursive] Error 1
Since library arpack could not be found, I then installed it here /seq/.../SOFTWARE/hgaprec/ARPACK and found that the process generated a static file libarpack_LINUX.a. To link this static library to gcc the following command was used:
gcc -larpack -L/seq/.../SOFTWARE/hgaprec/ARPACK/libarpack_LINUX.a
However, I keep getting the same error while installation of the software that larpack was not found. Am I using the linking command wrong?
You either want gcc main.c /seq/../SOFTWARE/hgaprec/ARPACK/libarpack_LINUX.a (you don't need -l and -L if you're specifying the full path to static library), or as #Julian_Cienfuegos suggested gcc main.c -L/seq/../SOFTWARE/hgaprec/ARPACK/ -larpack_LINUX. This assumes you're only compiling a single file called main.c which contains your main() function, and outputs the a.out binary.
EDIT: Added explanation of main.c.
My issue got solved after including the ARPACK library path as part of LD flag in configure like so:
./configure --prefix=/seq/.../SOFTWARE/hgaprec LDFLAGS="-L/seq/.../SOFTWARE/hgaprec/ARPACK/"
I'm trying to get started with SDL and trying to compile a 'hello world' starter app to check my configuration and I get this error:
C:/MinGW-4.8.1/bin/g++.exe -c "C:/Users/Me/Documents/Cpp_Projects/Demo_Graphics/main.cpp" -g -O0 -Wall -o ./Debug/main.cpp.o -I. -IC:/Users/Me/Documents/Cpp_Projects/SDL2/32bit/include
C:/MinGW-4.8.1/bin/g++.exe -o ./Debug/Demo_Graphics #"Demo_Graphics.txt" -L. -lC:/Users/Me/Documents/Cpp_Projects/SDL2/32bit/lib/
c:/mingw-4.8.1/bin/../lib/gcc/mingw32/4.8.1/../../../../mingw32/bin/ld.exe: cannot find -lC:/Users/Me/Documents/Cpp_Projects/SDL2/32bit/lib/
collect2.exe: error: ld returned 1 exit status
mingw32-make.exe[1]: *** [Debug/Demo_Graphics] Error 1
Demo_Graphics.mk:79: recipe for target 'Debug/Demo_Graphics' failed
mingw32-make.exe[1]: Leaving directory 'C:/Users/Me/Documents/Cpp_Projects/Demo_Graphics'
mingw32-make.exe: *** [All] Error 2
Makefile:4: recipe for target 'All' failed
1 errors, 0 warnings
The directory C:/Users/Me/Documents/Cpp_Projects/SDL2/32bit/lib/ certainly does exist and has the required SDL libraries in it, but I have no clue about compilers.
This is predefined code which should work so the problem is in set up somewhere?
The -l compiler flag is adding a library dependency. It does not specify a path in which to look for libraries (that is the -L flag), which appears to be what you are expecting.
In your error message:
-L. -lC:/Users/Me/Documents/Cpp_Projects/SDL2/32bit/lib/
You can see that the compiler is looking in your current working directory (.) for the library C:/Users/Me/Documents/Cpp_Projects/SDL2/32bit/lib/, but this is not a library -- this is the directory in which you're storing the SDL libraries.
In the CodeLite linker setup you want to change your library path to C:/Users/Me/Documents/Cpp_Projects/SDL2/32bit/lib/, or use
-LC:/Users/Me/Documents/Cpp_Projects/SDL2/32bit/lib/
as a build flag.
You also need to link to the SDL2 library, so you'll need to add -lSDL2 (possibly -lSDL2main as well, I can't remember the specifics of the SDL libraries) to your build/linker flags.
I'm cross compiling to an arm embedded system and receiving an error that I have questions about. Here is the error:
[ 19%] Built target cxjpeg-6b
Linking CXX shared library /home/botbear/JAUS++-2.110519- src/libraries/jaus++/2.0/lib/libcxutils.so
/home/botbear/openwrt/trunk/staging_dir/toolchain-arm_v6k_gcc-linaro_uClibc- 0.9.32_eabi/lib/gcc/arm-openwrt-linux-uclibcgnueabi/4.5.4/../../../../arm-openwrt-linux- uclibcgnueabi/bin/ld: cannot find -lpng
collect2: ld returned 1 exit status
make[2]: *** [/home/botbear/JAUS++-2.110519-src/libraries/jaus++/2.0/lib/libcxutils.so] Error 1
make[1]: *** [libcxutils/CxUtils/libcxutils/CMakeFiles/cxutils.dir/all] Error 2
make: *** [all] Error 2
As you can see the linker is looking for a static library named 'libpng'. In addition to the libpng lib., the command in the sub-make file using the -l switch to link to the following libraries: -lpng -lz -lX11 -lXtst -lpthread -Wl. All of the libraries (libpng,libz,libX11, etc) are in my host /usr/lib/ directory but my target toolchain does not have the the libraries. My question is if I manually recompile the libraries with my target compiler will that solved my problem? Or I'm going to have find and install packages for each of the libraries for my target platform.
Thanks in advance.
You seem to compile for the target, so you need target libraries. Either compiled by yourself or provided by the toolchain development environment (if you have one). The latter usually saves you some headaches (cross compiling and setting the paths where necessary).
I see you are using openwrt toolchain. Openwrt seems to have libpng as a package. I'd go with that if possible.