[texworks] Compilationerror for Mingw and printing
st.loeffler at gmail.com
Mon Jun 22 09:33:14 CEST 2009
Alain Delmotte schrieb:
>> 3) If you specify the whole filename (including the "lib" prefix)
>> explicitly, I think you must also give the extension.
>> So each of the following lines should work:
>> LIBS += -lgdi32
>> LIBS += -llibgdi32.a
>> The first one is better in any case because it leaves finding the actual
>> filename to the linker. So unless it accidentally picks the wrong one
>> it's more portable.
> Both do not work :-(
> Adding INCLUDEPATH += c:/MinGW/lib
> allowed compilation with end:
> g++ -enable-stdcall-fixup -Wl,-enable-auto-import
> oc -Wl,-s -mthreads -Wl -Wl,-subsystem,windows -o release/TeXworks.exe
> ript.TeXworks.Release -L'c:/Programmes/KDE-mingw/bin/../lib'
> -lmingw32 -lqtmain
> -LC:/texworks-mingw/hunspell-1.2.8/src/hunspell/.libs -lpoppler-qt4
> 1.2 -lgdi32 -ole32 -lQtXml4 -lQtGui4 -lQtCore4
> mingw32-make: Leaving directory `C:/texworks-mingw/texworks'
Hm, strange. But instead of
INCLUDEPATH += c:/MinGW/lib
LIBS += -Lc:/MinGW/lib
(your line tells it where to look for header files, mine where to look
If you have the gdi and ole lib we must be able to get it to be linked ;).
> *But* nothing in /Release and a file le32.exe in texworks of the size
> of the TeXworks executable.
> But it doesn't work, gives an error:
> Entry point not found for the procedure
> _Z21qRegisterResourceDataiPkhSO_SO_ for dynamic links in the library
> Funny, funny!
OK, you wrote you solved the dll problem. As for the rest, that's funny
indeed. If what I wrote above doesn't help, I recommend running
to clear any old temporary files.
>>> So I deleted the 2 lines and commented the #if ... #endif (in
>>> PDFDocument.cpp) and it compiled and it works for printing the source
>>> (keeping the highlighting colors) and creating the image for the PDF
>>> (printing to pdfcreator also works -- to print only one page you have
>>> to enter 2-2 not only 2).
>> I noticed that source highlighting no longer works if you print a
>> selection. But this may also be a Linux-specific issue.
> Same on Windows. Further it is not possible to select pages for the
> source. see picture left=source, right=pdf
That's the intended behavior (well, of course it would be nicer to have
that feature, but that's not easily possible). The problem is that while
the pdf is (by definition) nicely paginated, the source code is just one
long text, without page breaks or anything. Fortunately, Qt takes care
of the pagination itself during printing, but doesn't predict it before,
so at the time we show the dialog to the user we don't actually know how
many pages there will be.
>> Could you send me a screenshot about this page specification issue?
>> Normally, you should be able to use all the normal notations (with the
>> exception of e.g. "1-2,5,9" which isn't supported by Qt; btw: could you
>> check if that prints just the pages 1-2 or all pages 1-9?)
> 1-2,5-9 not allowed (error saying that only one page is allowed), but
> 1-9 gives the 9 pages.
Interesting. I expected that complex page ranges (like 1-2,5-9) are not
supported because there is no function to handle this on the c++ side.
The fact that you have to input 2-2 to print page 2 is a bug, though.
I'll see what I can find when I have the time.
More information about the texworks