You could check what version of
libgdiplus(https://github.com/mono/libgdiplus) did Debian Squeeze
include, and try to run a custom new mono built from sources, with an
older libgdiplus, to confirm that it is a libgdiplus regression. If it
is, then after that you could try to bisect the commit
I have this version on squeeze:
ii libgdiplus 2.10-3+b1
armelinterface library for System.Drawing of Mono
And this version on unstable:
ii libgdiplus
3.12-0xamarin1+jpeg62.1
Hello Alex.
I have followed those instructions and done a dist-upgrade, but after
re-compiling with mcs the problem persists unchanged. I have the
following versions now:
[11:38:29][blindcoder@flora:~/Downloads/PZ/MapMap]$ mcs --version
Mono C# compiler version 4.0.1.0
Hello.
I have a problem with PNG transparancy in mono on current Debian
Unstable.
I created a small example (4 kB download) with minimal code and two
example images:
https://oc.anderdonau.de/index.php/s/VwTAlcjETG6j3XP
Running this example on a current Debian Unstable results in this - bad
It works fine here with latest Mono 4.0.1.44 on Ubuntu. Can you try upgrading
to latest Mono from Xamarin by following
http://www.mono-project.com/docs/getting-started/install/linux/#debian-ubuntu-and-derivatives
?
I suspect this has something to do with libgdiplus (the native library most of
There aren't that many commits for pngcodec.c in the last 4 years (which is
when 2.10 was tagged), so it's probably one of those:
https://github.com/mono/libgdiplus/commits/master/src/pngcodec.c . Shouldn't be
too hard to figure out which one broke your scenario.
-- Alex
To: kno...@gmail.com
Alright, I compiled libgdiplus 2.10 and put it into /opt/libgdiplus2.10/
I then did the following:
LD_LIBRARY_PATH=/opt/libgdiplus2.10/lib/
export LD_LIBRARY_PATH
./transparancy.exe
And it works fine. So I guess there is a regression somewhere in
libgdiplus between 2.10 and today.
Am
AFAIR libgdiplus delegates to libpng reading the bitmap, probably libpng is
returning something different from the usual on Debian unstable for your
image. Did you try with other images, or with a trunk/older version of
libpng?
On Tue, Jun 9, 2015, 06:40 Benjamin Schieder benja...@anderdonau.de
Hello Rafael.
I have already established that it is most certainly a regression in
libgdiplus. Using an older version (2.10) with the current mono runtime
by overriding LD_LIBRARY_PATH to the 2.10 libgdiplus binary brings a
correct result.
Kind regards,
Benjamin
Am 2015-06-09 12:42,
I have found the bad commit (and learned how to use git bisect in the
process):
[01:04:04][blindcoder@flora:~/Downloads/libgdiplus]$ git bisect bad
59ca17e56adb8555e9b4e0960b771f2849f6366f is the first bad commit
commit 59ca17e56adb8555e9b4e0960b771f2849f6366f
Author: Dick Porter d...@acm.org
I have some legacy xsl sheets that use the XslCompiledTransform class but
they fail to load because they have VB code in them. Can these work with
Mono? If so, how?
--
--
This message contains confidential information and is intended only for the
individual
I'm pretty much happy that I got a usable workaround.
Also, those bugs don't actually exist so it'd be difficult for someone
with literally zero knowledge about the internal workings of libgdiplus
or mono to do either.
https://bugzilla.xamarin.com/show_bug.cgi?id=324503
Hey,
https://bugzilla.novell.com/show_bug.cgi?id=324503
https://bugzilla.novell.com/show_bug.cgi?id=426305
Are the droids you're looking for.
On 9 Jun 2015 5:08 pm, Benjamin Schieder benja...@anderdonau.de wrote:
I'm pretty much happy that I got a usable workaround.
Also, those bugs don't
Good job, now you should file the bug in http://bugzilla.xamarin.com/
and find a way to fix the bug in a way in which it doesn't make bug
426305 or 324503 reappear.
On 09/06/15 13:09, Benjamin Schieder wrote:
I have found the bad commit (and learned how to use git bisect in the
process):
14 matches
Mail list logo
