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.
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
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
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:-(
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@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/fedora-mingw
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@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/fedora-mingw
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?
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 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?
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.
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
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.
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 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%40... and we discuss many way that this not possible.
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%40... 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 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%40... 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:-().
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
On Tue, May 19, 2009 at 1:09 PM, Fridrich Strba fridrich.strba@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
/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@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
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.
On Wed, May 20, 2009 at 9:31 AM, Richard W.M. Jones rjones@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.
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
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
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?
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 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.
See also:
http://www.redhat.com/archives/fedora-devel-list/2009-April/thread.html#0193...
-
Erik van Pienbroek -
Farkas Levente -
Fridrich Strba -
Kevin Kofler -
NightStrike -
Richard W.M. Jones