Building zxing on Windows using Visual C++ and Visual Studio
eldiener
the Visual Studio IDE ? Is it just a matter of creating a DLL project
and adding all the source code in the zxing\cpp\core\src\zxing
directory and below ?
Has anyone been able to use the cpp port of zxing with a Windows
application ? I am particularly looking for the ability to decode
Datamatrix 2d barcodes in Windows application built with Visual C++.
Thanks !
Gunboat Diplomat
> the Visual Studio IDE ? Is it just a matter of creating a DLL project
> and adding all the source code in the zxing\cpp\core\src\zxing
> directory and below ?
There are very few platform dependencies so it wasn't very hard to
do. The only issues I had were that certain floating point constants
(INFINITY and NaN) that exist for GNU's implementation of math.h don't
exist for Microsoft's and there was no Unicode support, which is
compiled for in Windows by default...
> Has anyone been able to use the cpp port of zxing with a Windows
> application ? I am particularly looking for the ability to decode
> Datamatrix 2d barcodes in Windows application built with Visual C++.
been working strictly with QR codes so perhaps bar codes will work
better...
I hope that helps!
Steven Parkes
> (INFINITY and NaN) that exist for GNU's implementation of math.h don't
> exist for Microsoft's
Sounds like we should switch those preprocessor defines to numeric_limits<> functions …
> and there was no Unicode support, which is
> compiled for in Windows by default…
Not sure what this means.
> I have yet to get the cpp port to correctly scan any image but I've
> been working strictly with QR codes so perhaps bar codes will work
> better...
Actually, the qr code support is much more solid in C++ than the 1D codes. Not sure what's failing in your port. Sounds like it's gonna take some tracking down ...
Gunboat Diplomat
> Sounds like we should switch those preprocessor defines to numeric_limits<> functions …
> > and there was no Unicode support, which is
> > compiled for in Windows by default…
>
> Not sure what this means.
Unicode support...
> Actually, the qr code support is much more solid in C++ than the 1D codes. Not sure what's failing in your port. Sounds like it's gonna take some tracking down ...
There's something else of note. On the advice of Sean Owen, I'm
trying to build subversion revision 2132 and found a curious warning
in qrcode/detector/AlignmentPatternFinder.cpp on line 147:
size_t i = middleI + ((iGen & 0x01) == 0 ? ((iGen + 1) >> 1) : -((iGen
+ 1) >> 1));
gcc compiles this just fine but Microsoft's C++ compiler gives the
following warning:
warning C4146: unary minus operator applied to unsigned type, result
still unsigned
I haven't gotten a chance to test the MS compiler yet but I have
access to a Linux machine and, sure enough, this line compiles and
works as what was intended. Sadly, I won't say that it works as it
should because, as rare as it is for me to agree with MS, it is wrong
to take the unary minus of an unsigned type and get a signed one. I
also disagree that this should be a mere warning. It really should
have just errored out. To be on the safe side, this code should be
more like this:
size_t i = ((iGen & 0x01) == 0 ? middleI + ((iGen + 1) >> 1) : middleI
- ((iGen + 1) >> 1));
The take-away lesson here is that, when porting this code (or any!) to
your platform (MS Windows in our case), you should look through the
warnings carefully! Additionally, this is why many development
projects adhere to a zero warning policy. If there are millions of
warnings scrolling across the screen, you'll just ignore them and miss
the one revealing a serious bug! It's also not hard to avoid them as
you code the project...
Steven Parkes
> still unsigned
(Presumably) this is okay and VC++ is being overly conservative. We could probably quiet it with a cast but see below.
> Sadly, I won't say that it works as it
> should because, as rare as it is for me to agree with MS, it is wrong
> to take the unary minus of an unsigned type and get a signed one.
You don't. Negating an unsigned is an unsigned of the same width. It's completely legitimate to take the 2s complement of an unsigned. It'll never compare less than zero, but we aren't expecting it to … I hope. (See below.)
The warning is just saying what the standard says. I presume it's there because it's a common mistake but it is an entirely valid expression and entirely well defined (modulo my misinterpretation of the standard.)
What this does point out, though, is that (in my opinion) this code should not be using size_t's. We really want to keep the C++ as close to the Java code as we can so weird (and hard to debug) differences don't crop up. Since Java doesn't have unsigned types, this means we should be using signed types even where unsigned types make sense/seem safe.
In this case, it doesn't make any difference because the final values are always non-negative (since i is used to deference the image and that will fail for negative values) but it's certainly possible for Java code to use negative values as a flag and if we copy expressions like that but change the type to unsigned, we'll definitely get different behavior. Generally this will generate a warning, at least in gcc, but it's just too error prone, too easy to silence with an incorrect cast.
My thinking is that this (and probably other) uses of size_t should be switched to ptrdiff_t. It's more or less that signed equivalent of size_t. ssize_t is the other obvious possibility but the theoretical definition of ssize_t (close to size_t, but also -1) is not as general as Java int. ptrdiff_t is more or less supposed to be able to represent the distance between the beginning and end of large arrays in either direction, which is seems right.
Thoughts?
Gunboat Diplomat
> > warning C4146: unary minus operator applied to unsigned type, result
> > still unsigned
>
> (Presumably) this is okay and VC++ is being overly conservative. We could probably quiet it with a cast but see below.
I've finally gotten around to trying this in VC++ and I was shocked to
find it just as silent as gcc. Upon further investigation, it
produces this warning strictly for type size_t. My tests were using
unsigned char, thinking that any unsigned type will suffice.
Apparently not...
> > Sadly, I won't say that it works as it
> > should because, as rare as it is for me to agree with MS, it is wrong
> > to take the unary minus of an unsigned type and get a signed one.
>
> You don't. Negating an unsigned is an unsigned of the same width. It's completely legitimate to take the 2s complement of an unsigned. It'll never compare less than zero, but we aren't expecting it to … I hope. (See below.)
disagree with you. It might be tempting to think that you should be
able to take the two's compliment of an unsigned integer since it's
just a sequence of bits for which a two's compliment exists but what
does this mean? By that logic, you can take the two's compliment of a
float since it too is just a sequence of 32 bits... except that, in
the context of floating point arithmetic, the two's compliment in
meaningless. In the same way, if what you intended is really an
unsigned integer, the two's compliment of it is similarly
meaningless...
> The warning is just saying what the standard says. I presume it's there because it's a common mistake but it is an entirely valid expression and entirely well defined (modulo my misinterpretation of the standard.)
point out that you can omit returning a value for a non-void function
but I don't think you'd call that "valid..."
Incidentally, gcc doesn't bother giving a warning for that, either!
...and, upon closer inspection, VC++ gives an actual error. I could
have sworn I recall a time when that was merely a warning...
> What this does point out, though, is that (in my opinion) this code should not be using size_t's. We really want to keep the C++ as close to the Java code as we can so weird (and hard to debug) differences don't crop up. Since Java doesn't have unsigned types, this means we should be using signed types even where unsigned types make sense/seem safe.
implementation as possible for exactly the reasons you state...
> In this case, it doesn't make any difference because the final values are always non-negative (since i is used to deference the image and that will fail for negative values) but it's certainly possible for Java code to use negative values as a flag and if we copy expressions like that but change the type to unsigned, we'll definitely get different behavior. Generally this will generate a warning, at least in gcc, but it's just too error prone, too easy to silence with an incorrect cast.
stating my opinion here) to using negative numbers as flags. You
should probably just pass some flags as additional parameters...
> My thinking is that this (and probably other) uses of size_t should be switched to ptrdiff_t. It's more or less that signed equivalent of size_t. ssize_t is the other obvious possibility but the theoretical definition of ssize_t (close to size_t, but also -1) is not as general as Java int. ptrdiff_t is more or less supposed to be able to represent the distance between the beginning and end of large arrays in either direction, which is seems right.
admittedly, is usually done only for array manipulation but still...
not all pointer arithmetic is done on arrays. Since it appears that
none of the size_t variables in that function, particularly iGen,
middleI, i and j, are created by pointer arithmetic and are instead
used to create array indeces, I think the most prudent choice for
clarity is to simply use type int, just like the Java version
(presumably. I don't know Java and haven't looked at that code).
> Thoughts?
I had plenty. I hope you enjoyed them as much as I enjoyed telling
you them. I find conversation riveting...
Steven Parkes
> produces this warning strictly for type size_t. My tests were using
> unsigned char, thinking that any unsigned type will suffice.
Any size smaller than int undergoes integral promotion before being used in an expression, so an unsigned char becomes an unsigned int then the - is applied to the unsigned int and it stays an unsigned int, so I'm not sure why VC++ would warn for size_t and not unsigned char. I would understand if - on an unsigned promoted it to the next larger signed type but it doesn't.
So I still hold that it's an invalid warning, so who knows how they decide when to put up invalid warnings.
> It depends on what you mean by "legitimate"
By the definition in the standard.
Strictly speaking the standard doesn't say twos complement, it says
"The negative of an unsigned quantity is computed by subtracting its value from 2^n,
where n is the number of bits in the promoted operand."
> I won't pretend to know the standards specification but I'll just
> point out that you can omit returning a value for a non-void function
> but I don't think you'd call that "valid…"
The standard says that not providing a return value in a value-returning function results in undefined behavior.
There's nothing undefined about the result of unary minus on an unsigned.
> Incidentally, gcc doesn't bother giving a warning for that, either!
You need to use -Wall more often. We compile zxing with -Wall -Wextra -Werror, which is the way I compile all my C/C++/ObjectiveC/ObjectiveC++ code. I usually throw -pedantic in there, too, but zxing relies on auto arrays of variable size which is a non-standard extension.
> I must say that I'd object (not that I'm anyone important. I'm just
> stating my opinion here) to using negative numbers as flags.
I didn't mean to imply that it does (and whether you do or don't isn't an argument I'm personally particularly interested). I only raised it because it would be a compatibility issue if it did.
> ptrdiff_t is supposed to be the result of pointer arithmetic which,
> admittedly, is usually done only for array manipulation but still...
> not all pointer arithmetic is done on arrays.
Actually, ptrdiff_t is defined to be the type of pointer differences; all other valid pointer-pointer operations return bool. And pointer difference is only defined for arrays:
"Unless both pointers point to elements of the same array object, or
one past the last element of the array object, the behavior is undefined."
Of course, it's commonly used in lots of other ways, but strictly speaking that relies on undefined behavior.
> I think the most prudent choice for
> clarity is to simply use type int
sizeof(int) < sizeof(ptrdiff_t) for x86_64 so I still think ptrdiff_t is the right choice.
Steven Parkes
I just reread this and it reads wrong. It sounds like I'm (pretty obnoxiously) saying I'm not interested in nerdyvideo's opinion. I actually meant "whether we do or don't", in other words, I don't have a strong opinion/am not terribly interested in arguments on whether or not the project as whole uses this pattern. Not a hot button for me.
My apologies for sounding so rude ...
Gunboat Diplomat
On Jan 31, 6:55 pm, Steven Parkes <smpar...@smparkes.net> wrote:
>
> ...
> By the definition in the standard.
>
I'll defer to your intimate knowledge of the standard and simply say
that it is a strange beast...
> > Incidentally, gcc doesn't bother giving a warning for that, either!
>
> You need to use -Wall more often. We compile zxing with -Wall -Wextra -Werror, which is the way I compile all my C/C++/ObjectiveC/ObjectiveC++ code. I usually throw -pedantic in there, too, but zxing relies on auto arrays of variable size which is a non-standard extension.
Must the auto arrays be used? Couldn't type vector be used instead?
> > ptrdiff_t is supposed to be the result of pointer arithmetic which,
> > admittedly, is usually done only for array manipulation but still...
> > not all pointer arithmetic is done on arrays.
>
> Actually, ptrdiff_t is defined to be the type of pointer differences; all other valid pointer-pointer operations return bool. And pointer difference is only defined for arrays:
>
> "Unless both pointers point to elements of the same array object, or
> one past the last element of the array object, the behavior is undefined."
>
> Of course, it's commonly used in lots of other ways, but strictly speaking that relies on undefined behavior.
> > I think the most prudent choice for
> > clarity is to simply use type int
>
> sizeof(int) < sizeof(ptrdiff_t) for x86_64 so I still think ptrdiff_t is the right choice.
actually the result of pointer arithmetic, I still contend that
ptrdiff_t is not the right choice. All of what those variables are
doing is indexing an array that represent a line of pixel values. Any
reasonably large unsigned integer would be a decent choice but,
because we're looking to mimic the Java version, we'll settle for a
signed integer. Using the ptrdiff_t type implies something that's not
true (the existence of pointer arithmetic). What type does the Java
version use? I don't know Java at all but I'd be surprised if they
have a ptrdiff_t type. Whatever size integer they're using, we could
just use that...
Steven Parkes
Perhaps. zxing seems to have tended away from STL, perhaps for portability, I don't know. It might require checking to see if it's in an inner loop as well, since it's possible the dynamic allocation could have a performance impact.
But for now it's more an issue of if it's not broke, don't fix it.
> Because none of the variables in question are
> actually the result of pointer arithmetic, I still contend that
> ptrdiff_t is not the right choice.
ptrdiff_t is a signed integral type with range on the same order as that of a pointer. And that's the same definition for valid array indices since array dereference is just pointer arithmetic.
To make the C++ code entirely equivalent to the Java, we'd use int32_t since Java always uses the same widths. But Java also can't have arrays with more than 2G elements and C++ can (not that zxing will ever use it.) Some internal operations return these types (sizeof, pointer differences) so it still makes more sense to me to use them. Word-size related bugs are not common, not as common as signedness bugs.
Gunboat Diplomat
>
> Perhaps. zxing seems to have tended away from STL, perhaps for portability, I don't know. It might require checking to see if it's in an inner loop as well, since it's possible the dynamic allocation could have a performance impact.
>
> But for now it's more an issue of if it's not broke, don't fix it.
you mention it, I'm pretty sure I had to change this for VC++ and had
forgotten about it. I can't find that change now but I've also
jettisoned everything that wasn't QR code decoding so it might have
been in one of those files...
I get the impression that portability is a greater priority for zxing
than performance. If so then then it really is "broke" because VC++
doesn't support this extension. So far, it appears that the STL,
which is part of the C++ standard, is more portable than compiler
extensions...
Besides, as far as I can tell, zxing doesn't shy away from the STL at
all. Hell, even the Array type (in common/Array.h) uses std::vector
as its underlying container!
Unless you are actually trying to spite MS programmers, it would be
better form to avoid non-standard extensions. What is the name of
this forum thread?
> > Because none of the variables in question are
> > actually the result of pointer arithmetic, I still contend that
> > ptrdiff_t is not the right choice.
>
> ptrdiff_t is a signed integral type with range on the same order as that of a pointer. And that's the same definition for valid array indices since array dereference is just pointer arithmetic.
>
> To make the C++ code entirely equivalent to the Java, we'd use int32_t since Java always uses the same widths. But Java also can't have arrays with more than 2G elements and C++ can (not that zxing will ever use it.) Some internal operations return these types (sizeof, pointer differences) so it still makes more sense to me to use them. Word-size related bugs are not common, not as common as signedness bugs.
both type int and ptrdiff_t are signed but... whatever. ptrdiff_t is
not a bad choice, I just think it's misleading 'cause it implies
something that isn't true (pointer arithmetic). Plain type int is
similarly signed, is big enough, the virgin values appear to be of
that same type (I didn't trace back too far) and are only ever used to
generate values that are passed into BitMatrix::get() which, currently
does do array indexing but needn't necessarily. Correct me if I'm
wrong but type int will always be smaller than ptrdiff_t so even if
BitMatrix::get() does take that type, passing it a type int will never
result in an error...
What type does the Java implementation of class BitMatrix's methods
take?
Steven Parkes
I think it's in the 1D codes.
> I get the impression that portability is a greater priority for zxing
> than performance.
True. It'd have to be a significant performance difference to outweigh portability. I really doubt it is, but it's worth sanity-checking. Glancing at the Java code should make it clear quickly.
> If so then then it really is "broke" because VC++
> doesn't support this extension.
Sure. I haven't seen anyone raise VC++ issues. I support making it compatible if someone cares enough to file a bug. I only stumbled across it because I was tweaking the warnings to make the compilation more conservative.
> So far, it appears that the STL,
> which is part of the C++ standard, is more portable than compiler
> extensions…
Yeah. I don't know the history here. There are a number of classes in zxing that are pretty close to duplicates of STL. Not sure why STL wasn't used. Not sure if perhaps originally not requiring STL was a goal (but as you mention, as Array now uses std::vector, there is an STL dependence).
> Unless you are actually trying to spite MS programmers
Nope. I don't know when that code was written. It might simply have been an oversight, added without noticing it was an extension since the warnings that would have surfaced it weren't turned on.
I looked at making zxing compile with -pedantic but personally tabled it because I didn't really have a need and as I recall, it was more than just a few lines of code. Don't think I ever did compare the C++ to the Java in those cases. Now I'm a little curious …
In any case, I for one would welcome a patch …
As to the ptrdiff_t issue, in the the case of zxing where commonality with the Java is valuable, I wouldn't object to using int32_t and never use int or size_t. It limits some things, but only in the theoretical sense. There's nothing in zxing that I'm aware of the would benefit from taking advantage of a 64 bit architecture.
> ptrdiff_t is
> not a bad choice, I just think it's misleading 'cause it implies
> something that isn't true (pointer arithmetic)
Personally, I think you're taking too literal of an interpretation of the name. The name matters less. What matters is what it is, which is the signed type of the same width as size_t (at least in every case I know of).
Mixing operands that differ in both signed-ness and width at the same time can be the source of lots of bugs. (Google around … not only will you find people talking about this, at least some of the high ranked search results have their own subtle bugs.)
The rule of thumb is for things that use lengths and indexes, use same-width pairs: e.g., int/unsigned, int32_t/uint32_t, ptrdiff_t/size_t.
If you use size_t and think your collections scale up in size on 64 bit architectures but then use int to represent indexes or index arithmetic, you're likely to have bugs if you ever do scale up over 2G elements. If you're going to use int for indexes, you should use unsigned for sizes, not size_t.
The Java code uses int everywhere because it is, in some sense, the natural size of collections in Java. There are a lot of places in the zxing code where shorts and maybe even bytes could be used. But people don't really bother to be too precise. On the other hand, longs aren't used because Java collections don't deal in longs. So int is the correct native type.
C doesn't have a standard width and size_t and ptrdiff_t were created as types that would represent the natural/maximum sizes for arrays (and in essence, all collections) for the implementation. You can use other pairs as long as your consistent and you don't go over the bounds of size_t/ptrdiff_t.
Gunboat Diplomat
> > If so then then it really is "broke" because VC++
> > doesn't support this extension.
>
> Sure. I haven't seen anyone raise VC++ issues. I support making it compatible if someone cares enough to file a bug. I only stumbled across it because I was tweaking the warnings to make the compilation more conservative.
>
> > So far, it appears that the STL,
> > which is part of the C++ standard, is more portable than compiler
> > extensions…
>
> Yeah. I don't know the history here. There are a number of classes in zxing that are pretty close to duplicates of STL. Not sure why STL wasn't used. Not sure if perhaps originally not requiring STL was a goal (but as you mention, as Array now uses std::vector, there is an STL dependence).
class appears to be a reference counted version of class vector. They
could probably have just multiply inherited from both std::vector and
class zxing::Counted but I guess they weren't feeling that brave and
opted to simply created a condom thin wrapper...
> I looked at making zxing compile with -pedantic but personally tabled it because I didn't really have a need and as I recall, it was more than just a few lines of code. Don't think I ever did compare the C++ to the Java in those cases. Now I'm a little curious …
>
> In any case, I for one would welcome a patch …
patch? I'm just some random guy who walked in off the street...
> As to the ptrdiff_t issue, in the the case of zxing where commonality with the Java is valuable, I wouldn't object to using int32_t and never use int or size_t. It limits some things, but only in the theoretical sense. There's nothing in zxing that I'm aware of the would benefit from taking advantage of a 64 bit architecture.
>
> > ptrdiff_t is
> > not a bad choice, I just think it's misleading 'cause it implies
> > something that isn't true (pointer arithmetic)
>
> Personally, I think you're taking too literal of an interpretation of the name. The name matters less. What matters is what it is, which is the signed type of the same width as size_t (at least in every case I know of).
look a little more clear and inviting to developers new to the
project. I feel like I can relate to their point of view (if you can
imagine why). Obviously readability is somewhat subjective but I just
wanted to throw my opinion out there... for funzies...
Steven Parkes
> class appears to be a reference counted version of class vector.
Ah, right. I remember now. Ref/Counted are intrusive. C++11 adds non-intrusive std::shared_ptr (based on boost::shared_ptr which I'm familiar with.) Maybe some day we can switch to that.
karol
have you got the QR reading working on Windows? I've suceeded to
compile it using mingw, but still not fully working.
Karol
On Jan 27, 3:44 am, Gunboat Diplomat <nerdyvi...@gmail.com> wrote:
> > Has anyone been abloe to build zxing onWindowsusing Visual C++ and
> > and adding all the source code in the zxing\cpp\core\src\zxing
> > directory and below ?
>
> do. The only issues I had were that certain floating point constants
> (INFINITY and NaN) that exist for GNU's implementation of math.h don't
> exist for Microsoft's and there was no Unicode support, which is
> > Has anyone been able to use the cpp port of zxing with aWindows
> > application ? I am particularly looking for the ability to decode
karol
Borland C Builder (however, with C Builder you should be able to do
that after doing several changes to code)..
I've started to test the zxing C++ port on Windows but unfortunately
still no luck getting it fully working, but I was able to compile it
and create the .lib ..
The config is as following :
- mingw (without mingw I see no chance to get it working properly on
Windows)
- Python for SCons and crossmingw script
- Patience :)
AND
- Indigo Eclipse IDE for C/C++ Developers
You should be able to start developing. What I was unable to do is to
compile the app with imagemagickx .. But to be honest, I do not want
to use imagemagickx, I want to use a different library.
But what I'm missing : The fully working samples to read QR codes. Is
there a chance to get some samples without imagemagickx? Have you
suceeeded to compile on Windows?
Have a nice day!
Karol
On Jan 26, 4:35 pm, eldiener <edie...@agiletech.com> wrote:
> Has anyone been abloe to build zxing onWindowsusing Visual C++ and
> and adding all the source code in the zxing\cpp\core\src\zxing
> directory and below ?
>
> Has anyone been able to use the cpp port of zxing with aWindows
> application ? I am particularly looking for the ability to decode
>
> Thanks !
Gunboat Diplomat
> compile it using mingw, but still not fully working.
using the Microsoft compiler and IDE...
> It seems, that the zxing is not easy-to-compile using Visual Studio or
> Borland C Builder (however, with C Builder you should be able to do
> that after doing several changes to code)..
>
> I've started to test the zxing C++ port on Windows but unfortunately
> still no luck getting it fully working, but I was able to compile it
> and create the .lib ..
> The config is as following :
> - mingw (without mingw I see no chance to get it working properly on
> Windows)
> - Python for SCons and crossmingw script
> - Patience :)
>
> AND
>
> - Indigo Eclipse IDE for C/C++ Developers
with the provided build tools (scons and anything related to mingw),
(manually!) stuck all the source files into the MS IDE, set a couple
of reasonable build settings and simulated a couple of differences
between the UNIX environment and Microsoft's...
> You should be able to start developing. What I was unable to do is to
> compile the app with imagemagickx .. But to be honest, I do not want
> to use imagemagickx, I want to use a different library.
binaries for it and I didn't want to compile it myself (I was too busy
with zxing itself!) so I just used another image library that I
happened to have lying around. If you look at the code, you'll see
that the only place ImageMagick is used is in the implementation of
class MagickBitmapSource, which is a subtype of the abstract class
LuminanceSource. All you have to do to use another image library is
implement your own child of LuminanceSource and use that instead of
MagickBitmapSource...
> But what I'm missing : The fully working samples to read QR codes. Is
> there a chance to get some samples without imagemagickx? Have you
> suceeeded to compile on Windows?
correctly! ...as far as I can tell. From what I've heard, the working
port didn't decode all the test data either. I've taken a look at the
test data and the images where it fails were very... challenging, for
lack of a better term. I have more tests to do but it looks like
zxing will do for my purposes!
There are a lot of caveats for building zxing for Windows and I'm
currently discussing them with (who appears to be) the port maintainer
on various threads in this forum...
It will be subtly difficult to build a Windows DLL out of the current
zxing C++ port because DLL's have their own heap (and thus heap
managers) and zxing is not very strict with memory management. If
memory is allocated by the DLL and freed by the executable or vice
versa then heap corruption will occur. From what I've seen of the
code, it will almost work but I think there are a couple of places
where this cross allocation/deallocation occurs or potentially
occurs...
Even if you were to compile a static library, there may still be
difficulties in binary compatibilities. If a project happens to be
compiled with the same compiler as the zxing static library, it will
probably just work. However, because there's no standard for C++ name
mangling and zxing uses a pure C++ interface, if the library (static
or otherwise) were compiled with a different compiler than your
project, the export symbols are unlikely to match and linking will
fail...
Typically, portable libraries have well defined interfaces (like
having a separate include directory), strict policies on memory
management and a C interface with perhaps a C++ wrapper around it.
What I've done with my project is simply added the zxing code as part
of my code base. It sounds terrible but at least it's guaranteed to
work!
I hope all this helps!