tasen / leptonica

Automatically exported from code.google.com/p/leptonica
0 stars 0 forks source link

Leptonica 1.7 DLL linker errors #93

Open GoogleCodeExporter opened 8 years ago

GoogleCodeExporter commented 8 years ago
What steps will reproduce the problem?
1. Download FRESH copy of Leptonica source, e.g. 1.7 (as well as other 
dependencies)
2. Compile with target set as DLL Release in Visual Studio
3. Watch as compilation is successful but linkage fails

What is the expected output? What do you see instead?

Expected output would be a dll file for lept1.7.

Instead I get this:

1>affinecompose.obj : error LNK2019: unresolved external symbol 
_boxaConvertToPta referenced in function _boxaAffineTransform
1>affinecompose.obj : error LNK2019: unresolved external symbol 
_ptaConvertToBoxa referenced in function _boxaAffineTransform
1>pixabasic.obj : error LNK2001: unresolved external symbol _boxaGetExtent
1>pixafunc1.obj : error LNK2019: unresolved external symbol _boxaGetExtent 
referenced in function _pixaSort
1>pixafunc2.obj : error LNK2001: unresolved external symbol _boxaGetExtent
1>boxbasic.obj : error LNK2001: unresolved external symbol _boxaGetExtent
1>boxfunc2.obj : error LNK2001: unresolved external symbol _boxaGetExtent
1>boxfunc3.obj : error LNK2001: unresolved external symbol _boxaGetExtent
1>partition.obj : error LNK2001: unresolved external symbol _boxaGetExtent
1>boxfunc3.obj : error LNK2019: unresolved external symbol _boxaSelectByArea 
referenced in function _boxaCompareRegions
1>boxfunc3.obj : error LNK2019: unresolved external symbol _boxaGetArea 
referenced in function _boxaCompareRegions
1>colormap.obj : error LNK2019: unresolved external symbol 
_pixelShiftByComponent referenced in function _pixcmapShiftByComponent
1>jbclass.obj : error LNK2019: unresolved external symbol _boxaSelectBySize 
referenced in function _jbGetComponents
1>pdfio.obj : error LNK2019: unresolved external symbol _l_dnaCreate referenced 
in function "int __cdecl parseTrailerPdf(struct L_Bytea *,struct L_Dna * *)" 
(?parseTrailerPdf@@YAHPAUL_Bytea@@PAPAUL_Dna@@@Z)
1>utils.obj : error LNK2001: unresolved external symbol _l_dnaCreate
1>pdfio.obj : error LNK2019: unresolved external symbol _l_dnaDestroy 
referenced in function "int __cdecl parseTrailerPdf(struct L_Bytea *,struct 
L_Dna * *)" (?parseTrailerPdf@@YAHPAUL_Bytea@@PAPAUL_Dna@@@Z)
1>utils.obj : error LNK2001: unresolved external symbol _l_dnaDestroy
1>pdfio.obj : error LNK2019: unresolved external symbol _l_dnaEmpty referenced 
in function "int __cdecl parseTrailerPdf(struct L_Bytea *,struct L_Dna * *)" 
(?parseTrailerPdf@@YAHPAUL_Bytea@@PAPAUL_Dna@@@Z)
1>pdfio.obj : error LNK2019: unresolved external symbol _l_dnaAddNumber 
referenced in function "int __cdecl generateColormapStringsPdf(struct 
L_Pdf_Data *)" (?generateColormapStringsPdf@@YAHPAUL_Pdf_Data@@@Z)
1>utils.obj : error LNK2001: unresolved external symbol _l_dnaAddNumber
1>pdfio.obj : error LNK2019: unresolved external symbol _l_dnaGetCount 
referenced in function "void __cdecl generateTrailerPdf(struct L_Pdf_Data *)" 
(?generateTrailerPdf@@YAXPAUL_Pdf_Data@@@Z)
1>utils.obj : error LNK2001: unresolved external symbol _l_dnaGetCount
1>pdfio.obj : error LNK2019: unresolved external symbol _l_dnaGetIValue 
referenced in function "void __cdecl generateTrailerPdf(struct L_Pdf_Data *)" 
(?generateTrailerPdf@@YAXPAUL_Pdf_Data@@@Z)
1>pdfio.obj : error LNK2019: unresolved external symbol _l_dnaGetIArray 
referenced in function "int __cdecl generateOutputDataPdf(unsigned char * 
*,unsigned int *,struct L_Pdf_Data *)" 
(?generateOutputDataPdf@@YAHPAPAEPAIPAUL_Pdf_Data@@@Z)
1>pdfio.obj : error LNK2019: unresolved external symbol _l_dnaaCreate 
referenced in function _ptraConcatenatePdfToData
1>pdfio.obj : error LNK2019: unresolved external symbol _l_dnaaDestroy 
referenced in function _ptraConcatenatePdfToData
1>pdfio.obj : error LNK2019: unresolved external symbol _l_dnaaAddDna 
referenced in function _ptraConcatenatePdfToData
1>pdfio.obj : error LNK2019: unresolved external symbol _l_dnaaGetDna 
referenced in function _ptraConcatenatePdfToData
1>pdfio.obj : error LNK2019: unresolved external symbol _l_dnaMakeDelta 
referenced in function _ptraConcatenatePdfToData
1>pdfio.obj : error LNK2019: unresolved external symbol _readHeaderJp2k 
referenced in function "struct L_Compressed_Data * __cdecl 
l_generateJp2kData(char const *)" 
(?l_generateJp2kData@@YAPAUL_Compressed_Data@@PBD@Z)
1>readfile.obj : error LNK2001: unresolved external symbol _readHeaderJp2k
1>readfile.obj : error LNK2019: unresolved external symbol _sreadHeaderJp2k 
referenced in function _pixReadHeaderMem
1>DLL Release\liblept168.dll : fatal error LNK1120: 21 unresolved externals

What version of the product are you using? On what operating system?

Attempting to compile dll version of 1.7, Windows 8, Visual studio 2012

Please provide any additional information below.

For an explanation of the linker issues let's take a look at this example:
The boxaTranslate function in affinecompose.c calls boxaConvertToPta. Now the 
prototype for boxaConvertToPta is defined in allheaders.h, yet it was REMOVED 
from its original place in boxfunc1.c (it was there pre 1.69). So it looks like 
whatever changes that were made to boxfunc1 and other files weren't propagated 
forward OR the latest zip file doesn't contain up to date versions of 
affinecompose.c along with many other files. This seems to indicate that the 
latest files are not in the zip file.

I managed to fix a variety of other Visual Studio related issues as well which 
I'll outline below (in case anyone else comes along having these issues), 
they're unrelated to the issue at hand. 

======================================================================
First, building leptonica under Visual Studio to treat all the .c files as .cpp 
files. This is due to the constant static integers like:

static const l_int32  L_BUF_SIZE = 512

In traditional "C" (e.g. pre C99) const meant nothing for resolving compile 
time variables to values (and in general really), thus this would cause 
failures anywhere an array was created using L_BUF_SIZE. The visual studio 
project must enable /TP option or "Compile as C++" under the advanced options 
in the C/C++ compiler properties page. 

Next, I determined the fix for seeing all those Chinese characters mentioned in 
issue #80, it turns out the vcxproj file contained new lines separating various 
xml nodes like the following: 

      <Command>if not exist ..\..\lib md ..\..\lib copy "$(TargetPath)" ..\..\lib
copy "$(TargetDir)$(TargetName).lib" ..\..\lib
      </Command>

A fix here is to simply remove the new lines:

      <Command>if not exist ..\..\lib md ..\..\lib copy "$(TargetPath)" ..\..\lib copy "$(TargetDir)$(TargetName).lib" ..\..\lib </Command>

You must do this for each instance where a new line occurs, such as the 
%(Additional Options) under the options flag nodes/elements.

Finally, you may fail to compile due to LNK1281: Unable to generate SAFESEH 
image. You need to turn off the compilation flags for this in the advanced 
linker options section for safe exception handling.

Original issue reported on code.google.com by jnclay...@gmail.com on 5 Feb 2014 at 7:49

GoogleCodeExporter commented 8 years ago
I should note that this was the subject of issue #80 but wasn't solved 
directly. The poster reverted back to 1.68.

Also, any known issues with 1.70 interfacing with tesseract? It would be good 
to get those out in the open if there are any.

Thanks!

Original comment by jnclay...@gmail.com on 5 Feb 2014 at 7:58

GoogleCodeExporter commented 8 years ago
Thank you for looking at these issues in detail.  I am sure that Tom Powers, 
who maintains the win32 build, will get back to you on this.

As for tesseract, we are coordinating a debian release of leptonica with the 
latest version of tesseract.

Original comment by dan.bloo...@gmail.com on 5 Feb 2014 at 2:43

GoogleCodeExporter commented 8 years ago
I have NOT released a Visual Studio 2008 Solution yet for Leptonica 1.70. 
Please be patient. A temporary VS2008 solution was sent to the tesseract 
project for their use only. I have yet to hear back directly from them. (No 
news is good news?)

Using VS2008 (and my new VS2008 Solution files), I have successfully build 
v1.70 many times over the past 2 weeks.

I'm not sure when I will release an official v1.70 VS2008 solution. For one 
thing, it depends on when leptonica itself stops changing (there were changes 
just yesterday). It will probably be at least a week from now.

Leptonica 1.69 was NEVER officially supported on Windows. It was supposed to be 
a linux only release. Basing a 1.70 Windows build on some files you somehow got 
for 1.69 is not a great idea. (Possibly someone edited the xml files on linux 
thereby breaking newlines? Who knows?)

As you noted, the /TP switch has to be turned on now for compiling leptonica 
sources.

I have not attempted to compile via VS2012 yet. I would expect a few minor 
issues. I seem to recall reading somewhere that turning off the SAFESEH was 
handled automatically when converting VS2008 projects to VS2012?

I wouldn't recommend deleting those lines from the Build Events. At least not 
unless you understand the implications of doing so.

Watching the tesseract mailing lists, I see that among other things, there is 
NO support yet for building the training tools on Windows. OTOH, zdenko has 
reported that he has been able to build tesseract itself using Leptonica 1.70 
and VS2010 (but he has limited time to work on tesseract at the moment, 
apparently, and even less time to work on the Windows side of things).

Original comment by tomp2...@gmail.com on 5 Feb 2014 at 3:27

GoogleCodeExporter commented 8 years ago
Hey Tom, I appreciate all of the work you've done getting the visual studio 
side of things taken care of. 

I realize you're a busy guy, so I'll make a quick summary, look below the 
separation marks (=====) for more details/a more lengthy reply.

There are missing function definitions of boxaConvertToPta, ptaConvertToBoxa, 
etc in the c files (the prototypes were correctly declared, but there function 
bodies are missing!). Please just look yourself in the zip version posted here:

http://www.leptonica.com/source/leptonica-1.70.tar.gz

All I'm asking is that you grep/look for boxaConvertToPta and tell me where you 
see the function definition (not just declaration, e.g. where the actual body 
of the function is) being. 

===================================================
I realize you didn't post a 1.70 official VS project release. 

I didn't take/use/include any files from v1.69. I said that pre v1.69 (e.g. 
1.68) there were function definitions that are no longer in v1.70. I didn't 
base anything on v1.69. While having having an official vs 2008 release would 
be nice, it's unnecessary for me. I am savvy at dealing with visual studio or 
general Windows/Linux porting related issues. What I'm seeing is function 
bodies missing while the prototypes still exist. Those prototypes are then 
referenced in various places. Like a call on line 348 of affinecompose.c to 
boxaConvertToPta. The zip file for 1.7 on the official Leptonica web page 
doesn't contain a function definition (it contains a declaration in 
allheaders.h, but no function definition). A function definition existed in 
v1.68 in file  boxfunc1.c on line 1524. So boxfunc1.c was refactored but those 
changes didn't propagate to affinecompose.c in a meaningful way. Now I can add 
those function definitions back just to get it to compile but I'm weary of 
doing so for obvious reasons.

When you say you've successfully built v1.70 was that targeting the lib or dll 
version? Did you try both release and debug? If so, I suggest you download a 
fresh copy of v1.70 and try to rebuild, use the same VS project files if you 
want but using the zip's src and prog files. Please try the dll debug and 
release versions.

I have a feeling that the latest "c" files do not include all of the updates. 
Or if they do then the dll version is seemingly broken. You may have made 
changes that affect targeting the dll side of things. If you could take a 
moment just to verify that the stuff in the leptonica 1.7 zip file posted 
contains everything you're building with that would be great.

Everything except linking the dll release/debug seems to work. 

Regarding the issues below the ========= line: these were all problems I saw 
and the approaches I took to get rid of them. I do not need help on these. The 
only reason I posted them were for anyone else also seeing the same issues. I'm 
not sure what you meant about deleting lines from the "Build Events."  I didn't 
mention deleting any "lines" but removing "newlines" from the vcxproj file. 
There are known issues with the xml parser for VS2010+ regarding the vcxproj 
files, googling a bit reveals that newlines bork up the parsing of specific xml 
elements resulting in the Chinese characters seen in issue #80.

Original comment by jnclay...@gmail.com on 6 Feb 2014 at 4:34

GoogleCodeExporter commented 8 years ago
I just checked the archive I downloaded from leptonica.org on 1/23/2014. In
boxfunc4.c line 599 I see the definition of boxaConvertToPta(). I also
re-downloaded it and it hasn't changed.

You'll have to ask Dan if he's been changing the 1.70 archive since it
first went up but I doubt it? Perhaps you forgot to add boxfunc4.c to your
solution? Via a local mercurial repository I use to keep track of changes I
can tell that boxfunc4.c has been added since 1.68.

When testing I build DLL_Debug, DLL_Release, LIB_Debug, and LIB_Release. I
get ZERO errors & warnings. Of course I cheat a bit by turning off some
warnings that I feel are mainly noise, but Dan does fix any other warning
that show up. I then manually build & run ioformats_reg, dwamorph1_reg,
dwamorph2_reg for all 4 configurations.

In addition all 62 alltests_reg programs are built for all 4
configurations. "alltests_reg compare" is then run for all configurations
to test against "golden" files generated by an "alltests_reg generate" done
a week or so ago. One test out of 61 fails and Dan is still trying to
figure out why.

The remaining 174 prog programs are built for all 4 configurations to make
sure there are no compiler errors, but so far I've only tested a few of
them.

Ah... newlines not lines. Sorry I was reading too fast. I see that bug has
been reported at [1]. Thanks for pointing out the root cause of the problem.

[1] http://connect.microsoft.com/VisualStudio/feedback/details/774527

    -- Tom

Original comment by tomp2...@gmail.com on 6 Feb 2014 at 2:46

GoogleCodeExporter commented 8 years ago
[deleted comment]
GoogleCodeExporter commented 8 years ago
The 1.70 archive version on leptonica.org has not changed since I put it up 
about 2 weeks ago.  However, I will replace it today with a slightly updated 
version that has removed the few bugs we have found since then.  There may be 2 
or 3 new functions.  AFter that it will not be changed, but version 1.71 will 
go up shortly with changes requested by Tom and others.  I expect that Tom's 
official VS build will be to 1.71.

We presently have 61 tests, of which 1 fails if the test harness runs on 4 
cores and succeeds if it runs on 2.  It is almost certainly due to a 
synchronization problem where a temporary file from one slow test is 
overwritten by another somewhat distant in the list.  By moving the failing 
test forward, the test passes.

Original comment by dan.bloo...@gmail.com on 6 Feb 2014 at 3:51

GoogleCodeExporter commented 8 years ago
Ah, nuts! Thanks Tom. You're right that the solution didn't contain boxfunc4.c, 
I should have taken more time and done what I was asking you to do by doing the 
find/grep instead of using the built in solution search.

Thanks again guys!

Original comment by jnclay...@gmail.com on 6 Feb 2014 at 5:31

GoogleCodeExporter commented 8 years ago
doh I just spent 3 days cross compiling from mingw to windows / visual studio 
in order to get leptonica 1.7 working for tesseract because i couldnt get it to 
compile in VS 2013... oh well

Original comment by sirus2...@gmail.com on 6 Feb 2014 at 8:37