How to solve linking pdfium on windows 10 - windows

I have the main.cpp on Windows at C:\repo\pdfium\out\debug\obj\test directory. Pdfium.lib is at obj directory.
#include <stdio.h>
#include <fpdfview.h>
int main() {
FPDF_InitLibrary();
FPDF_DestroyLibrary();
printf("PDFium hello.\n");
return 0;}
pdfium.lib is build with GCC(is_lang=false)
With command i am producing main.o
g++.exe -std=c++11 -g -I........\public -c
C:\repo\pdfium\out\debug\obj\test\main.cpp -o obj\Debug\main.o
With command bellow i am trying to link pdfium.lib
g++.exe -o bin\Debug\test.exe obj\Debug\main.o ..\pdfium.lib
But i am taking ...
Warning: corrupt .drectve at end of def file
..\pdfium.lib(obj/core/fpdfapi/parser/parser/fpdf_parser_utility.obj):(.xdata[$unwind$?_Makestr#_System_error#std##CA?AV?$basic_string#DU?$char_traits#D#std##V?$allocator#D#2##2#Verror_code#2#V32##Z]+0x8): undefined reference to `__GSHandlerCheck'
I have try so many time but nothing on linking on windows 10.
Any advice will be redemptive.
Thank you
Jim

If you're building PDFium with a non-component build (is_component_build = false in args.gn) and not setting pdf_is_complete_lib = true, the generated .lib files won't have their dependencies included, so you're quite likely to have the linker complain about missing symbols. Try either generating DLLs (is_component_build = true) or setting pdf_is_complete_lib = true.
If you use a component build, you'll need to package the PDFium DLL and its dependencies (at least the zlib DLL, possibly others) with your application.

Related

Include error when trying to include <wuapi.h>

Recently I tried to create tool using Windows Update Agent API in C++.
The problem is, even include of the wuapi.h header file causes problems on my machine.
It keeps saying, the header file could not be found.
#include <wuapi.h>
int main(int argc, char **args)
{
return 0;
}
Attempt to compile the simple code ends up predictably:
gcc -o tool.exe file.cpp -pedantic -Wall -Wextra
file.cpp:1:10: fatal error: wuapi.h: No such file or directory
#include <wuapi.h>
^~~~~~~~~
compilation terminated.
I found almost no information related to this issue on the Internet so far. That means I'm not sure what's wrong at all.
I'm using Windows 10.0.18362.592 but more importantly I'm using mingw-w64 8.1.0 as a compiler.
At this point I'm not sure, whether mingw-w64 supports this part of Win32 API. I found no useful information though.

'undefined symbol: __stack_chk_guard' in libopenh264.so when building FFmpeg with emcc

I am trying to build codecbox.js on Ubuntu 18.04, which involves building FFmpeg with emcc.
At some stage of the build process, FFmpeg's configure script tries to process the following code:
#include <wels/codec_api.h>
#include <stdint.h>
long check_WelsGetCodecVersion(void) { return (long) WelsGetCodecVersion; }
int main(void) {
int ret = 0;
ret |= ((intptr_t)check_WelsGetCodecVersion) & 0xFFFF;
return ret;
}
and I get a linker error:
wasm-ld: error: /.../codecbox.js/build/dist/lib/libopenh264.so: undefined symbol: __stack_chk_guard
It seems to be related to Stack Smashing Protector compiler feature. I tried to inspect my libopenh264.so file with nm but nm tells me File format not recognized. However, using grep, I found out that there was a __stack_chk_guard symbol in this file.
I tried to rebuild libopenh264 by adding -fno-stack-protector and -U_FORTIFY_SOURCE to the CFLAGS and the LDFLAGS but that did not change anything:
grep __stack_chk_guard libopenh264.so
still answers
Binary file libopenh264.so matches
I then tried to build the piece of code shown above by adding the same options -fno-stack-protector and -U_FORTIFY_SOURCE to emcc, but it did not change anything either.
Any idea how to get rid off the problem?
I had not rebuilt libopenh264 completely.
Adding -fno-stack-protector and -U_FORTIFY_SOURCE to the CFLAGS, the CXXFLAGS and the LDFLAGS then doing make clean and make solved the problem: libopenh264.so no longer embedded symbol __stack_chk_guard.

Versionhelpers.h: No such file or directory

I'm trying to identify Windows version using IsWindows10OrGreater() and other related functions.
C++, Windows 7 Home Basic, Visual Studio Code v1.36.1, VSCode Extensions - C/C++ for Visual Studio Code, MinGW g++ v8.2.0
Compilation command:
g++ -std=c++11 main.cpp -o file.exe -s -lws2_32 -Wno-write-strings -fno-exceptions -fmerge-all-constants -fpermissive -static-libstdc++ -static-libgcc
I included the version helper header using #include <Versionhelpers.h>, but IntelliSense doesn't recognize it and the build also fails with the error:
fatal error: Versionhelpers.h: No such file or directory
#include <Versionhelpers.h>
I tried including the header in a fresh file and building it, but that didn't work either.
#include <Versionhelpers.h>
int main() {
IsWindowsServer();
return 1;
}
Is there any extension that I need to install in VSCode to get this to work? Or perhaps download the header file (and put it where?)

gcc undefined reference to with pthread [duplicate]

I picked up the following demo off the web from https://computing.llnl.gov/tutorials/pthreads/
#include <pthread.h>
#include <stdio.h>
#define NUM_THREADS 5
void *PrintHello(void *threadid)
{
long tid;
tid = (long)threadid;
printf("Hello World! It's me, thread #%ld!\n", tid);
pthread_exit(NULL);
}
int main (int argc, char *argv[])
{
pthread_t threads[NUM_THREADS];
int rc;
long t;
for(t=0; t<NUM_THREADS; t++){
printf("In main: creating thread %ld\n", t);
rc = pthread_create(&threads[t], NULL, PrintHello, (void *)t);
if (rc){
printf("ERROR; return code from pthread_create() is %d\n", rc);
exit(-1);
}
}
pthread_exit(NULL);
}
But when I compile it on my machine (running Ubuntu Linux 9.04) I get the following error:
corey#ubuntu:~/demo$ gcc -o term term.c
term.c: In function ‘main’:
term.c:23: warning: incompatible implicit declaration of built-in function ‘exit’
/tmp/cc8BMzwx.o: In function `main':
term.c:(.text+0x82): undefined reference to `pthread_create'
collect2: ld returned 1 exit status
This doesn't make any sense to me, because the header includes pthread.h, which should have the pthread_create function. Any ideas what's going wrong?
For Linux the correct command is:
gcc -pthread -o term term.c
In general, libraries should follow sources and objects on command line, and -lpthread is not an "option", it's a library specification. On a system with only libpthread.a installed,
gcc -lpthread ...
will fail to link.
Read this or this detailed explanation.
For Linux the correct command is:
gcc -o term term.c -lpthread
you have to put -lpthread just after the compile command,this command will tell to the compiler to execute program with pthread.h library.
gcc -l links with a library file.Link -l with library name without the lib prefix.
in eclipse
properties->c/c++Build->setting->GCC C++ linker->libraries in top part add "pthread"
Running from the Linux terminal, what worked for me was compiling using the following command (suppose the c file I want to compile is called test.c):
gcc -o test test.c -pthread
Hope it helps somebody!
If you are using cmake, you can use:
add_compile_options(-pthread)
Or
SET(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -pthread")
I believe the proper way of adding pthread in CMake is with the following
find_package (Threads REQUIRED)
target_link_libraries(helloworld
${CMAKE_THREAD_LIBS_INIT}
)
Acutally, it gives several examples of compile commands used for pthreads codes are listed in the table below, if you continue reading the following tutorial:
https://computing.llnl.gov/tutorials/pthreads/#Compiling
Compile it like this : gcc demo.c -o demo -pthread
In Visual Studio 2019 specify -pthread in the property pages for the project under:
Linker -> Command Line -> Additional Options
Type in -pthread in the textbox.
You need to use the option -lpthread with gcc.
you need only Add "pthread" in proprieties=>C/C++ build=>GCC C++ Linker=>Libraries=> top part "Libraries(-l)".
thats it
check man page and you will get.
Compile and link with -pthread.
SYNOPSIS
#include <pthread.h>
int pthread_create(pthread_t *thread, const pthread_attr_t *attr,
void *(*start_routine) (void *), void *arg);
Compile and link with -pthread.
....
Since none of the answers exactly covered my need (using MSVS Code), I add here my experience with this IDE and CMAKE build tools too.
Step 1: Make sure in your .cpp, (or .hpp if needed) you have included:
#include <functional>
Step 2 For MSVSCode IDE users:
Add this line to your c_cpp_properties.json file:
"compilerArgs": ["-pthread"],
Step 2 For CMAKE build tools users:
Add this line to your CMakeLists.txt
set(CMAKE_CXX_FLAGS "-pthread")
Note: Adding flag -lpthread (instead of -pthread) results in failed linking.
From man gcc,
-pthread
Define additional macros required for using the POSIX threads library.
You should use this option consistently for both compilation and linking.
This option is supported on GNU/Linux targets,
most other Unix derivatives,
and also on x86 Cygwin and MinGW targets.
It is correct that -pthread is an option and the best way to handle this.
There are statements in some answers that it generates different compiled code. This is misleading.
If you wish to duplicate -pthread, you could use -lpthread -D_REENTRANT=1. So there are two things going on with the -pthread option.
Indeed it links with the pthread library as many answers express. Also, the order of the pthread library is important because it may override some weak symbols. So a correct version using -lpthread may need to have it multiple times on the command line.
The other important part is the _REENTRANT define. Note, that this is in the implementation namespace. Some people may care for portability and other not. However, it is very important that it is defined as the first thing in the compilation unit. This symbol will alter the way that many system headers files are parsed.
You can include #define _REENTRANT 1 at the top of every source file, but it is much easier to have it on the command line. Again, the -pthread is the best way to achieve this. Also, gcc may change the way this is implemented in the future. However, I think it is important for programmers to understand what is going on.
term.c: In function ‘main’: term.c:23: warning: incompatible implicit
declaration of built-in function ‘exit’
You never included <stdlib.h>, where exit() is declared. Also, I think newer versions of gcc have removed the need for _REENTRANT.
Why features.h?
Example on godbolt, without -pthread.
So, it is NOT generating different code. Ie, the backend of the compiler is NOT different. It is only conditional compilation and linking to different libraries. It does not generate 'lock free' code or add appropriate machine barriers because you have used this option.
In Anjuta, go to the Build menu, then Configure Project.
In the Configure Options box, add:
LDFLAGS='-lpthread'
Hope it'll help somebody too...
Sometimes, if you use multiple library, check the library dependency.
(e.g. -lpthread -lSDL... <==> ... -lSDL -lpthread)

Clang on WIndows finds VC headers instead of GCC

When I had Clang 3.7 installed it would find the STL headers from my GCC installation as long as only both those two directories in the path.
Now that I have installed Clang 3.8 the compiler keeps finding the Visual Studio headers despite the fact that it isn't even in the path
My path is as follows:
PATH=whatever;G:\Compilers\LLVM\bin;g:\compilers\Mingw64-64bit\bin
Edit 1
I've know idea what the correct include paths, but I tried a compilation in Codelite which found these:
"-IG:\\Compilers\\Mingw64-64bit\\x86_64-w64-mingw32\\include\\c++"
"-IG:\\Compilers\\Mingw64-64bit\\x86_64-w64-mingw32\\include\\c++\\x86_64-w64-mingw32"
"-IG:\\Compilers\\Mingw64-64bit\\lib\\gcc\\x86_64-w64-mingw32\\5.1.0\\include"
"-IG:\\Compilers\\Mingw64-64bit\\lib\\gcc\\x86_64-w64-mingw32\\5.1.0\\include-fixed" "-IG:\\Compilers\\Mingw64-64bit\\x86_64-w64-mingw32\\include"
"-IG:\\Compilers\\Mingw64-64bit\\x86_64-w64-mingw32\\include\\c++\\backward"
I'm also using the dialect flag --std=c++11
However a very simple program using the C++ library is giving me errors such as
G:\Compilers\Mingw64-64bit\x86_64-w64-mingw32\include\c++\bits/stringfwd.h:63:33: error: use of undeclared identifier 'char16_t'
template<> struct char_traits<char16_t>;
^
Edit 2
Now passing x86_64-w64-mingw32 as recommended by Martin, the autodiscovery process seems to work, however the produced executable just freezes.
I found the same when I tried to use the VS2015 Clang toolset
The code example I am using is this
#include <iostream>
int main()
{
int arr[] = {1, 2, 3, 4, 5};
for(auto el : arr)
{
std::cout << el << std::endl;
}
return 0;
}
I am now compiling with:
clang++ -v --target=x86_64-w64-mingw32 hello.cpp -o test.exe -std=c++14
I have looked at the executable produced with Dependency Walker and it is showing as a 64 bit compile and linking to "g:\Compilers\Mingw64-32Bit\bin\libstdc++-6.dll"
I think the next step would be to try compiling a 32 bit version, but I cannot seem to find the correct target name for that
I have just tried clang++ hello.cpp -o main.exe -std=c++14 --target=i686-pc-mingw32 -v
That seems to be producing a 32 bit executable, but again it just freezes
Note I updated the path to point to the 32 bit clang.
Edit 3
What I find confusing is that until I passed x86_64-w64-mingw32 as the target I got very similar errors both from passing the GCC paths, and from the default target of MSVC where both seemed to be related to char16_t and similar types
Seeing this I thought I would try if passing a target might fix the VC compiler errors
Whilst that sort of seems to work it just creates more problems, because it keeps asking for libs to link to and I don't know the correct ones
So I tried:
clang++ hello.cpp -o main-vc.exe -std=c++14 --target=x86_64-pc-windows-msvc19.0.0 -v
-Xlinker "c:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\lib\amd64\libcmt.lib"
"C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\lib\amd64\libcpmt.lib"
"C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\lib\amd64\libvcruntime.lib"
"C:\Program Files (x86)\Windows Kits\10\Lib\10.0.10586.0\ucrt\x64\libucrt.lib"
I have no idea what were the correct directories to pass.
I have a feeling that I need to pass another lib file as I am getting this error
libcmt.lib(thread_safe_statics.obj) : error LNK2019: unresolved external symbol __imp_CloseHandle
Did you change the target? VC is the new default. Use this (example) for x64, mingw:
clang++ --target=x86_64-w64-mingw32 test.cpp
Don't forget the linker as wel.

Resources