9:19 a.m.
hi,
it's turn out mingw32-libjpeg can't be used since it's contains a few
typedef (INT32, boolean) which already defined in w32api so it's works as a
native lib but not as mingw32 lib. i'd like to make a patch for this. what's
the recommended way for this:
- should i apply a patch which simply remove these typedefs or
- add an extra ifdef for these typedef (and which ifdef use for this
purpose)?
thanks.
--
Levente "Si vis pacem para bellum!"
9:53 a.m.
Farkas Levente wrote:
it's turn out mingw32-libjpeg can't be used since it's
contains a few
typedef (INT32, boolean) which already defined in w32api so it's works as
a native lib but not as mingw32 lib. i'd like to make a patch for this.
what's the recommended way for this:
- should i apply a patch which simply remove these typedefs or
- add an extra ifdef for these typedef (and which ifdef use for this
purpose)?
Please see the existing discussion on this issue, somebody already wanted to
patch mingw32-libjpeg that way, but libjpeg upstream said it's wrong,
changing those typedefs breaks ABI compatibility.
Kevin Kofler
10:20 a.m.
Op vrijdag 15-05-2009 om 16:53 uur [tijdzone +0200], schreef Kevin
Kofler:
Please see the existing discussion on this issue, somebody already
wanted to
patch mingw32-libjpeg that way, but libjpeg upstream said it's wrong,
changing those typedefs breaks ABI compatibility.
With the current state, the ABI is undefined anyway for Win32 targets,
so the question is what the libjpeg people actually think that the
datatype should be. When we've got an answer to that question we can
decide how to fix the issue.
Regards,
Erik van Pienbroek
1:15 p.m.
Erik van Pienbroek wrote:
Op vrijdag 15-05-2009 om 16:53 uur [tijdzone +0200], schreef Kevin
Kofler:
> Please see the existing discussion on this issue, somebody already wanted to
> patch mingw32-libjpeg that way, but libjpeg upstream said it's wrong,
> changing those typedefs breaks ABI compatibility.
With the current state, the ABI is undefined anyway for Win32 targets,
so the question is what the libjpeg people actually think that the
datatype should be. When we've got an answer to that question we can
decide how to fix the issue.
but until then it's currently unusable:-(
--
Levente "Si vis pacem para bellum!"
4 p.m.
Why not to read the README in the sources concerning win32 and do
exactly what they suggest?
Fridrich
On Fri, 2009-05-15 at 16:19 +0200, Farkas Levente wrote:
hi,
it's turn out mingw32-libjpeg can't be used since it's contains a few
typedef (INT32, boolean) which already defined in w32api so it's works
as a native lib but not as mingw32 lib. i'd like to make a patch for
this. what's the recommended way for this:
- should i apply a patch which simply remove these typedefs or
- add an extra ifdef for these typedef (and which ifdef use for this
purpose)?
thanks.
--
Levente "Si vis pacem para bellum!"
_______________________________________________
fedora-mingw mailing list
fedora-mingw(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/fedora-mingw
4:56 a.m.
I meant the install.doc document
Cheers
Fridrich
On Fri, 2009-05-15 at 23:00 +0200, Fridrich Strba wrote:
Why not to read the README in the sources concerning win32 and do
exactly what they suggest?
Fridrich
On Fri, 2009-05-15 at 16:19 +0200, Farkas Levente wrote:
> hi,
> it's turn out mingw32-libjpeg can't be used since it's contains a few
> typedef (INT32, boolean) which already defined in w32api so it's works
> as a native lib but not as mingw32 lib. i'd like to make a patch for
> this. what's the recommended way for this:
> - should i apply a patch which simply remove these typedefs or
> - add an extra ifdef for these typedef (and which ifdef use for this
> purpose)?
> thanks.
>
> --
> Levente "Si vis pacem para bellum!"
> _______________________________________________
> fedora-mingw mailing list
> fedora-mingw(a)lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/fedora-mingw
8:19 a.m.
Fridrich Strba wrote:
I meant the install.doc document
Cheers
Fridrich
On Fri, 2009-05-15 at 23:00 +0200, Fridrich Strba wrote:
> Why not to read the README in the sources concerning win32 and do
> exactly what they suggest?
>
> Fridrich
>
> On Fri, 2009-05-15 at 16:19 +0200, Farkas Levente wrote:
>> hi,
>> it's turn out mingw32-libjpeg can't be used since it's contains a
few
>> typedef (INT32, boolean) which already defined in w32api so it's works
>> as a native lib but not as mingw32 lib. i'd like to make a patch for
>> this. what's the recommended way for this:
>> - should i apply a patch which simply remove these typedefs or
>> - add an extra ifdef for these typedef (and which ifdef use for this
>> purpose)?
>> thanks.
ok we rtfm:-) so we fix it.
may i apply this patch to the fedora cvs?
--
Levente "Si vis pacem para bellum!"
Index: jpeg-mingw32.patch
===================================================================
RCS file: /cvs/pkgs/rpms/mingw32-libjpeg/devel/jpeg-mingw32.patch,v
retrieving revision 1.1
diff -u -r1.1 jpeg-mingw32.patch
--- jpeg-mingw32.patch 30 Jan 2009 11:48:26 -0000 1.1
+++ jpeg-mingw32.patch 19 May 2009 13:17:56 -0000
@@ -1,7 +1,6 @@
-diff -rup jpeg-6b/makefile.cfg jpeg-6b.new/makefile.cfg
---- jpeg-6b/makefile.cfg 2008-09-09 09:54:38.000000000 -0400
-+++ jpeg-6b.new/makefile.cfg 2008-09-09 09:55:03.000000000 -0400
-@@ -169,7 +169,7 @@ libjpeg.a: @A2K_DEPS@ $(LIBOBJECTS)
+--- ./makefile.cfg.mingw32 2009-05-19 14:56:43.000000000 +0200
++++ ./makefile.cfg 2009-05-19 14:56:43.000000000 +0200
+@@ -169,7 +169,7 @@
# with libtool:
libjpeg.la: @A2K_DEPS@ $(LIBOBJECTS)
$(LIBTOOL) --mode=link $(CC) $(CFLAGS) -o libjpeg.la $(LIBOBJECTS) \
@@ -10,3 +9,28 @@
# sample programs:
+--- ./jconfig.vc.mingw32 2009-05-19 15:02:19.000000000 +0200
++++ ./jconfig.vc 2009-05-19 15:03:51.000000000 +0200
+@@ -21,6 +21,11 @@
+ #endif
+ #define HAVE_BOOLEAN /* prevent jmorecfg.h from redefining it */
+
++/* Define "INT32" as int, not long, per Windows custom */
++#ifndef __BASETSD_H__ /* don't conflict if basetsd.h already read */
++typedef int INT32;
++#endif
++#define HAVE_INT32 /* prevent jmorecfg.h from redefining it */
+
+ #ifdef JPEG_INTERNALS
+
+--- ./jmorecfg.h.mingw32 2009-05-19 15:01:33.000000000 +0200
++++ ./jmorecfg.h 2009-05-19 15:02:07.000000000 +0200
+@@ -157,7 +157,7 @@
+
+ /* INT32 must hold at least signed 32-bit values. */
+
+-#ifndef XMD_H /* X11/xmd.h correctly defines INT32 */
++#ifndef HAVE_INT32
+ typedef long INT32;
+ #endif
+
Index: mingw32-libjpeg.spec
===================================================================
RCS file: /cvs/pkgs/rpms/mingw32-libjpeg/devel/mingw32-libjpeg.spec,v
retrieving revision 1.3
diff -u -r1.3 mingw32-libjpeg.spec
--- mingw32-libjpeg.spec 26 Feb 2009 01:14:41 -0000 1.3
+++ mingw32-libjpeg.spec 19 May 2009 13:17:56 -0000
@@ -10,7 +10,7 @@
Name: mingw32-libjpeg
Version: 6b
-Release: 10%{?dist}
+Release: 11%{?dist}
Summary: MinGW Windows Libjpeg library
License: IJG
@@ -50,7 +50,7 @@
%patch5 -p1 -b .oflo
%patch6 -p1
-%patch100 -p1
+%patch100 -p1 -b .mingw32
# For long-obsolete reasons, libjpeg 6b doesn't ship with a configure.in.
# We need to re-autoconf though, in order to update libtool support,
@@ -137,6 +137,9 @@
%changelog
+* Tue May 19 2009 Zoltan Seress <gatesofdarkness(a)gmail.com> - 6b-11.el5
+- modify jpeg-mingw32.patch to use correct typedefs on Windows
+
* Wed Feb 25 2009 Fedora Release Engineering <rel-eng(a)lists.fedoraproject.org> -
6b-10
- Rebuilt for https://fedoraproject.org/wiki/Fedora_11_Mass_Rebuild
8:51 a.m.
On Tue, May 19, 2009 at 03:19:02PM +0200, Farkas Levente wrote:
Fridrich Strba wrote:
> I meant the install.doc document
ok we rtfm:-) so we fix it.
may i apply this patch to the fedora cvs?
I don't think this patch is correct or follows Fridrich's suggestion
to look at install.doc. This really needs to be discussed with
'upstream' libjpeg -- whoever that is at the moment [see my other
email]. Please make some effort to contact them and have them make a
decision on this.
Rich.
--
Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones
New in Fedora 11: Fedora Windows cross-compiler. Compile Windows
programs, test, and build Windows installers. Over 70 libraries supprt'd
http://fedoraproject.org/wiki/MinGW http://www.annexia.org/fedora_mingw
9:15 a.m.
Richard W.M. Jones wrote:
On Tue, May 19, 2009 at 03:19:02PM +0200, Farkas Levente wrote:
> Fridrich Strba wrote:
>> I meant the install.doc document
> ok we rtfm:-) so we fix it.
> may i apply this patch to the fedora cvs?
I don't think this patch is correct or follows Fridrich's suggestion
to look at install.doc. This really needs to be discussed with
'upstream' libjpeg -- whoever that is at the moment [see my other
email]. Please make some effort to contact them and have them make a
decision on this.
we do what install.doc says,
- replace jconfig.cfg with jconfig.vc which is the visual c compiler's
config suggested by install.doc
- for INT32 we define the same way in jconfig.vc as they did for boolean
- and use HAVE_INT32 for jmorecfg.h as they used for HAVE_BOOLEAN
what's the problem?
--
Levente "Si vis pacem para bellum!"
9:18 a.m.
Farkas Levente wrote:
Richard W.M. Jones wrote:
> On Tue, May 19, 2009 at 03:19:02PM +0200, Farkas Levente wrote:
>> Fridrich Strba wrote:
>>> I meant the install.doc document
>> ok we rtfm:-) so we fix it.
>> may i apply this patch to the fedora cvs?
> I don't think this patch is correct or follows Fridrich's suggestion
> to look at install.doc. This really needs to be discussed with
> 'upstream' libjpeg -- whoever that is at the moment [see my other
> email]. Please make some effort to contact them and have them make a
> decision on this.
we do what install.doc says,
- replace jconfig.cfg with jconfig.vc which is the visual c compiler's
config suggested by install.doc
- for INT32 we define the same way in jconfig.vc as they did for boolean
- and use HAVE_INT32 for jmorecfg.h as they used for HAVE_BOOLEAN
what's the problem?
ohh i send a half patch last time.
--
Levente "Si vis pacem para bellum!"
Index: configure.in
===================================================================
RCS file: /cvs/pkgs/rpms/mingw32-libjpeg/devel/configure.in,v
retrieving revision 1.1
diff -u -r1.1 configure.in
--- configure.in 30 Jan 2009 11:48:26 -0000 1.1
+++ configure.in 19 May 2009 14:16:40 -0000
@@ -1,7 +1,7 @@
dnl IJG auto-configuration source file.
dnl Process this file with autoconf to produce a configure script.
AC_INIT(jcmaster.c)
-AC_CONFIG_HEADER(jconfig.h:jconfig.cfg)
+AC_CONFIG_HEADER(jconfig.h:jconfig.vc)
dnl
dnl do these first since other macros rely on them
AC_PROG_CC
Index: jpeg-mingw32.patch
===================================================================
RCS file: /cvs/pkgs/rpms/mingw32-libjpeg/devel/jpeg-mingw32.patch,v
retrieving revision 1.1
diff -u -r1.1 jpeg-mingw32.patch
--- jpeg-mingw32.patch 30 Jan 2009 11:48:26 -0000 1.1
+++ jpeg-mingw32.patch 19 May 2009 14:16:40 -0000
@@ -1,7 +1,6 @@
-diff -rup jpeg-6b/makefile.cfg jpeg-6b.new/makefile.cfg
---- jpeg-6b/makefile.cfg 2008-09-09 09:54:38.000000000 -0400
-+++ jpeg-6b.new/makefile.cfg 2008-09-09 09:55:03.000000000 -0400
-@@ -169,7 +169,7 @@ libjpeg.a: @A2K_DEPS@ $(LIBOBJECTS)
+--- ./makefile.cfg.mingw32 2009-05-19 14:56:43.000000000 +0200
++++ ./makefile.cfg 2009-05-19 14:56:43.000000000 +0200
+@@ -169,7 +169,7 @@
# with libtool:
libjpeg.la: @A2K_DEPS@ $(LIBOBJECTS)
$(LIBTOOL) --mode=link $(CC) $(CFLAGS) -o libjpeg.la $(LIBOBJECTS) \
@@ -10,3 +9,28 @@
# sample programs:
+--- ./jconfig.vc.mingw32 2009-05-19 15:02:19.000000000 +0200
++++ ./jconfig.vc 2009-05-19 15:03:51.000000000 +0200
+@@ -21,6 +21,11 @@
+ #endif
+ #define HAVE_BOOLEAN /* prevent jmorecfg.h from redefining it */
+
++/* Define "INT32" as int, not long, per Windows custom */
++#ifndef __BASETSD_H__ /* don't conflict if basetsd.h already read */
++typedef int INT32;
++#endif
++#define HAVE_INT32 /* prevent jmorecfg.h from redefining it */
+
+ #ifdef JPEG_INTERNALS
+
+--- ./jmorecfg.h.mingw32 2009-05-19 15:01:33.000000000 +0200
++++ ./jmorecfg.h 2009-05-19 15:02:07.000000000 +0200
+@@ -157,7 +157,7 @@
+
+ /* INT32 must hold at least signed 32-bit values. */
+
+-#ifndef XMD_H /* X11/xmd.h correctly defines INT32 */
++#ifndef HAVE_INT32
+ typedef long INT32;
+ #endif
+
Index: mingw32-libjpeg.spec
===================================================================
RCS file: /cvs/pkgs/rpms/mingw32-libjpeg/devel/mingw32-libjpeg.spec,v
retrieving revision 1.3
diff -u -r1.3 mingw32-libjpeg.spec
--- mingw32-libjpeg.spec 26 Feb 2009 01:14:41 -0000 1.3
+++ mingw32-libjpeg.spec 19 May 2009 14:16:40 -0000
@@ -10,7 +10,7 @@
Name: mingw32-libjpeg
Version: 6b
-Release: 10%{?dist}
+Release: 11%{?dist}
Summary: MinGW Windows Libjpeg library
License: IJG
@@ -50,7 +50,7 @@
%patch5 -p1 -b .oflo
%patch6 -p1
-%patch100 -p1
+%patch100 -p1 -b .mingw32
# For long-obsolete reasons, libjpeg 6b doesn't ship with a configure.in.
# We need to re-autoconf though, in order to update libtool support,
@@ -137,6 +137,9 @@
%changelog
+* Tue May 19 2009 Zoltan Seress <gatesofdarkness(a)gmail.com> - 6b-11.el5
+- modify jpeg-mingw32.patch to use correct typedefs on Windows
+
* Wed Feb 25 2009 Fedora Release Engineering <rel-eng(a)lists.fedoraproject.org> -
6b-10
- Rebuilt for https://fedoraproject.org/wiki/Fedora_11_Mass_Rebuild
2:20 p.m.
Yeah, but it is what the upstream recommends and what virtually all
win32 jpeg packages distributed out there do. So, it is consistent with
the jpeg win32 ABI :)
Cheers
F.
On Tue, 2009-05-19 at 21:04 +0200, Kevin Kofler wrote:
Fridrich Strba wrote:
> Just out of curiosity: this is what I do in my packages.
And this one changes the ABI.
Looks like there's really no good solution here. :-(
Kevin Kofler
2:09 p.m.
Fridrich Strba wrote:
Yeah, but it is what the upstream recommends and what virtually all
win32 jpeg packages distributed out there do. So, it is consistent with
the jpeg win32 ABI :)
Cheers
F.
On Tue, 2009-05-19 at 21:04 +0200, Kevin Kofler wrote:
> Fridrich Strba wrote:
>> Just out of curiosity: this is what I do in my packages.
> And this one changes the ABI.
>
> Looks like there's really no good solution here. :-(
so what's our position now?
it seems upstream wouldn't like to (and probably can't solve without
break something).
but currently fedora's mingw32-libjpeg worse then any other precompiled
windows mingw libjpeg, since other at least works and has a long
history, but ours can't be used. imho if we switch to the tor
lillqvist's version than it'd be much better then the current status.
--
Levente "Si vis pacem para bellum!"
3:22 p.m.
On Wed, Jun 17, 2009 at 09:09:45PM +0200, Farkas Levente wrote:
so what's our position now?
it seems upstream wouldn't like to (and probably can't solve without
break something).
Have you talked to upstream about this? Please point us to
the upstream discussion on their mailing lists.
Rich.
--
Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones
virt-p2v converts physical machines to virtual machines. Boot with a
live CD or over the network (PXE) and turn machines into Xen guests.
http://et.redhat.com/~rjones/virt-p2v
3:40 p.m.
Richard W.M. Jones wrote:
On Wed, Jun 17, 2009 at 09:09:45PM +0200, Farkas Levente wrote:
> so what's our position now?
> it seems upstream wouldn't like to (and probably can't solve without
> break something).
Have you talked to upstream about this? Please point us to
the upstream discussion on their mailing lists.
without any response:
http://sourceforge.net/mailarchive/forum.php?thread_name=4A12C61E.9010701...
and we discuss many way that this not possible.
--
Levente "Si vis pacem para bellum!"
4:47 p.m.
On Wed, Jun 17, 2009 at 10:40:56PM +0200, Farkas Levente wrote:
Richard W.M. Jones wrote:
> On Wed, Jun 17, 2009 at 09:09:45PM +0200, Farkas Levente wrote:
>> so what's our position now?
>> it seems upstream wouldn't like to (and probably can't solve without
>> break something).
>
> Have you talked to upstream about this? Please point us to
> the upstream discussion on their mailing lists.
without any response:
http://sourceforge.net/mailarchive/forum.php?thread_name=4A12C61E.9010701...
and we discuss many way that this not possible.
There's a reason I keep going on about upstream libjpeg, not just
because I'm being difficult. It's because there's no way we, as mere
packagers, can fix this on our own. We can't even fix it if we have
the consent of SuSE, Debian and other packagers.
libjpeg has a screwy, disfunctional upstream. There's not been a real
upstream release for 11 years. Now there is someone claiming to be
the official upstream for libjpeg who isn't ready to hold open
discussions with any of the interested groups.
This can *only* be fixed by someone taking control, and making
a real upstream libjpeg which has an open, responsive governance.
This is *not* a Fedora problem.
Create a real upstream libjpeg (maybe you'll need to change the name).
Involve all the parties and packagers, make the right technical
decisions, release up to date, modern packages, and then, maybe,
mingw32-libjpeg can be a proper part of Fedora.
Rich.
--
Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones
New in Fedora 11: Fedora Windows cross-compiler. Compile Windows
programs, test, and build Windows installers. Over 70 libraries supprt'd
http://fedoraproject.org/wiki/MinGW http://www.annexia.org/fedora_mingw
3:35 a.m.
Richard W.M. Jones wrote:
On Wed, Jun 17, 2009 at 10:40:56PM +0200, Farkas Levente wrote:
> Richard W.M. Jones wrote:
>> On Wed, Jun 17, 2009 at 09:09:45PM +0200, Farkas Levente wrote:
>>> so what's our position now?
>>> it seems upstream wouldn't like to (and probably can't solve without
>>> break something).
>> Have you talked to upstream about this? Please point us to
>> the upstream discussion on their mailing lists.
> without any response:
>
http://sourceforge.net/mailarchive/forum.php?thread_name=4A12C61E.9010701...
> and we discuss many way that this not possible.
There's a reason I keep going on about upstream libjpeg, not just
because I'm being difficult. It's because there's no way we, as mere
packagers, can fix this on our own. We can't even fix it if we have
the consent of SuSE, Debian and other packagers.
libjpeg has a screwy, disfunctional upstream. There's not been a real
upstream release for 11 years. Now there is someone claiming to be
the official upstream for libjpeg who isn't ready to hold open
discussions with any of the interested groups.
This can *only* be fixed by someone taking control, and making
a real upstream libjpeg which has an open, responsive governance.
This is *not* a Fedora problem.
Create a real upstream libjpeg (maybe you'll need to change the name).
Involve all the parties and packagers, make the right technical
decisions, release up to date, modern packages, and then, maybe,
mingw32-libjpeg can be a proper part of Fedora.
in this case we've to remove mingw32-libjpeg from fedora since it's
currently unusable and there is no usable upstream. which will result
all of it's dependencies should have to be also removed (which is rather
large number:-().
--
Levente "Si vis pacem para bellum!"
12:09 p.m.
New subject: Worth considering
As you might know, many of the libraries that fedora mingw project is
packaging were already ported and built since ages by Tor Lillqvist. It
is a great proceeding before one packages a library to visit
ftp://ftp.gnome.org/pub/GNOME/binaries/win32/ and check in the *-dev
packages the directory src/tml/make that contains Tor's build scripts
with inlined patches. This might be good to avoid having different ABI
versions of the same library out there in the wild.
Cheers
Fridrich
3:28 p.m.
New subject: Worth considering
On Tue, May 19, 2009 at 1:09 PM, Fridrich Strba
<fridrich.strba(a)bluewin.ch> wrote:
As you might know, many of the libraries that fedora mingw project
is
packaging were already ported and built since ages by Tor Lillqvist. It
is a great proceeding before one packages a library to visit
ftp://ftp.gnome.org/pub/GNOME/binaries/win32/ and check in the *-dev
packages the directory src/tml/make that contains Tor's build scripts
with inlined patches. This might be good to avoid having different ABI
versions of the same library out there in the wild.
Linky no worky
8:26 p.m.
New subject: Worth considering
/me surprised. Linky worky herey.
F.
On Tue, 2009-05-19 at 16:28 -0400, NightStrike wrote:
On Tue, May 19, 2009 at 1:09 PM, Fridrich Strba
<fridrich.strba(a)bluewin.ch> wrote:
> As you might know, many of the libraries that fedora mingw project is
> packaging were already ported and built since ages by Tor Lillqvist. It
> is a great proceeding before one packages a library to visit
> ftp://ftp.gnome.org/pub/GNOME/binaries/win32/ and check in the *-dev
> packages the directory src/tml/make that contains Tor's build scripts
> with inlined patches. This might be good to avoid having different ABI
> versions of the same library out there in the wild.
Linky no worky
8:31 a.m.
New subject: Worth considering
On Wed, May 20, 2009 at 03:26:02AM +0200, Fridrich Strba wrote:
/me surprised. Linky worky herey.
It works for me too. NightStrike are you using a firewall which stops
active FTP?
Rich.
--
Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones
New in Fedora 11: Fedora Windows cross-compiler. Compile Windows
programs, test, and build Windows installers. Over 70 libraries supprt'd
http://fedoraproject.org/wiki/MinGW http://www.annexia.org/fedora_mingw
12:30 p.m.
New subject: Worth considering
On Wed, May 20, 2009 at 9:31 AM, Richard W.M. Jones <rjones(a)redhat.com> wrote:
On Wed, May 20, 2009 at 03:26:02AM +0200, Fridrich Strba wrote:
> /me surprised. Linky worky herey.
It works for me too. NightStrike are you using a firewall which stops
active FTP?
No, but I am using a chrome incognito window and getting a connection
timeout. Maybe that matters.
2:04 p.m.
Farkas Levente wrote:
ok we rtfm:-) so we fix it.
This suffers from the "different ABI depending on which header is included
first" (i.e. "first included wins") issue.
But I don't think there's a real solution as the ABI which is currently used
uses different type definitions than the rpcndr.h ones.
Kevin Kofler
2:25 p.m.
Now, the problem with the indetermination is also that the decompression
and compression routines check what is the size of the corresponding
struct according to the caller and according to the called code. In case
they are different, it bails out. So the only solution to have a working
libjpeg is to get the boolean always the same size. BTW, the size of
boolean is completely implementation defined, there is no standard what
size it should be. Normally it is the size of int (4bytes), but on win32
it is 1 byte. So, the point here is to get the size of boolean when
working with libjpeg always the same. This is what the install.doc is
advising.
Cheers
F.
On Tue, 2009-05-19 at 21:04 +0200, Kevin Kofler wrote:
Farkas Levente wrote:
> ok we rtfm:-) so we fix it.
This suffers from the "different ABI depending on which header is included
first" (i.e. "first included wins") issue.
But I don't think there's a real solution as the ABI which is currently used
uses different type definitions than the rpcndr.h ones.
Kevin Kofler
5:36 p.m.
Kevin Kofler wrote:
Farkas Levente wrote:
> ok we rtfm:-) so we fix it.
This suffers from the "different ABI depending on which header is included
first" (i.e. "first included wins") issue.
But I don't think there's a real solution as the ABI which is currently used
uses different type definitions than the rpcndr.h ones.
ok. os what to do now? facts:
- the current mingw32-libjpeg is unusable
- there is no abi compatible solution with unix
- try to be consistent ie. don't choose solution which depend on the
include file order.
- imho try to be compatible with previous windows libs (ie. Tor
Lillqvist's libs) it use:
---------------------------
#ifdef _WIN32
# include <windows.h>
/* Define "boolean" as unsigned char, not int, per Windows custom */
# if !defined __RPCNDR_H__ || defined __MINGW32__ /* don't conflict
if rpcndr.h already read */
# ifndef boolean /* don't conflict if rpcndr.h already read */
typedef unsigned char boolean;
# endif /* boolean */
# endif /* __RPCNDR_H__ */
# define HAVE_BOOLEAN /* prevent jmorecfg.h from redefining it */
# define USE_WINDOWS_MESSAGEBOX 1
#endif /* _WIN32 */
---------------------------
for INT32:
---------------------------
/* INT32 must hold at least signed 32-bit values. */
#if !defined(XMD_H) && !defined(_WIN32) /* X11/xmd.h
correctly defines INT32 */
typedef long INT32;
#endif
---------------------------
so how we patch?
--
Levente "Si vis pacem para bellum!"
7:21 a.m.
On Sat, May 23, 2009 at 12:36:49AM +0200, Farkas Levente wrote:
ok. os what to do now?
Go and ask upstream!!!
Rich.
--
Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones
virt-df lists disk usage of guests without needing to install any
software inside the virtual machine. Supports Linux and Windows.
http://et.redhat.com/~rjones/virt-df/
7:28 a.m.
Richard W.M. Jones wrote:
On Sat, May 23, 2009 at 12:36:49AM +0200, Farkas Levente wrote:
> ok. os what to do now?
Go and ask upstream!!!
i did and no one answer in the last 5 days:-(
but anyway anything batter then the current state. we've got a packages
which not usable. if we fix it in the same way as tor did it then we're
at least better.
and anyway this situation can't be solve even upstream, the most what we
can expect from them that everybody use the same hack.
--
Levente "Si vis pacem para bellum!"
4:11 a.m.
See also:
http://www.redhat.com/archives/fedora-devel-list/2009-April/thread.html#0...
--
Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones
virt-df lists disk usage of guests without needing to install any
software inside the virtual machine. Supports Linux and Windows.
http://et.redhat.com/~rjones/virt-df/
5423
days inactive
5457
days old
29 comments
6 participants
participants (6)
-
Erik van Pienbroek -
Farkas Levente -
Fridrich Strba -
Kevin Kofler -
NightStrike -
Richard W.M. Jones