I am trying to use the latest NVIDIA Video SDK, specifically - its NVDEC (hardware video decoder lib). I had been using the previous version for a while and it was loading function pointers in runtime from libnvcuvid.so, which on my machine is located in:
/usr/lib/nvidia-396/
It contains the folowing related items:
/usr/lib/nvidia-396/libnvcuvid.so
/usr/lib/nvidia-396/libnvcuvid.so.1
/usr/lib/nvidia-396/libnvcuvid.so.396.18
Now,in the latest SDK 8.1,there is no loading of library function pointers in runtime, but all the API methods marked as extern and static linking is used. On Windows they provide nvcuvid.lib. But on linux, the are only above mentioned SOs. My IDE targets that directory (triple checked;if I remove the path,the linker complains that it can't find the lib) correctly, also I put the libnvcuvid.so on the linker exactly the same way as I put cuda.so and cudart.so in the same place for static linking vs CUDA API. But I am still getting
"undefined reference"
for all cuvid functions declared in the latest header. As you can see, my drivers version is also up to date (8.1 requires at least 390).
Why it doesn't link?
UPDATE (linker):
/usr/bin/g++ -o bin/xxxxx_xxx_d #"xxxxx_xxx.txt" -L. -LDebug
-L/usr/lib/nvidia-396 -L/usr/local/cuda-9.1/lib64 -lcuda -lcudart -lnvcuvid .....
Related
[summary]
I can not compile vulkan program including "vkGetAccelerationStructureBuildSizesKHR" or "vkCreateAccelerationStructureKHR" with errors "undefined reference to `vkGetAccelerationStructureBuildSizesKHR'".
[environment]
OS : Ubuntu 20.04
command : clang++ with option -lvulkan
vulkan version : 1.2.170
[what tried]
I guess that it is need more library.
I added "-lvulkan_radeon", but it does not make any change.
For reference, If my program does not include any new feature of ray tracing, I can build it normally.
I read that ray tracing features are officially supported from version 1.2.167, so I expect that I can build it without any additional works, but I can't.
Is there any additional library to be linked?
As with all functions provided by extensions and not being part of the core, you have to manually define and get the function pointers in your application before you can call it:
PFN_vkGetAccelerationStructureBuildSizesKHR pfnGetAccelerationStructureBuildSizesKHR;
pfnGetAccelerationStructureBuildSizesKHR = reinterpret_cast<PFN_vkGetAccelerationStructureBuildSizesKHR>(vkGetDeviceProcAddr(device, "vkGetAccelerationStructureBuildSizesKHR"));
Context: I'm using Qt 5.9.3 on Windows, building for MinGW 32-bit. The Qt part is a side issue though - the problem seems to be with MinGW. The version of MinGW is 4.3.0, supplied prebuilt as part of the Qt installation.
I'm building a library which talks to a USB device over HID. Everything compiles fine, but it fails at the link stage with
./..\..\object\debug\usb_hid_device.o: In function `ZN8MyApp3USB5Win3213getDevicePathB5cxx11Ell':
<MYPATH>/../../source/win32/usb_hid_device.cpp:99: undefined reference to `HidD_GetAttributes(void*, _HIDD_ATTRIBUTES*)#8'
./..\..\object\debug\usb_hid_device.o: In function `ZN8MyApp3USB5Win3214CHIDDeviceImplC2EllRNS_15LogPerComponentE':
<MYPATH>/../../source/win32/usb_hid_device.cpp:200: undefined reference to `HidD_FlushQueue(void*)#4'
The linker command is
g++ -shared -mthreads -Wl,-subsystem,windows -Wl,--out-implib,<MYPATH>\bin\debug\libusb_hid_comms.a -o <MYPATH>\bin\debug\usb_hid_comms.dll object_script.usb_hid_comms.Debug -lhid -lsetupapi -LC:\Qt\Qt5.9.3\5.9.3\mingw53_32\lib C:\Qt\Qt5.9.3\5.9.3\mingw53_32\lib\libQt5Guid.a C:\Qt\Qt5.9.3\5.9.3\mingw53_32\lib\libQt5Cored.a
If I omit -lhid I get the same errors. I also get the same errors if I remove -lhid and explicitly set the path and filename to libhid.a. If I deliberately mistype the path and filename, it comes up with an error, so I know the command-line is getting parsed correctly. But for whatever reason, MinGW appears to not be linking with one of its own library files.
I've also tried removing -lsetupapi and I get the linker errors I'd expect for the functions defined in there. Likewise the Qt library files. But it seems that specifically for libhid.a, MinGW can see the library file but just isn't going to link with it.
Has anyone else seen this? Or can anyone else with the same (or similar) version of MinGW confirm or deny that they can link with libhid.a? Or is there something obviously wrong with what I'm doing?
I've just found the answer. I'm posting an answer myself so that other people know in future, because I think this is still a valid question which people might want to know about.
The problem is the include file hidsdi.h. The majority of other header files which pull in Win32 API calls have extern "C" around the function declarations. However this one doesn't! The result is that we end up with C++ name mangling for linker symbols, instead of the C-style "_" in front of the linker symbols.
The solution is to use
extern "C"
{
#include <hidsdi.h>
}
and then everything works fine.
The version of hidsdi.h with the older version of MinGW (which I'm porting from) did have that protection around the function declarations. However it looks like it's gone in the newer version.
Context:
cygwin-gcc as my terminal and compiler
Trying to use OpenGL for my program and it requires GLEW extension to make it work. I chose to dynamically link my program to the required libraries.
Downloaded, make installe'd, the glew libraries and header files.
Put .dll files in usr/local/lib folder including the opengl32.dll which is originally from the system32 folder to test but still not working.
Put header files in /usr/local/include folder
Problem:
Getting underfined references to functions.
Input Command:
gcc -o TestGameBoy TestGameBoy.c -I/usr/local/include/GL -L/usr/local/lib -lglew32 -lglu32 -lopengl32
Edit: -opengl32 changed to -lopengl32 but just a typo.
Linking output error:
/tmp/cc0Qp34q.o: In function `initWindowComponents':
/cygdrive/d/DMG_Emulator/BGWindow.c:35: undefined reference to `glewExperimental'
/cygdrive/d/DMG_Emulator/BGWindow.c:36: undefined reference to `glewInit'
/cygdrive/d/DMG_Emulator/BGWindow.c:48: undefined reference to `glGenTextures'
/cygdrive/d/DMG_Emulator/BGWindow.c:50: undefined reference to `glBindTexture'
/cygdrive/d/DMG_Emulator/BGWindow.c:54: undefined reference to `glTexImage2D'
collect2: error: ld returned 1 exit status
Note: I didnt included the SDL part since it is already working. I managed to follow its argument list but somehow not working for glew.
Id like to believe that this is because the linker doesn't actually load the library into the ram. Soo it is unable to fill those necessary data for assembly calls to function's memory space which needs a defined memory address? I dont know Im mostly theorizing myself after I watch a video probably realted to my problem. But this does makes sense for me though somehow I couldnt make it work.
Never(!!!) touch anything that resides in system32 or SysWow64! These are operating system resources and messing around with those will cause a lot of headache in the long run.
As for using (modern) OpenGL with Cygwin… that's kind of a PITA. You have this XWin/GLX wrapper sitting in between, so that programs written for X11 can be run inside the Cygwin X11 server. This in turn means that inside Cygwin you're dealing with *nix-ish OpenGL library names, i.e. -lGL -lGLX -l… (probably expects X libraries as well). Which also means that you can not talk directly to the native OpenGL implementation in a pure Cygwin environment.
There's (might be) an error in your linker invocation. It's generally -l… yet you have -opengl32 there (dropped the l). However the linker should complain about every miswritten option or libraries specified, but it can not find.
I strongly suggest using MinGW/MSys2 instead of Cygwin which gives you truly native Windows API environment and makes things lots of easier. MSys2 uses the Pacman package manager (of Arch Linux) and is an all around pleasant to work with environment. It gives you all the *nix-ish dev tools (GCC / Clang, Shells, etc.) yet is native Win32.
opengl32.dll is a shared lib, but not the import lib needed by the compiler. opengl32.dll also does not match the expected the shared library name in cygwin that is cyg*.dll
Install cygwin libGLEW-devel package. It will provide the correct GLEW import lib and the headers
The content is listed on
https://cygwin.com/packages/x86_64/libGLEW-devel/libGLEW-devel-1.13.0-1
2016-07-21 22:36 1018809 usr/include/GL/glew.h
2016-07-21 22:36 73140 usr/include/GL/glxew.h
2016-07-21 22:36 0 usr/lib/
2016-07-21 22:36 2106644 usr/lib/libGLEW.dll.a
2016-07-21 22:36 1667262 usr/lib/libGLEWmx.dll.a
2016-07-21 22:36 0 usr/lib/pkgconfig/
2016-07-21 22:36 222 usr/lib/pkgconfig/glew.pc
2016-07-21 22:36 233 usr/lib/pkgconfig/glewmx.pc
There is also a glew package OpenGL Extension Wrangler demos that you can use to test the proper installation.
I am new to OpenCL. Working on a Core i5 machine with Intel(R) HD Graphics 4000, running Windows 7. I installed the newest Intel driver with support for OpenCL. GpuCapsViewer confirms I have OpenCL support setup. I Developed a simple HelloWorld program using Intel OpenCL SDK. I successfully compile the program but when run, it crashes upon call to clGetPlatformIDs() with a segmentation fault. This is my code:
#include <iostream>
#include <CL/opencl.h>
int main() {
std::cout << "Test OCL without driver" << std::endl;
cl_int err;
cl_uint num_platforms;
err = clGetPlatformIDs(0, NULL, &num_platforms);
if (err == CL_SUCCESS) {
std::cout << "Success. Platforms available: " << num_platforms
<< std::endl;
} else {
std::cout << "Error. Platforms available: " << num_platforms
<< std::endl;
}
std::cout << "Test OCL without driver" << std::endl;
std::cout << "Press button to exit." << std::endl;
std::cin.get();
return 0;
}
How can it be that GpuCapsViewer successfully confirms OpenCL support and can use it to run its demos, but I can't run my code? Both must be using the same functions, right?
Been working on this for days. Even tried re installing the drivers. Any Ideas?
GpuCapsViewer says:
DRIVER: R295.93 (r295_00-233) / 10.18.10.3496 (3-11-2014)
OPENGL: OpenGL 4.2 (GeForce GT 630M/PCIe/SSE2 with 290 ext.)
OPENCL: OpenCL 1.1, GeForce GT 630M compute units:2#950MHz
CUDA: GeForce GT 630M CC:2.1, multiprocessors:2#950MHz
PHYSX: GPU PhysX (NVIDIA GeForce GT 630M)
MULTI-GPU: no multi-GPU support (2 physical GPUs)
UPDATE:
Compilation line:
g++ -I"C:\Program Files (x86)\Intel\OpenCL SDK\4.4\include" -O0 -g3 -Wall -c -fmessage-length=0 -MMD -MP -MF"Test3.d" -MT"Test3.d" -o "Test3.o" "../Test3.cpp"
Finished building: ../Test3.cpp
Linker line:
g++ -L"C:\Program Files (x86)\Intel\OpenCL SDK\4.4\lib\x64" -o "TestOpenCL" ./HelloWorld.o ./HelloWorld2.o ./Test3.o -lOpenCL
Finished building target: TestOpenCL
OS: Windows 7 Ultimate Version 6.1 (Build 7601: Service Pack 1)
UPDATE 2, Crash Information:
Problem Event Name: APPCRASH
Application Name: TestOpenCL.exe
Application Version: 0.0.0.0
Application Timestamp: 53bc6ac5
Fault Module Name: TestOpenCL.exe
Fault Module Version: 0.0.0.0
Fault Module Timestamp: 53bc6ac5
Exception Code: c0000005
Exception Offset: 0000000000002cc0
OS Version: 6.1.7601.2.1.0.256.1
Locale ID: 1033
Additional Information 1: 56e3
Additional Information 2: 56e3743a8a234df3bdeba0b507471c44
Additional Information 3: 8fe0
Additional Information 4: 8fe0ef5706153941955de850e5612393
UPDATE 3:
Used DependencyWalker(http://dependencywalker.com/) as a substitute for dumpbin. It generates the following warnings:
Warning: At least one delay-load dependency module was not found.
Warning: At least one module has an unresolved import due to a missing export function in a delay-load dependent module.
The warnings seem to refer to the following DLLs which are all marked with a "Error opening file. The system can not find the file specified(2)" error message.
API-MS-WIN-CORE-COM-L1-1-0.DLL
API-MS-WIN-CORE-WINRT-ERROR-L1-1-0.DLL
API-MS-WIN-CORE-WINRT-L1-1-0.DLL
API-MS-WIN-CORE-WINRT-ROBUFFER-L1-1-0.DLL
API-MS-WIN-CORE-WINRT-STRING-L1-1-0.DLL
API-MS-WIN-SHCORE-SCALING-L1-1-0.DLL
DCOMP.DLL
IESHIMS.DLL
UPDATE 4, GDB BACKTRACE:
Program received signal SIGSEGV, Segmentation fault.
0x0000000000402cc0 in clGetPlatformIDs ()
(gdb) backtrace full
#0 0x0000000000402cc0 in clGetPlatformIDs ()
No symbol table info available.
#1 0x0000000000402af3 in main () at ../Test3.cpp:11
err = 0
num_platforms = 0
platform = 0x0
(gdb) backtrace
#0 0x0000000000402cc0 in clGetPlatformIDs ()
#1 0x0000000000402af3 in main () at ../Test3.cpp:11
UPDATE 5, GDB DISASS:
(gdb) disass
Dump of assembler code for function clGetPlatformIDs:
=> 0x0000000000402cc0 <+0>: jmpq *0x4b74e8(%rip) # 0x8ba1ae
0x0000000000402cc6 <+6>: nop
0x0000000000402cc7 <+7>: nop
End of assembler dump.
UPDATE 6, GDB INFO SHARED:
(gdb) INFO SHARED
From To Syms Read Shared Object Library
0x0000000077191000 0x00000000773384e0 Yes (*) C:\Windows\system32\ntdll.dll
0x0000000077071000 0x000000007718eab4 Yes (*) C:\Windows\system32\kernel32.dll
0x000007fefc081000 0x000007fefc0eb13c Yes (*) C:\Windows\system32\KernelBase.dll
0x000007fedf8d1000 0x000007fedf8e96aa Yes (*) C:\Windows\system32\OpenCL.dll
0x000007fefe101000 0x000007fefe1da628 Yes (*) C:\Windows\system32\advapi32.dll
0x000007fefe061000 0x000007fefe0fe4bc Yes (*) C:\Windows\system32\msvcrt.dll
0x000007fefdcc1000 0x000007fefdcde39a Yes (*) C:\Windows\SYSTEM32\sechost.dll
0x000007fefc6a1000 0x000007fefc7cc914 Yes (*) C:\Windows\system32\rpcrt4.dll
(*): Shared library is missing debugging information.
Binary file, x64 and include folders:
https://drive.google.com/file/d/0BxKA63T2GnKMRW02QWZnam5lSGM/edit?usp=sharing
UPDATE 7, GPUcaps situation:
GPUcaps detects 2 GPUs:
GPU 1: Intel(R) HD Graphics 4000
GPU 2: NVIDIA GeForce GT 630M
You can see the screenshot here:
https://drive.google.com/file/d/0BxKA63T2GnKMa00tU1gydGNJeXc/edit?usp=sharing
UPDATE 8:
Per #antiduh 's answer, I have been trying to link directly against OpenCL.dll present in Windows\System32 folder. I am using mingw64. I get this:
Invoking: Cross G++ Linker
g++ -L"C:\Windows\System32" -o "TestOpenCL" ./HelloWorld.o ./HelloWorld2.o ./Test3.o -lOpenCL
d:/ws/apps_inst/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/4.7.1/../../../../x86_64-w64-mingw32/bin/ld.exe: skipping incompatible C:\Windows\System32/OpenCL.dll when searching for -lOpenCL
d:/ws/apps_inst/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/4.7.1/../../../../x86_64-w64-mingw32/bin/ld.exe: skipping incompatible C:\Windows\System32/OpenCL.dll when searching for -lOpenCL
d:/ws/apps_inst/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/4.7.1/../../../../x86_64-w64-mingw32/bin/ld.exe: cannot find -lOpenCL
d:/ws/apps_inst/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/4.7.1/../../../../x86_64-w64-mingw32/bin/ld.exe: skipping incompatible C:\Windows\System32/msvcrt.dll when searching for -lmsvcrt
d:/ws/apps_inst/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/4.7.1/../../../../x86_64-w64-mingw32/bin/ld.exe: skipping incompatible C:\Windows\System32/advapi32.dll when searching for -ladvapi32
d:/ws/apps_inst/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/4.7.1/../../../../x86_64-w64-mingw32/bin/ld.exe: skipping incompatible C:\Windows\System32/shell32.dll when searching for -lshell32
d:/ws/apps_inst/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/4.7.1/../../../../x86_64-w64-mingw32/bin/ld.exe: skipping incompatible C:\Windows\System32/user32.dll when searching for -luser32
d:/ws/apps_inst/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/4.7.1/../../../../x86_64-w64-mingw32/bin/ld.exe: skipping incompatible C:\Windows\System32/kernel32.dll when searching for -lkernel32
d:/ws/apps_inst/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/4.7.1/../../../../x86_64-w64-mingw32/bin/ld.exe: skipping incompatible C:\Windows\System32/msvcrt.dll when searching for -lmsvcrt
UPDATE 9:
I can now compile, link and run the sample code manually with the following line.
g++ -I. s.cpp -L. -lOpenCL
I simplified everything and it just worked. This is obviously very different from the compile and link commands used by Eclipse. Any idea which of the parameters used by eclipse cause the problem? And also, why is it that eclipse first compiles to object files and then attempts to link them, in two separate steps?
There are three total ways for a program to use external library:
Static linkage: Directly insert the library into your executable. The external library, presented as a .lib file, contains nothing but packaged .obj files. Your program invokes functions from the library as normal. The compiler extracts executable code from the lib, inserts it, and performs full, complete linkage against it. It is as if you compiled against the imported functions like they were from your own source code.
Load-time dynamic linkage, aka 'implicit linking': Load the library when you launch the program. The external library, presented as a .dll containing executable code, and a .lib file containing the exports from the .dll, is tentatively linked against by the compiler and linker. The linker uses the .lib to understand how to call the .dll at run-time, and to put in deferred bindings into your program. When the OS launches your program, it performs 'load-time' linking - it looks up all of the deferred bindings, attempts to find a .dll file, finishes the linkage of the deferred bindings in your program, and allows you to run the file.
"Pure" run-time dynamic linkage, aka 'explicit linking': Directly calling LoadLibrary. Your program has no specific references to any .lib, .dll, or otherwise. Your program starts running, itself calls LoadLibrary with a string path to a .dll. LoadLibrary merges the .dll into your virtual memory, and then your program calls GetProcAddress to get a function pointer to the function you want to call. You then use that function pointer to make calls.
You can't normally link against a dll without the .lib. The compiler wants to resolve those function call references to real addresses, but we don't want to put in real addresses since we want DLLs to be loaded into any arbitrary memory address (DLLs are 'relocatable').
From my understanding, a .lib used as an import library contains stubs that the main program links directly against - so all calls in the program go through the stubs. The stubs then have references to an 'Import Address Table". When the OS loads a DLL into memory for a process, it does so by filling out the IAT. The stub then just calls the DLL by making an indirect jump that references the right slot in the IAT.
So if a DLL MathLib has an exported function Factorial that my exe is importing, then the import .lib file has an actual function Factorial that my exe statically compiles against. That Factorial in that .lib looks like the following psuedo code:
int Factorial( int value ) {
// Read MathLib's IAT which should always be at address 0x8ba100.
// Factorial's real address gets stored in slot 2, so add 8 to the address
// to read from.
__asm jmp *0x8ba108; // nb this is an indirect jump.
}
And then we hope that when the OS loads that DLL, that IAT is filled out correctly, else we jump into nothingness.
So I think what happened is that you were compiling against one .lib, but 'load-time' linking against the wrong opencl.dll. The IAT was never created, or was created in the wrong place, and so you jumped into nothingness; that's why this line created a segfault:
0x0000000000402cc0 <+0>: jmpq *0x4b74e8(%rip) # 0x8ba1ae
So lets figure out why we linked wrong. There could be 3 sets of opencl.dll/opencl.lib files on your computer:
The opencl.lib/dll that comes from Kronos, and is actually just a stub/loader library that figures out what real providers are on your computer and does dispatches function calls to the actual right lib.
The opencl.lib/dll that comes from Intel from their SDK and drivers.
The opencl.lib/dll that comes from Nvidia from their drivers.
Which of these files did you actually have? My estimate is thus:
The opencl.dll that came from kronos got installed into c:\windows\system32.
There is no opencl.lib from Kronos
There was probably no opencl.lib from nvidia, since you didn't have their SDK installed.
You probably had an opencl.lib and opencl.dll from Intel since you did have their SDK installed.
You were definitely linking against the Intel opencl.lib, but appeared to be loading the Kronos opencl.dll in c:\windows\system32. One solution would be to get the program to load the Intel opencl.dll when you run the program by putting their dll in your program's directory.
However, you state that you were able to make things work using this compilation line:
g++ -I. s.cpp -L. -lOpenCL
There's something neat about gcc on Windows - in order to link against a library, you don't need to have the .lib. Gcc figures it out for you by inspecting the dll; other people have figured out how to do the same when someone gives them a dll but no lib. In most other compilers, especially Visual Studio, you need to have a .lib and a .dll to link against something. That's why the Win SDK installs hundreds of .lib (kernel32.lib, eg). Turns out that the compiler can actually infer it if it wanted to, but libs exist as an archaic mechanism.
Anyway, you ran that above gcc link line, it found a suitable opencl.dll using the search path, invented its own .lib for it, and compiled against it; you launched your program, it used that same search path to get an opencl.dll, it was the same one you compiled against, so your program runs. Whew.
I still have some suggestions:
Find an opencl.lib and opencl.dll pair that come from Kronos's "Installable Client Driver" ICD Loader. That loader will then figure out how to bind to a particular provider (nvidia, intel, etc) at runtime.
Distribute the Kronos opencl.dll with your application so that you will never accidentally run-time-link against the wrong file.
Uninstall the Intel SDK, assuming it's providing opencl.lib/opencl.dll files that are specific to Intel.
Some more relevant questions on libs and dlls:
When building a DLL file, does the generated LIB file contain the DLL name?
Why are LIB files beasts of such a duplicitous nature?
I'm trying to create a program that uses some of the code from WebKit/GTK+. Specifically, I want to load a string, use WebKit's parser to construct a DOM tree and then iterate over that tree.
I'm trying to use a class called HTMLDocument. WebKit/GTK+ doesn't expose this as part of its API and I'm running into some trouble linking against it.
I'm able to build WebKit/GTK+ normally, which gives me a file called: libwebkit-1.0.so. My program is:
#include <iostream>
#include <WebCore/config.h>
#include <WebCore/html/HTMLDocument.h>
using namespace WebCore;
int main() {
String title = "test";
RefPtr<HTMLDocument> d = HTMLDocument::create(0);
d->open();
d->write("<!doctype html><html><head><title>" + title + "</title></head><body></body></html>");
}
This compiles fine (I'm using the same include directives used by webkit to build), but results in linking errors.
...test_doc.cpp:18: undefined reference to `WebCore::String::String(char const*)'
...test_doc.cpp:21: undefined reference to WebCore::Document::open(WebCore::Document*)'
...(similar for every function I use)
If I run:
nm -C .libs/libwebkit-1.0.so | grep 'WebCore::Document::open'
I see:
003b1830 T WebCore::Document::open(WebCore::Document*)
which seems to indicate that the function is available. I have a reasonable amount of C++ experience, but not much experience with linking files under Linux.
I'm not expecting this exact problem to be solved, but I'm hoping someone can correct me if I have conceptual problems. My main question is why I see "undefined reference" errors when I'm linking with an .so file that lists that function as being defined. Is another file or build step needed?
Thank you very much.
Using:
Ubuntu 9.10
g++ 4.4.1
g++ is invoked with:
g++ --debug -DHAVE_CONFIG_H -I. `pkg-config --cflags libsoup-2.4` \
-DBUILDING_CAIRO__=1 -DBUILDING_GTK__=1 -DWTF_CHANGES -DWTF_USE_ICU_UNICODE=1 \
-DNDEBUG -I./WebCore -I./WebCore/accessibility -I./WebCore/bindings/js \
-I./WebCore/bridge -I./WebCore/bridge/c -I./WebCore/css -I./WebCore/dom \
...many more webkit include directories...
-DDATA_DIR=\"/usr/local/share\" \
test_doc.cpp -o test_doc.out \
./webkit-1.1.15.3/.libs/libwebkit-1.0.so
(I get the same result with -L/path/to/lib -lwebkit-1.0)
I think you might be running into an ordering problem: man g++ specifies that the order of the -l option is significant, and from memory the linker will only look for symbols in objects which have preceeded the current file on the command line.
I suspect what is happening is that the linker is trying to link test_doc before it's seen libwebkit-1.0.so, so it hasn't seen any of those symbols yet and bails.
You should use the -L/path/to/web and -lwebkit-1.0.
Also, I would compile your .cpp file in to a .o and then build your executable separately to make sure things are isolated.
Anyway, you may need to set your $LD_LIBRARY_PATH environment variable to include the path where that .so is stored. If you link to a shared library, you will need that library at run-time. Therefore, you do not want to have your webkit SO stored in its build directory (build/.libs). You want to install it. If you are not root, then you should ./configure with a --prefix=/some/path to install it to some local directory. Alternatively, you can link against the static library. One way to do this is to use the -bstatic (or similar) flag before your -lwebkit-1.0.
This is a good resource for Linux library creation and use.
I think you're issue is that the symbols you need are not exported. You can do objdump --dynamic-syms libwebkit-1.0.so to see which symbols are available. In the WebKit GTK build files there is use of the -fvisibility=hidden flag to restrict the symbols. Check your generated GNUMakefile and you'll see SYMBOL_VISIBILITY = -fvisibility=hidden. You should be able to modify the build files to get what you need.