I'm a Pascal programmer but i need to compile a C library for Windows.
That library is espeak (a voice synthesizer) which uses portaudio lib to access audio port. I have translated the C header into Pascal and have no problem using that library in Linux with the Pascal header.. Also, no problem compiling that lib in Linux (some Make,... and it is done...).
But i want to use it for Windows too...
So i have installed Microsoft Visual Studio and loaded the project.
When I compile the lib, I get messages like:
wavegen.obj : error LNK2019: unresolved external symbol _Pa_Initialize referenced in function "int __cdecl WavegenInitSound(void)" (?WavegenInitSound##YAHXZ)
It seems that the link to the library is not found.
How can i declare what and where that library is (portaudio.dll).
In the code there is #include "portaudio.h" so I think the link to the function is defined.
But I cannot find where it is defined which library (portaudio.dll) to use.
PS : I do not speak great C so some code is very welcome...
Many thanks
You need to make sure that the version of portaudio you are linking to is the same as the version of portaaudio.h that eSpeak compiles to.
The eSpeak sources contain both a v18 and v19 header for portaudio. It also has a portaudio.h which IIRC is a copy of the v18 header.
Related
I like windows gcc equation.com because it like ran natively just like windows compiler. However :
I will need some dll's that not included on distributed package. if i compiled a windows equation.com gfortran program like using Openblas, it will need libgcc_s_seh-1.dll libgfortran-5.dll libquadmath-0.dll libwinpthread-1.dll.
I could find it on web. But how to make it statically linked, i saw libgcc.a libgfortran.a libquadmath.a libpthread.a so i dont have to copy the dll from other. It is possible ?
For several c source code it need include <sys/resource.h> that not included. It's compatible with resource.h from where. After just copied from others, and recompile.
I got error :
c:\gcc\x86_64-w64-mingw32\include\sys\resource.h:74:29: error: unknown type name 'id_t'; did you mean 'pid_t'?
Is there any forum for this type gcc? Is there any debugger for windows gcc that friendly like VisualStudio Community for Intel Fortran.
Regards.
I am using nvcodec sdk (https://developer.nvidia.com/nvidia-video-codec-sdk) and use its linux static library in my project.
I added the compile option in gcc with
gcc myprogram.c NvCodec/Lib/linux/stubs/x86_64/libnvcuvid.so
However, when running the program,
./bin/a.out: symbol lookup error: ./bin/a.out: undefined symbol: cuvidGetDecodeStatus
I found that the symbol cuvidGetDecodeStatus is actually in NvCodec/Lib/linux/stubs/x86_64/libnvcuvid.so.
And by
nm a.out
the symbol is included in the program.
so I tried
ldd a.out
I found it's linked to nvidia driver with same name.
libnvcuvid.so.1 => /usr/lib/nvidia-384/libnvcuvid.so.1
I can't modify the LD_LIBRARY_PATH to modify the search order since NvCodec is a static library.
I have no idea why it's linked to the nvidia driver library even I don't add link option (like -lnvcuvid)
And idea?
thank you
as #Robert Crovella said,
this is an issue for an outdated driver. the library in the cuda codec sdk is actually a stub, which points to the cuda driver shared library.
And there is no symbol like cuvidGetDecodeStatus in the nvidia-384 driver library.
after update nvidia-384 to nvidia-396, the problem solved.
I have a third party C library, both in static format (.lib) and in dynamic format (.dll) with its own import library (.lib). It is MKL (Intel Math Kernel Library). I am working with cygiwn 64 on Windows 7.
In brief, I am trying to get a compiler born to work in POSIX world to talk to a lib compiled in Windows world, assuming that is vene possible.
I want to link that library as part of a C++ executable I am compiling with g++ in cygwin and I am trying to link with the DLL using the import library.
My command line, where I omit the file paths for simplicity, results in a undefined reference error.
$ g++ main.obj mkl_intel_lp64_dll.lib mkl_sequential_dll.lib mkl_core_dll.lib -o paper.exe
mkl_intel_lp64_dll.lib: blah, blah, blah: undefined reference to `__GSHandlerCheck'
... and many other similar errors
Anybody knows if it is possible, and, if yes, how to do it?
Thanks
Try rearranging the arguments to g++ so that main.obj precedes the libraries it references.
I'm trying to compile Rust code on Windows that calls vsnprintf. My C code looks like this:
#include <stdarg.h>
#include <stdio.h>
// A static buffer for storing any formatted messages.
static char buffer[4096];
void rust_logger(const char *fmt, ...) {
// Reconstruct the variable arguments as a va_list. This is necessary so we
// can chain together a call to vsnprintf.
va_list varargs;
va_start(varargs, fmt);
// Write the formatted string to our target (static) buffer.
vsnprintf(buffer, sizeof(buffer)-1, fmt, varargs);
// Call Rust back with final string
...
// Clean up processing of variable arguments
va_end(varargs);
}
This works fine on macOS (and I would guess under Linux, although I have not tried it). But on Windows, I'm having problems. The error I get is:
"C:\\Program Files (x86)\\Microsoft Visual Studio 14.0\\VC\\bin\\amd64\\link.exe" "/LIBPATH:C:\\Program Files (x86)\\Microsoft Visual Studio 14.0\\VC\\lib\\amd64" "/LIBPATH:C:\\Program Files (x86)\\Windows Kits\\10\\lib\\10.0.10240.0\\ucrt\\x64" "/LIBPATH:C:\\Program Files (x86)\\Windows Kits\\8.1\\lib\\winv6.3\\um\\x64" "/NOLOGO" "/NXCOMPAT" "/LIBPATH:C:\\Users\\mtiller\\.rustup\\toolchains\\stable-x86_64-pc-windows-msvc\\lib\\rustlib\\x86_64-pc-windows-msvc\\lib" "C:\\Users\\mtiller\\Source\\rust-fmu\\target\\debug\\deps\\rust_fmu-dd167e2c1e3583f1.0.o" "/OUT:C:\\Users\\mtiller\\Source\\rust-fmu\\target\\debug\\deps\\rust_fmu-dd167e2c1e3583f1.exe" "/OPT:REF,NOICF" "/DEBUG" "/LIBPATH:C:\\Users\\mtiller\\Source\\rust-fmu\\target\\debug\\deps" "/LIBPATH:C:\\Users\\mtiller\\Source\\rust-fmu\\target\\debug\\build\\rust-fmu-e434516f4288772d\\out" "/LIBPATH:C:\\Users\\mtiller\\.rustup\\toolchains\\stable-x86_64-pc-windows-msvc\\lib\\rustlib\\x86_64-pc-windows-msvc\\lib" "logger.lib" "C:\\Users\\mtiller\\Source\\rust-fmu\\target\\debug\\deps\\liblibloading-c41a2f71457b39f3.rlib" "C:\\Users\\mtiller\\Source\\rust-fmu\\target\\debug\\deps\\liblibc-5dc7b85e748840b4.rlib" "C:\\Users\\mtiller\\Source\\rust-fmu\\target\\debug\\deps\\libkernel32-835ed4d4f4dc2d3e.rlib" "C:\\Users\\mtiller\\Source\\rust-fmu\\target\\debug\\deps\\libwinapi-a5898d7aceb63fac.rlib" "C:\\Users\\mtiller\\.rustup\\toolchains\\stable-x86_64-pc-windows-msvc\\lib\\rustlib\\x86_64-pc-windows-msvc\\lib\\libstd-90fbcc8c07b4a644.rlib" "C:\\Users\\mtiller\\.rustup\\toolchains\\stable-x86_64-pc-windows-msvc\\lib\\rustlib\\x86_64-pc-windows-msvc\\lib\\libpanic_unwind-d2e7baf2c0a36eaf.rlib" "C:\\Users\\mtiller\\.rustup\\toolchains\\stable-x86_64-pc-windows-msvc\\lib\\rustlib\\x86_64-pc-windows-msvc\\lib\\libunwind-112baa0117a60076.rlib" "C:\\Users\\mtiller\\.rustup\\toolchains\\stable-x86_64-pc-windows-msvc\\lib\\rustlib\\x86_64-pc-windows-msvc\\lib\\liblibc-ad15457034b2bf37.rlib" "C:\\Users\\mtiller\\.rustup\\toolchains\\stable-x86_64-pc-windows-msvc\\lib\\rustlib\\x86_64-pc-windows-msvc\\lib\\librand-fa1852079e0fefd1.rlib" "C:\\Users\\mtiller\\.rustup\\toolchains\\stable-x86_64-pc-windows-msvc\\lib\\rustlib\\x86_64-pc-windows-msvc\\lib\\libcollections-27e4c8cc19e6faac.rlib" "C:\\Users\\mtiller\\.rustup\\toolchains\\stable-x86_64-pc-windows-msvc\\lib\\rustlib\\x86_64-pc-windows-msvc\\lib\\liballoc-588bb0bd8c9dd8ca.rlib" "C:\\Users\\mtiller\\.rustup\\toolchains\\stable-x86_64-pc-windows-msvc\\lib\\rustlib\\x86_64-pc-windows-msvc\\lib\\liballoc_system-dbfe715efb71d408.rlib" "C:\\Users\\mtiller\\.rustup\\toolchains\\stable-x86_64-pc-windows-msvc\\lib\\rustlib\\x86_64-pc-windows-msvc\\lib\\libstd_unicode-a2e15800b52a7a60.rlib" "C:\\Users\\mtiller\\.rustup\\toolchains\\stable-x86_64-pc-windows-msvc\\lib\\rustlib\\x86_64-pc-windows-msvc\\lib\\libcore-b2880fdfb9b2b596.rlib" "C:\\Users\\mtiller\\.rustup\\toolchains\\stable-x86_64-pc-windows-msvc\\lib\\rustlib\\x86_64-pc-windows-msvc\\lib\\libcompiler_builtins-9d27746f5ba8488f.rlib" "kernel32.lib" "advapi32.lib" "ws2_32.lib" "userenv.lib" "shell32.lib" "msvcrt.lib"
note: logger.lib(logger.o) : error LNK2019: unresolved external symbol __ms_vsnprintf referenced in function vsnprintf
C:\Users\mtiller\Source\rust-fmu\target\debug\deps\rust_fmu-dd167e2c1e3583f1.exe : fatal error LNK1120: 1 unresolved externals
From my research, it seems like this has something to do with some mismatch between MinGW and MinGW64, but when I look at the output of the Rust build, it seems to be using Visual Studio 14.0.
I'm totally confused. I don't quite know how Rust determines which toolchain to use. I used the rustup-init.exe installer which I assumed would "do the right thing", but it seems confused here (or is it just me).
Any suggestions on how to get my toolchain aligned? One other constraint is that I'm using the libloading crate because my program is loading DLLs. I want that part to work as well, but haven't gotten to test that under Windows yet because of build issues.
P.S. - I need the v version of vsnprintf because I'm getting passed varargs and I need a way to actually process them.
My machine had MSVC, MinGW64 and MinGW installed on it. Given the error messages, I fell into the trap of thinking that it was related to rustc invoking the wrong compiler/linker because of issues in my path or its own assumptions about the tools on my machine.
It turns out the build script I was using was calling gcc and ar directly, which invoked the MinGW commands. I thought Rust had "wrappers" for these commands so they behaved the same on all platforms (hence my lack of concern about these).
When I read the documentation on build scripts more closely, I see that they repeat the same (non-portable) approach, but then talk about the lack of cross-platform support for that approach and then show a much simpler and more portable way to do this.
Bottom line, use:
[build-dependencies]
gcc = "0.3"
...and read the build script documentation carefully. Now everything compiles fine on both macOS and Windows.
I'm trying to use the FFMpeg libraries in a Windows application. I use MingW-w64 to compile FFMpeg with static libraries with architecture once with x86 and once with x86_64.
Currently I'm trying to link the 32bit x86 libraries with my VS2008 application.
The libraries are added to the library path and VS does not complain about being unable to load a .a file.
However I get several uneresolved symbol errors like
ait_rtp_receiver.lib(ait_decoder_lib.obj) : error LNK2001: unresolved external symbol _av_free
I import the FFMpeg header files as extern C and I can see the symbols in the .a without the leading underscore.
What can I do to make the name decoration of Mingw-w64's gcc and of the VS compiler suite compatible?
After spending miserable days trying to get the GCC-Mingw based version of building FFMpeg to work, I reverted to using the Visual Studio or Windows SDK compiler and linker. Using the --toolchain=msvc of the configure script made the build process generate static .a files that are basically .lib files that can be loaded within Visual Studio projects.
I wrote the build steps up and here is a link