Closed DarthAlSith closed 4 years ago
Please provide more detailed information:
pdfcffdecoder.cpp
do you get this compile error? XXX:Y does not allow to identify the cause.Additionally, I would recommend to use the latest release 0.9.8 of wxPdfDocument.
Sorry.. that careless..
Which platform do you use?
I need to compile it on both Linux and Windows, and now I'm starting on Linux
Which compiler?
g++
Which build system? (configure, VC++ solution, makefile)
I configure wxWidgets-3.0.4 as:
CPPFLAGS="-std=c++98" ./configure --enable-monolithic --enable-debug --enable-utf8 --disable-std_string --without-gtkprint --disable-compat28 --without-subdirs
and then configure wxPdfDoc-0.9.7 as:
CPPFLAGS="-std=c++98" ./configure --with-wx-config=../wxWidgets-3.0.4-debug/wx-config
To compile I launch make command
At which line number in pdfcffdecoder.cpp do you get this compile error? XXX:Y does not allow to identify the cause.
I get the error at the lines 157 and 172.
PS: I decided to use 0.9.7 version, after I read that it's latest stable
It seems to be solved.
I compiled without errors changing the use of MACRO wxS()
with wxT()
in the following files:
minimal/labels.cpp src/pdfcffdecoder.cpp src/pdffontmanager.cpp src/pdffontparsertruetype.cpp src/pdffontsubsettruetype.cpp src/pdfkernel.cpp src/pdfparser.cpp src/pdfcjkfontdata.inc src/pdfcmapdata.inc src/pdfcodepagedata.inc src/pdfcolourdata.inc src/pdfcorefontdata.inc src/pdfglyphnames.inc
What do you think about? Compile goes ok; now I try to insert these libraries in my program and test its usage.
PS: I decided to use 0.9.7 version, after I read that it's latest stable
Where did you read that??? This is simply not true.
I strongly recommend to use version 0.9.8 as it adds alpha transparency support for wxPdfDC and a few other useful things.
I configure wxWidgets-3.0.4 as:
CPPFLAGS="-std=c++98" ./configure --enable-monolithic --enable-debug --enable-utf8 --disable-std_string --without-gtkprint --disable-compat28 --without-subdirs
I fear that the compile error you get might be a side effect of the option --enable-utf8
as it modifies the definition of the string macro wxS
. I know that wxPdfDocument compiles flawlessly with the wxWidgets default build configuration (which uses UTF8 for internal string representation anyway as far as I know).
You could try to modify line 147 (resp line 163) by replacing wxChar*
by wxString
:
static const wxString gs_subrsFunctions[] = {
I have not tested this myself, but it might solve the issue. However, this type of initialization is used in various other source files of wxPdfdoucument as well. Therefore you should maybe reconsider whether you really need compile option --enable-utf8
.
It seems to be solved.
Good news.
I compiled without errors changing the use of MACRO wxS() with wxT() in the following files: [...]
As mentioned in my previous post this type of initialization with macro wxS
is used in several source files of wxPdfDocument.
What do you think about?
Well, in earlier versions of wxPdfDocument I used the macro wxT
throughout the whole source code. However, it was recommended to use wxS
for better compatibility with wxWidgets 3.x. So I changed from wxT
to wxS
.
While wxT
always creates wide strings independent of the UTF8 setting, wxS
does not if UTF8 is enabled.
Compile goes ok; now I try to insert these libraries in my program and test its usage.
In principle the program should work if it compiles without errors. But since I never used option --enable-utf8
myself I have no idea whether it might still cause problems at runtime.
Since I intend to drop compatibility with wxWidgets 2.8.x anyway, I will consider to rewrite the code to avoid such problems for future versions of wxPdfDocument.
Just for the record, wx doesn't use UTF-8 by default. And wxS()
is not equivalent to wxT()
, it's intentionally different from it in UTF-8 build so that you can use have a literal of the same type that is used by wxString
by default -- which is not the case with wxT()
in UTF-8 build. However wxChar
is still wchar_t
even in UTF-8 build, which probably explains the errors.
I.e. in UTF-8 build the type used by wxString
internally is not the same wxChar
.
Thanks for the clarification, Vadim.
The reasoning behind using wxChar*
for static string constants in wxPdfDocument was to avoid the creation of tons of wxString objects. This worked without issues for wxWidgets 2.8.x and at least for default builds for wxWidgets 3.x.
I have to admit that I wasn't aware of the differences between wxS
and wxT
in UTF-8 builds. The question is what would be the most appropriate approach to fix the issue for UTF-8 builds without breaking anything else.
One possibility is to use wxStringCharType
instead of wxChar
: this would allow the code using wxS()
compile in all build variants, I think. However wxStringCharType
doesn't exist in 2.8, so you'd have to use some wxPdfDocCharType
and define it as wxChar
with 2.8.
I will consider to introduce such an approach. However on the other hand, I think the time has come to drop 2.8 compatibility.
Thank you guys.
One possibility is to use
wxStringCharType
instead ofwxChar
: this would allow the code usingwxS()
compile in all build variants, I think. HoweverwxStringCharType
doesn't exist in 2.8, so you'd have to use somewxPdfDocCharType
and define it aswxChar
with 2.8.
I'll try to use the solution suggested by vadz.. I update you
UPDATE: the files to modify are the same that in the previous case:
minimal/labels.cpp src/pdfcffdecoder.cpp src/pdffontmanager.cpp src/pdffontparsertruetype.cpp src/pdffontsubsettruetype.cpp src/pdfkernel.cpp src/pdfparser.cpp src/pdfcjkfontdata.inc src/pdfcmapdata.inc src/pdfcodepagedata.inc src/pdfcolourdata.inc src/pdfcorefontdata.inc src/pdfglyphnames.inc
I was able to apply vadz's solution in the most chance, except 2 files:
src/pdfcjkfontdata.inc src/pdfcorefontdata.inc
For these, it seemed, at first look, more articulated proceed as others and so I defined static arrays' texts with macro wxT() Now, I'm going to test it.
Since wxWidgets recommends to avoid the use of macro wxT
for version 2.9 and above, I'd like to avoid to reintroduce it in wxPdfDocument, although this approach may be the quickest solution for your use case.
Instead I now plan to drop support for wxWidgets 2.8.x (last release was in 2011 - almost 9 years ago). In this course I will remove all those static wxChar
constants. However, this process will take some time.
Ok utelle. now, sorry for the shameful question .. how come a dynamic library is not created ..?? .. it didn't seem like there was a parameter to be forced.
AFAIK creating shared libraries should be the default under Linux. If that doesn't work for you, I'm at a loss unfortunately, because I do most of my development under Windows. Maybe @vadz has an idea what could have been gone wrong.
I made a quick check under Linux using the default build configuration. The shared libraries are created as expected.
Hi utelle. Could you show me the compilation command that you used?
Well, as said I used default configurations. I compiled wxWidgets 3.1.3 as descibed in its documentation using
mkdir build-gtk
cd build-gtk
../configure --with-gtk
make
and - with a fresh copy of wxPdfDocument 0.9.8 -
autoreconf
mkdir build-gtk
cd build-gtk
../configure
make
Maybe one thing to mention is that libtool
is used for wxPdfDocument, that is, the shared libraries are created in subdirectory .libs
of the build directory.
I used:
-for wxWidgets-3.0.4:
CPPFLAGS="-std=c++98" ./configure --enable-monolithic --enable-debug --disable-std_string --without-gtkprint --disable-compat28 --without-subdir
-for wxPdfDoc-0.9.8:
CPPFLAGS="-std=c++98" ./configure --with-wxdir="../wxWidgets-3.0.4-debug"
In addition, in the last rows of configure's output I read:
.... checking for wxWidgets static library... Warning: No config found to match ... checking if wxWidgets was built with UNICODE enabled... yes checking if wxWidgets was built in DEBUG mode... no checking if wxWidgets was built in STATIC mode... no
..but I compiled wxWidgets in Debug Mode
IMHO you need to specify the debug option explicitly. Simply referencing the wx directory is not enough, because you could have several different builds in that directory. So, maybe try to add option --enable-wxdebug
(and possibly --enable-debug
).
Ok. I try this configuration:
CPPFLAGS="-std=c++98" ../configure WX_CONFIG="../../wxWidgets-3.1.3-debug/build-x/" --enable-wxdebug --enable-debug
...and configuration seems go ok, but gives me warning unrecognized options: --enable-wxdebug, --enable-debug
libtool: link:
src/pdfannotation.lo' is not a valid libtool object`I can't explain the error message you get from libtool. However, I can confirm that the options --enable-debug
and --enable-wxdebug
are not recognized. Again, I don't know why that is so.
The configure support for wxPdfDocument was initially provided by @vadz. So I hope he can shed some light on those issues.
I try this configuration:
* configure and compile wxWidgets-3.1.3 in debug mode, in a specific 'build-x' dir: OK. * configure wxpdfdoc-0.9.8, from relative 'build-x' dir, with command: `CPPFLAGS="-std=c++98" ../configure WX_CONFIG="../../wxWidgets-3.1.3-debug/build-x/" --enable-wxdebug --enable-debug` ...and configuration seems go ok, but gives me warning `unrecognized options: --enable-wxdebug, --enable-debug`
This is wrong, WX_CONFIG
needs to be set to the location of wx-config
, which is missing at the end of your path. If you want to use a directory, you can use --with-wxdir=PATH
option instead.
Also, --enable-wxdebug
is not really useful, I'm not sure why do you use it.
Well, I'm to blame for that @DarthAlSith tried out option --enable-wxdebug
. I asked him to try it in a previous post. In fact, neither --enable-debug
nor --enable-wxdebug
are recognized by wxPdfDocument's configure script. How can debug mode be enabled for wxPdfDocument then?
How can debug mode be enabled for wxPdfDocument then?
There is no debug mode in the current configure. It's not really clear to me what would it do -- -g
is used by default anyhow. In fact, the main use of it I can see is to make --disable-debug
disable the use of -g
and define NDEBUG
.
The OP asked for debug mode.
I had the impression that with wxWidgets 3.x there is no separate debug build anymore at least under Linux. However, the build instructions for wxWidgets itself clearly make a distinction between release and debug build.
Personally, I develop and test mostly under Windows. I usually verify that all functions properly under Linux, but I seldom need to debug under Linux.
Yes, in 3.x there is one default build, which includes debug helpers which can be activated or not by the application. So for an application, it might make sense to use some configure option to disable asserts. But I don't really think --enable-debug
makes much sense for a library such as wxPdfDoc.
You are right. In fact, wxPdfDocument does not have any debug specific code except for several calls to wxLogDebug
.
Hi guys. Ok about debug option for wxPdfDoc.. I understand. My problem is still that I'm not able to obtain shared library for wxpdfdoc.
The last working configuration is:
CPPFLAGS="-std=c++98" ./configure --enable-monolithic --enable-debug --enable-utf8 --disable-std_string --without-gtkprint --disable-compat28 --without-subdirs
CPPFLAGS="-std=c++98" ./configure WX_CONFIG="../../wxWidgets-3.1.3-debug/wx-config"
how can we solve?
File libwxcode_gtk2u_pdfdoc-3.0.la
should be a rather small libtool text file containing references to the shared library files located in subdirectory .libs
of the build directory. For linking you then use libtool (see Linking executables using libtool).
Ok, I'll look at it. Thanks.
Now closing, since the issue is related to build tools and not wxPdfDocument itself.
Feel free to reopen if necessary.
Hi. I compiled wxWidgets-3.0.4 with UTF8 encoding. When I try to compile wxPdfdoc-0.9.7 with the wx-config file of the version compiled before it gives me the error:
"pdfcffdecoder.cpp:XXX:Y: error: cannot convert 'const char' to 'const wxChar {aka const wchar_t*}' in initialization"
how can I solve it? Can you help me?