Re: Working with PDFlib; and slamming the wall - XCode 2.1 doesn't link static library.
Re: Working with PDFlib; and slamming the wall - XCode 2.1 doesn't link static library.
- Subject: Re: Working with PDFlib; and slamming the wall - XCode 2.1 doesn't link static library.
- From: "Frederick C. Lee" <email@hidden>
- Date: Fri, 22 Jul 2005 11:53:53 -0700
Thank you, Damien & Patrick, for your quick responses.
It appears that the static library 'libpdf.a' is NOT being linked
into the project output,
even though I have added the search paths of both header and library
in the Build Configurations (Default & Debug).
So the obvious question is:
1) Why doesn't the library show up in the build if I had listed the
search path in the build phase (info dialog)?
- Perhaps the library isn't DIRECTLY called within the source code?
See below.
Regards,
Ric.
On Jul 22, 2005, at 4:15 AM, Damien Bobillot wrote:
Le 22 juil. 05 à 01:31, Frederick C. Lee a écrit :
Greetings:
I've downloaded pdflib verson 6.0.1 from pdflib.com. What I
got was some demo and doc files. I'm assuming the libpdf.a
library is installed somewhere globally.
Nevertheless, I've created a test (testC++) routine via XCode 2.1
containing the 'hello.cpp' and 'hello.hpp' source with links to
the pdflib.cpp, pdflib.hpp and pdflib.h
The following error was encountered during the link part of the
build:
[Session started at 2005-07-21 16:20:43 -0700.]
ZeroLink: unknown symbol '_PDF_get_api'
testC++ has exited due to signal 6 (SIGABRT).
1) How do I solve this? and
Did you add the static library libpdf.a to your projet ? It should
appear in the "Link Binary With Library" build phase of your target.
You may run "otool -L <exec>" on the executable created by Xcode in
order to know where the dynamic linker will search the libraries to
load. Then, check if the libraries are in the good places.
You may also run "nm <lib>" on the libpdf.a file to check if it
really export a _PDF_get_api symbol.
1) I added the static library 'libpdf.a' via the "Project <testC++>
Info" dialog for default & debug configurations:
HEADER_SEARCH_PATHS = "/Users/Ric/workarea/tmp/PDFView/c/
include /usr/local/include" <-- this is in the debug
configuration. The default has only the /usr/local/include
LIBRARY_SEARCH_PATHS = /usr/local/lib
[/usr/local/lib]ls libpdf.a
libpdf.a
2) The static library 'libpdf.a' does NOT show up in the 'Link Binary
With Library' phase. I don't know why.
3) Using the 'otool' to check the executable created by XCode:
[/Users/Ric/workarea/tmp/PDFView/C++/build/Debug]otool -L testC++
testC++:
/System/Library/PrivateFrameworks/ZeroLink.framework/
Versions/A/ZeroLink (compatibility version 1.0.0, current version 1.0.0)
/usr/lib/libstdc++.6.dylib (compatibility version 7.0.0,
current version 7.3.0)
/usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0,
current version 1.0.0)
/usr/lib/libmx.A.dylib (compatibility version 1.0.0, current
version 92.0.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0,
current version 88.0.0)
4) Using the 'nm <lib>' on libpdf.a to check for '_PDF_get_api'
symbol: *good!*, see the following line:
[/usr/local/lib]nm libpdf.a | grep '_PDF_get_api'
00000218 T _PDF_get_api
0000037c T _PDF_get_apiname
[/usr/local/lib]
------
BTW:
I'm linking 'help.cpp', 'pdflib.cpp' and 'pdflib.hpp' files.
help.cpp has:
#include <iostream>
#include "pdflib.hpp"
...
pdflib.cpp has:
#include "pdflib.hpp"
...
pdflib.hpp has:
#include "pdflib.h"
...
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden