libjpeg-turbo-devel

[Libjpeg-turbo-devel] problem when using jmorecfg.h and windows.h

[Vincent T. <vin...@gm...>]

hello

I'm compiling a library on Windows using libjpeg-turbo and mingw-w64
v3 (using 64 bits toolchain) and I get that error :

  CC       eet_image.lo
In file included from
C:/MinGW/msys/1.0/opt/libjpeg-turbo/include/jpeglib.h:29:0,
                 from eet_image.c:38:
C:/MinGW/msys/1.0/opt/libjpeg-turbo/include/jmorecfg.h:163:14: error:
conflicting types for 'INT32'
 typedef long INT32;
              ^
In file included from
c:\mingw\msys\1.0\opt\windows_64\x86_64-w64-mingw32\include\winnt.h:134:0,
                 from
c:\mingw\msys\1.0\opt\windows_64\x86_64-w64-mingw32\include\minwindef.h:146,
                 from
c:\mingw\msys\1.0\opt\windows_64\x86_64-w64-mingw32\include\windef.h:8,
                 from
c:\mingw\msys\1.0\opt\windows_64\x86_64-w64-mingw32\include\windows.h:69,
                 from
c:\mingw\msys\1.0\opt\windows_64\x86_64-w64-mingw32\include\winsock2.h:23,
                 from eet_image.c:30:
c:\mingw\msys\1.0\opt\windows_64\x86_64-w64-mingw32\include\basetsd.h:31:22:
note: previous declaration of 'INT32' was h
ere
   typedef signed int INT32,*PINT32;
                      ^

that library includes jpeglib.h after windows.h (if I include it
before, i get other similar errors)

in addition, INT32 and al types already exists on Windows :
http://msdn.microsoft.com/en-us/library/windows/desktop/aa383751%28v=vs.85%29.aspx

Is there a solution to that problem ?

thank you

Vincent Torri

Re: [Libjpeg-turbo-devel] problem when using jmorecfg.h and windows.h

[DRC <dco...@us...>]

How was libjpeg-turbo built?  And what version of libjpeg-turbo are you 
using?  The reason why this issue would happen is either that a very old 
version of libjpeg-turbo was being used or the wrong jconfig.h was 
included.  There's a special jconfig.h for Windows that gets generated 
with the CMake build system, and this header prevents INT32 from being 
redefined.

The larger issue-- rather than fix this in jconfig.h, I think a more 
robust solution is to fix it in jmorecfg.h like IJG does.  Further, I 
question whether the definition for INT32 specifically needs to go in 
jmorecfg.h at all, since it is not used in any distributed headers.  It 
probably needs to go in jpegint.h instead.

Either way, though, I need to be able to reproduce the issue before I 
can determine the correct fix.  Our current fix for this issue may be 
somewhat hackish, but it does work, as long as the correct files are 
distributed.


On 4/18/14 2:30 AM, Vincent Torri wrote:
> hello
>
> I'm compiling a library on Windows using libjpeg-turbo and mingw-w64
> v3 (using 64 bits toolchain) and I get that error :
>
>    CC       eet_image.lo
> In file included from
> C:/MinGW/msys/1.0/opt/libjpeg-turbo/include/jpeglib.h:29:0,
>                   from eet_image.c:38:
> C:/MinGW/msys/1.0/opt/libjpeg-turbo/include/jmorecfg.h:163:14: error:
> conflicting types for 'INT32'
>   typedef long INT32;
>                ^
> In file included from
> c:\mingw\msys\1.0\opt\windows_64\x86_64-w64-mingw32\include\winnt.h:134:0,
>                   from
> c:\mingw\msys\1.0\opt\windows_64\x86_64-w64-mingw32\include\minwindef.h:146,
>                   from
> c:\mingw\msys\1.0\opt\windows_64\x86_64-w64-mingw32\include\windef.h:8,
>                   from
> c:\mingw\msys\1.0\opt\windows_64\x86_64-w64-mingw32\include\windows.h:69,
>                   from
> c:\mingw\msys\1.0\opt\windows_64\x86_64-w64-mingw32\include\winsock2.h:23,
>                   from eet_image.c:30:
> c:\mingw\msys\1.0\opt\windows_64\x86_64-w64-mingw32\include\basetsd.h:31:22:
> note: previous declaration of 'INT32' was h
> ere
>     typedef signed int INT32,*PINT32;
>                        ^
>
> that library includes jpeglib.h after windows.h (if I include it
> before, i get other similar errors)
>
> in addition, INT32 and al types already exists on Windows :
> http://msdn.microsoft.com/en-us/library/windows/desktop/aa383751%28v=vs.85%29.aspx
>
> Is there a solution to that problem ?
>
> thank you
>
> Vincent Torri

Re: [Libjpeg-turbo-devel] problem when using jmorecfg.h and windows.h

[Vincent T. <vin...@gm...>]

hello

On Fri, Apr 18, 2014 at 10:36 AM, DRC <dco...@us...> wrote:
> How was libjpeg-turbo built?

MSYS + mingw-w64
./configure --host=x86_64-w64-mingw32 --disable-static


>  And what version of libjpeg-turbo are you
> using?

latest one, downloaded this morning

>  The reason why this issue would happen is either that a very old
> version of libjpeg-turbo was being used or the wrong jconfig.h was
> included.  There's a special jconfig.h for Windows that gets generated
> with the CMake build system, and this header prevents INT32 from being
> redefined.

indeed, if CMake is the preferred solution to build libjpeg-turbo on
Windows, then it might be the problem. I can provide autotool stuff to
fix that, if you tell me what is needed.

> The larger issue-- rather than fix this in jconfig.h, I think a more
> robust solution is to fix it in jmorecfg.h like IJG does.  Further, I
> question whether the definition for INT32 specifically needs to go in
> jmorecfg.h at all, since it is not used in any distributed headers.  It
> probably needs to go in jpegint.h instead.

imho (and I've tell that to Guido several times, but he doesn't want
to understand, that's why I try with libjpeg-turbo), defining types
that are used by OS is a very bad idea.

> Either way, though, I need to be able to reproduce the issue before I
> can determine the correct fix.  Our current fix for this issue may be
> somewhat hackish, but it does work, as long as the correct files are
> distributed.

not tested, bu i think that this will reproduce the problem :

1) with MSYS + mingw-w64 (see win-builds.org for example) install
libjpeg-turbo like me (see above)
2) then this test example :

#include <windows.h>
#include <jpeglib.h>

int main() { return 0; }

Vincent Torri

>
>
> On 4/18/14 2:30 AM, Vincent Torri wrote:
>> hello
>>
>> I'm compiling a library on Windows using libjpeg-turbo and mingw-w64
>> v3 (using 64 bits toolchain) and I get that error :
>>
>>    CC       eet_image.lo
>> In file included from
>> C:/MinGW/msys/1.0/opt/libjpeg-turbo/include/jpeglib.h:29:0,
>>                   from eet_image.c:38:
>> C:/MinGW/msys/1.0/opt/libjpeg-turbo/include/jmorecfg.h:163:14: error:
>> conflicting types for 'INT32'
>>   typedef long INT32;
>>                ^
>> In file included from
>> c:\mingw\msys\1.0\opt\windows_64\x86_64-w64-mingw32\include\winnt.h:134:0,
>>                   from
>> c:\mingw\msys\1.0\opt\windows_64\x86_64-w64-mingw32\include\minwindef.h:146,
>>                   from
>> c:\mingw\msys\1.0\opt\windows_64\x86_64-w64-mingw32\include\windef.h:8,
>>                   from
>> c:\mingw\msys\1.0\opt\windows_64\x86_64-w64-mingw32\include\windows.h:69,
>>                   from
>> c:\mingw\msys\1.0\opt\windows_64\x86_64-w64-mingw32\include\winsock2.h:23,
>>                   from eet_image.c:30:
>> c:\mingw\msys\1.0\opt\windows_64\x86_64-w64-mingw32\include\basetsd.h:31:22:
>> note: previous declaration of 'INT32' was h
>> ere
>>     typedef signed int INT32,*PINT32;
>>                        ^
>>
>> that library includes jpeglib.h after windows.h (if I include it
>> before, i get other similar errors)
>>
>> in addition, INT32 and al types already exists on Windows :
>> http://msdn.microsoft.com/en-us/library/windows/desktop/aa383751%28v=vs.85%29.aspx
>>
>> Is there a solution to that problem ?
>>
>> thank you
>>
>> Vincent Torri
>
> ------------------------------------------------------------------------------
> Learn Graph Databases - Download FREE O'Reilly Book
> "Graph Databases" is the definitive new guide to graph databases and their
> applications. Written by three acclaimed leaders in the field,
> this first edition is now available. Download your free book today!
> http://p.sf.net/sfu/NeoTech
> _______________________________________________
> Libjpeg-turbo-devel mailing list
> Lib...@li...
> https://lists.sourceforge.net/lists/listinfo/libjpeg-turbo-devel

Re: [Libjpeg-turbo-devel] problem when using jmorecfg.h and windows.h

[DRC <dco...@us...>]

On 4/18/14 3:53 AM, Vincent Torri wrote:
> indeed, if CMake is the preferred solution to build libjpeg-turbo on
> Windows, then it might be the problem. I can provide autotool stuff to
> fix that, if you tell me what is needed.

I'm actually surprised that our code built at all with autotools and 
MinGW, and I'd be even more surprised if it actually ran.  Maybe it 
works under MSYS, but it definitely doesn't work when cross-compiling 
using MinGW on Linux.  The resulting DLL contains bogus dependency 
information and won't execute.

Autotools and MinGW has never been a supported configuration for 
libjpeg-turbo.  I don't understand why you can't use CMake to build our 
code.  It doesn't require you to use CMake to build your application-- 
just the JPEG library.

There's a lot more to getting autotools to work with Windows builds, and 
even if we could get it working, that configuration would never be 
tested, so it would be prone to breakage.  The larger issue is-- if 
users expect it to work, then I'm expected to support it, and I'm not in 
a good position to do so.  I definitely do not want some other project's 
build instructions for our code to include something that isn't supported.

I am open to being convinced otherwise, if you have a compelling 
arguments that demonstrates why autotools is necessary in some cases.  I 
would still not be willing to officially document or support it, but if 
you absolutely do need to use autotools, then I'd be willing to check in 
an unsupported patch to jconfig.h.in, if that is sufficient to fix this 
issue.

Re: [Libjpeg-turbo-devel] problem when using jmorecfg.h and windows.h

[DRC <dco...@us...>]

This was fixed a long time ago (in 1.2 beta.)  How are you building 
libjpeg-turbo, or where are you getting your build?

I'm suspicious of the fact that your build of libjpeg-turbo resides in 
c:/MinGW/msys/1.0/opt/libjpeg-turbo.  /opt/libjpeg-turbo is generally 
used for Unix builds, not Windows builds.  Methinks someone may have 
gotten too creative with distributing or building our code.

The Windows versions of libjpeg-turbo (except for Cygwin, which is 
treated as a Unix build) are built with CMake instead of autotools, and 
the CMake build system generates a special version of jconfig.h just for 
Windows.  That special version of jconfig.h includes code to work around 
the INT32 conflict.  Note that IJG also has their own fix for this 
issue, in jmorecfg.h.  Their fix, however, does not work if jpeglib.h is 
included before windows.h.  Ours does.  Also, it made more sense to me 
to include our fix in a header that was only distributed on Windows, but 
if a distributor included the wrong version of jconfig.h in the 
distribution, then the problem you're observing could occur.  I suspect 
you might just be using an old version.  Install our official package 
(libjpeg-turbo-gcc64.exe), which puts libjpeg-turbo in 
c:/libjpeg-turbo-gcc64/, and use that when building your code instead.


On 4/18/14 2:30 AM, Vincent Torri wrote:
> hello
>
> I'm compiling a library on Windows using libjpeg-turbo and mingw-w64
> v3 (using 64 bits toolchain) and I get that error :
>
>    CC       eet_image.lo
> In file included from
> C:/MinGW/msys/1.0/opt/libjpeg-turbo/include/jpeglib.h:29:0,
>                   from eet_image.c:38:
> C:/MinGW/msys/1.0/opt/libjpeg-turbo/include/jmorecfg.h:163:14: error:
> conflicting types for 'INT32'
>   typedef long INT32;
>                ^
> In file included from
> c:\mingw\msys\1.0\opt\windows_64\x86_64-w64-mingw32\include\winnt.h:134:0,
>                   from
> c:\mingw\msys\1.0\opt\windows_64\x86_64-w64-mingw32\include\minwindef.h:146,
>                   from
> c:\mingw\msys\1.0\opt\windows_64\x86_64-w64-mingw32\include\windef.h:8,
>                   from
> c:\mingw\msys\1.0\opt\windows_64\x86_64-w64-mingw32\include\windows.h:69,
>                   from
> c:\mingw\msys\1.0\opt\windows_64\x86_64-w64-mingw32\include\winsock2.h:23,
>                   from eet_image.c:30:
> c:\mingw\msys\1.0\opt\windows_64\x86_64-w64-mingw32\include\basetsd.h:31:22:
> note: previous declaration of 'INT32' was h
> ere
>     typedef signed int INT32,*PINT32;
>                        ^
>
> that library includes jpeglib.h after windows.h (if I include it
> before, i get other similar errors)
>
> in addition, INT32 and al types already exists on Windows :
> http://msdn.microsoft.com/en-us/library/windows/desktop/aa383751%28v=vs.85%29.aspx
>
> Is there a solution to that problem ?
>
> thank you
>
> Vincent Torri

Re: [Libjpeg-turbo-devel] problem when using jmorecfg.h and windows.h

[DRC <dco...@us...>]

Oops.  Sorry.  I replied twice.  Ignore the previous reply.  I had not 
fully examined IJG's fix when I wrote that.

On 4/18/14 3:57 AM, DRC wrote:
> This was fixed a long time ago (in 1.2 beta.)  How are you building
> libjpeg-turbo, or where are you getting your build?
>
> I'm suspicious of the fact that your build of libjpeg-turbo resides in
> c:/MinGW/msys/1.0/opt/libjpeg-turbo.  /opt/libjpeg-turbo is generally
> used for Unix builds, not Windows builds.  Methinks someone may have
> gotten too creative with distributing or building our code.
>
> The Windows versions of libjpeg-turbo (except for Cygwin, which is
> treated as a Unix build) are built with CMake instead of autotools, and
> the CMake build system generates a special version of jconfig.h just for
> Windows.  That special version of jconfig.h includes code to work around
> the INT32 conflict.  Note that IJG also has their own fix for this
> issue, in jmorecfg.h.  Their fix, however, does not work if jpeglib.h is
> included before windows.h.  Ours does.  Also, it made more sense to me
> to include our fix in a header that was only distributed on Windows, but
> if a distributor included the wrong version of jconfig.h in the
> distribution, then the problem you're observing could occur.  I suspect
> you might just be using an old version.  Install our official package
> (libjpeg-turbo-gcc64.exe), which puts libjpeg-turbo in
> c:/libjpeg-turbo-gcc64/, and use that when building your code instead.
>
>
> On 4/18/14 2:30 AM, Vincent Torri wrote:
>> hello
>>
>> I'm compiling a library on Windows using libjpeg-turbo and mingw-w64
>> v3 (using 64 bits toolchain) and I get that error :
>>
>>    CC       eet_image.lo
>> In file included from
>> C:/MinGW/msys/1.0/opt/libjpeg-turbo/include/jpeglib.h:29:0,
>>                   from eet_image.c:38:
>> C:/MinGW/msys/1.0/opt/libjpeg-turbo/include/jmorecfg.h:163:14: error:
>> conflicting types for 'INT32'
>>   typedef long INT32;
>>                ^
>> In file included from
>> c:\mingw\msys\1.0\opt\windows_64\x86_64-w64-mingw32\include\winnt.h:134:0,
>>
>>                   from
>> c:\mingw\msys\1.0\opt\windows_64\x86_64-w64-mingw32\include\minwindef.h:146,
>>
>>                   from
>> c:\mingw\msys\1.0\opt\windows_64\x86_64-w64-mingw32\include\windef.h:8,
>>                   from
>> c:\mingw\msys\1.0\opt\windows_64\x86_64-w64-mingw32\include\windows.h:69,
>>                   from
>> c:\mingw\msys\1.0\opt\windows_64\x86_64-w64-mingw32\include\winsock2.h:23,
>>
>>                   from eet_image.c:30:
>> c:\mingw\msys\1.0\opt\windows_64\x86_64-w64-mingw32\include\basetsd.h:31:22:
>>
>> note: previous declaration of 'INT32' was h
>> ere
>>     typedef signed int INT32,*PINT32;
>>                        ^
>>
>> that library includes jpeglib.h after windows.h (if I include it
>> before, i get other similar errors)
>>
>> in addition, INT32 and al types already exists on Windows :
>> http://msdn.microsoft.com/en-us/library/windows/desktop/aa383751%28v=vs.85%29.aspx
>>
>>
>> Is there a solution to that problem ?
>>
>> thank you
>>
>> Vincent Torri

Re: [Libjpeg-turbo-devel] problem when using jmorecfg.h and windows.h

[Vincent T. <vin...@gm...>]

On Fri, Apr 18, 2014 at 10:57 AM, DRC <dco...@us...> wrote:
> This was fixed a long time ago (in 1.2 beta.)  How are you building
> libjpeg-turbo, or where are you getting your build?

already answered in my previous mail, with a possible test example.

> I'm suspicious of the fact that your build of libjpeg-turbo resides in
> c:/MinGW/msys/1.0/opt/libjpeg-turbo.  /opt/libjpeg-turbo is generally
> used for Unix builds, not Windows builds.  Methinks someone may have
> gotten too creative with distributing or building our code.

I think so. The GNU standard (see autoconf manual) says that default
prefix is /usr/local, not /opt/something

I was a bit surprised when i didn't find libjpeg in /usr/local :) but
not a problem , i just set the needed env var.

> The Windows versions of libjpeg-turbo (except for Cygwin, which is
> treated as a Unix build) are built with CMake instead of autotools, and
> the CMake build system generates a special version of jconfig.h just for
> Windows.  That special version of jconfig.h includes code to work around
> the INT32 conflict.  Note that IJG also has their own fix for this
> issue, in jmorecfg.h.  Their fix, however, does not work if jpeglib.h is
> included before windows.h.  Ours does.  Also, it made more sense to me
> to include our fix in a header that was only distributed on Windows, but
> if a distributor included the wrong version of jconfig.h in the
> distribution, then the problem you're observing could occur.  I suspect
> you might just be using an old version.  Install our official package
> (libjpeg-turbo-gcc64.exe), which puts libjpeg-turbo in
> c:/libjpeg-turbo-gcc64/, and use that when building your code instead.

i didn't try that because

1) i realle don't like exe installers for FOSS
2) i'm helping the lead dev of win-builds to have some packages of
standard libraries and libjpeg-turbo is one of those. And he is
compiling all the libraries from sources. So my investigations will
certainly help him later.

i guess that this build used Visual Studio. I'll try that at least to
seee if it works and fix my problem.

Vincent Torri

>
> On 4/18/14 2:30 AM, Vincent Torri wrote:
>> hello
>>
>> I'm compiling a library on Windows using libjpeg-turbo and mingw-w64
>> v3 (using 64 bits toolchain) and I get that error :
>>
>>    CC       eet_image.lo
>> In file included from
>> C:/MinGW/msys/1.0/opt/libjpeg-turbo/include/jpeglib.h:29:0,
>>                   from eet_image.c:38:
>> C:/MinGW/msys/1.0/opt/libjpeg-turbo/include/jmorecfg.h:163:14: error:
>> conflicting types for 'INT32'
>>   typedef long INT32;
>>                ^
>> In file included from
>> c:\mingw\msys\1.0\opt\windows_64\x86_64-w64-mingw32\include\winnt.h:134:0,
>>                   from
>> c:\mingw\msys\1.0\opt\windows_64\x86_64-w64-mingw32\include\minwindef.h:146,
>>                   from
>> c:\mingw\msys\1.0\opt\windows_64\x86_64-w64-mingw32\include\windef.h:8,
>>                   from
>> c:\mingw\msys\1.0\opt\windows_64\x86_64-w64-mingw32\include\windows.h:69,
>>                   from
>> c:\mingw\msys\1.0\opt\windows_64\x86_64-w64-mingw32\include\winsock2.h:23,
>>                   from eet_image.c:30:
>> c:\mingw\msys\1.0\opt\windows_64\x86_64-w64-mingw32\include\basetsd.h:31:22:
>> note: previous declaration of 'INT32' was h
>> ere
>>     typedef signed int INT32,*PINT32;
>>                        ^
>>
>> that library includes jpeglib.h after windows.h (if I include it
>> before, i get other similar errors)
>>
>> in addition, INT32 and al types already exists on Windows :
>> http://msdn.microsoft.com/en-us/library/windows/desktop/aa383751%28v=vs.85%29.aspx
>>
>> Is there a solution to that problem ?
>>
>> thank you
>>
>> Vincent Torri
>
> ------------------------------------------------------------------------------
> Learn Graph Databases - Download FREE O'Reilly Book
> "Graph Databases" is the definitive new guide to graph databases and their
> applications. Written by three acclaimed leaders in the field,
> this first edition is now available. Download your free book today!
> http://p.sf.net/sfu/NeoTech
> _______________________________________________
> Libjpeg-turbo-devel mailing list
> Lib...@li...
> https://lists.sourceforge.net/lists/listinfo/libjpeg-turbo-devel

Re: [Libjpeg-turbo-devel] problem when using jmorecfg.h and windows.h

[Vincent T. <vin...@gm...>]

On Fri, Apr 18, 2014 at 11:09 AM, Vincent Torri <vin...@gm...> wrote:
>
>> I'm suspicious of the fact that your build of libjpeg-turbo resides in
>> c:/MinGW/msys/1.0/opt/libjpeg-turbo.  /opt/libjpeg-turbo is generally
>> used for Unix builds, not Windows builds.  Methinks someone may have
>> gotten too creative with distributing or building our code.
>
> I think so. The GNU standard (see autoconf manual) says that default
> prefix is /usr/local, not /opt/something
>
> I was a bit surprised when i didn't find libjpeg in /usr/local :) but
> not a problem , i just set the needed env var.

btw, even if i compile with a 64 bit toolchain
(--host=x86_64-w64-mingw32), configure installs the libraries in
/opt/libjpeg-turbo/lib32 :-) (and not in ***/libjpeg-turbo64/lib like
the windows installer that i just installed)

Vincent Torri

Re: [Libjpeg-turbo-devel] problem when using jmorecfg.h and windows.h

[DRC <dco...@us...>]

On 4/18/14 4:23 AM, Vincent Torri wrote:
> btw, even if i compile with a 64 bit toolchain
> (--host=x86_64-w64-mingw32), configure installs the libraries in
> /opt/libjpeg-turbo/lib32 :-) (and not in ***/libjpeg-turbo64/lib like
> the windows installer that i just installed)

Yes, because configure.ac determines that based on the size of the long 
type, which is always 32-bit on Windows.  I did mention that we don't 
support using autotools and MinGW, didn't I?  It's these sorts of subtle 
bugs that will drive me to insanity if I had to support dual build 
systems on Windows.

Re: [Libjpeg-turbo-devel] problem when using jmorecfg.h and windows.h

[Vincent T. <vin...@gm...>]

On Fri, Apr 18, 2014 at 11:30 AM, DRC <dco...@us...> wrote:
> On 4/18/14 4:23 AM, Vincent Torri wrote:
>> btw, even if i compile with a 64 bit toolchain
>> (--host=x86_64-w64-mingw32), configure installs the libraries in
>> /opt/libjpeg-turbo/lib32 :-) (and not in ***/libjpeg-turbo64/lib like
>> the windows installer that i just installed)
>
> Yes, because configure.ac determines that based on the size of the long
> type, which is always 32-bit on Windows.

ouch

>  I did mention that we don't
> support using autotools and MinGW, didn't I?

yes, you mentioned that.

>  It's these sorts of subtle
> bugs that will drive me to insanity if I had to support dual build
> systems on Windows.

I can help you with the autotools : i was the maintainer of the
autotools and Windows port of a dozen of libraries (enlightenment
project, if you know it)

Vincent Torri

Re: [Libjpeg-turbo-devel] problem when using jmorecfg.h and windows.h

[DRC <dco...@us...>]

On 4/18/14 4:32 AM, Vincent Torri wrote:
> I can help you with the autotools : i was the maintainer of the
> autotools and Windows port of a dozen of libraries (enlightenment
> project, if you know it)

You have never answered why you can't build libjpeg-turbo with CMake.  I 
do it all the time on MinGW/MSYS.  It works fine.  You just install the 
CMake binary (or maybe convince the MinGW-builds guys to package their 
own version of it), and do

cmake -G"MSYS Makefiles" .
make

In addition to being a fully supported configuration, doing the build 
that way on a Windows machine is a crap-ton faster than doing it with 
autotools.

Re: [Libjpeg-turbo-devel] problem when using jmorecfg.h and windows.h

[Vincent T. <vin...@gm...>]

On Fri, Apr 18, 2014 at 12:06 PM, DRC <dco...@us...> wrote:
> On 4/18/14 4:32 AM, Vincent Torri wrote:
>> I can help you with the autotools : i was the maintainer of the
>> autotools and Windows port of a dozen of libraries (enlightenment
>> project, if you know it)
>
> You have never answered why you can't build libjpeg-turbo with CMake.  I
> do it all the time on MinGW/MSYS.  It works fine.  You just install the
> CMake binary (or maybe convince the MinGW-builds guys to package their
> own version of it), and do

each time i tried to use cmake on windows, i failed :) I had to hack
the cmake files, and as there is no help like autotools...

and i have other reasons to not like cmake.

> cmake -G"MSYS Makefiles" .
> make
>
> In addition to being a fully supported configuration, doing the build
> that way on a Windows machine is a crap-ton faster than doing it with
> autotools.

you could also do cross compilation on linux for the windows build,
which is even faster. But cmake is like hell when doing
cross-compilation

Vincent

Re: [Libjpeg-turbo-devel] problem when using jmorecfg.h and windows.h

[DRC <dco...@us...>]

On 4/18/14 4:09 AM, Vincent Torri wrote:
> i didn't try that because
>
> 1) i realle don't like exe installers for FOSS

Get over it.  Our installers are 100% reproducible using libjpeg-turbo's 
in-tree packaging system.  I don't see how that is philosophically any 
different from using a binary distributed by MinGW-builds or Cygwin.  It 
is just a different distribution mechanism.


> 2) i'm helping the lead dev of win-builds to have some packages of
> standard libraries and libjpeg-turbo is one of those. And he is
> compiling all the libraries from sources. So my investigations will
> certainly help him later.

All the more reason to use our supported build procedure, if possible. 
This will ensure that your build won't break due to some future 
modification I make to the Unix build system.  Getting it working the 
first time isn't the issue.  It's the maintainability of the solution.


> i guess that this build used Visual Studio. I'll try that at least to
> seee if it works and fix my problem.

No, we have two separate sets of packages, one built with MinGW and one 
built with Visual Studio.

Re: [Libjpeg-turbo-devel] problem when using jmorecfg.h and windows.h

[Vincent T. <vin...@gm...>]

On Fri, Apr 18, 2014 at 12:02 PM, DRC <dco...@us...> wrote:
> On 4/18/14 4:09 AM, Vincent Torri wrote:
>> i didn't try that because
>>
>> 1) i realle don't like exe installers for FOSS
>
> Get over it.  Our installers are 100% reproducible using libjpeg-turbo's
> in-tree packaging system.  I don't see how that is philosophically any
> different from using a binary distributed by MinGW-builds or Cygwin.  It
> is just a different distribution mechanism.

you said the word : "philosophically " :-)

>> 2) i'm helping the lead dev of win-builds to have some packages of
>> standard libraries and libjpeg-turbo is one of those. And he is
>> compiling all the libraries from sources. So my investigations will
>> certainly help him later.
>
> All the more reason to use our supported build procedure, if possible.
> This will ensure that your build won't break due to some future
> modification I make to the Unix build system.  Getting it working the
> first time isn't the issue.  It's the maintainability of the solution.

for maintainability, I agree. But normally, once it's done right,
there is no problem. I've done that for years with the autotools

>> i guess that this build used Visual Studio. I'll try that at least to
>> seee if it works and fix my problem.
>
> No, we have two separate sets of packages, one built with MinGW and one
> built with Visual Studio.

ho, right, i downloaded the vc one.

Vincent

Re: [Libjpeg-turbo-devel] problem when using jmorecfg.h and windows.h

[DRC <dco...@us...>]

On 4/18/14 5:10 AM, Vincent Torri wrote:
> each time i tried to use cmake on windows, i failed :) I had to hack
> the cmake files, and as there is no help like autotools...

Like I said, we have a very well-defined and supported build procedure 
for doing that, described in BUILDING.txt.


> and i have other reasons to not like cmake.

I'm sure you do, and no one is asking you to use it in your own project, 
but you can't honestly expect me to support another build system just 
because of your personal hang-ups.


> you could also do cross compilation on linux for the windows build,
> which is even faster. But cmake is like hell when doing
> cross-compilation

Again, we have a very well-defined and supported build procedure for 
that, described in BUILDING.txt.

Re: [Libjpeg-turbo-devel] problem when using jmorecfg.h and windows.h

[Vincent T. <vin...@gm...>]

ok, sorry to have bother you :)

On Fri, Apr 18, 2014 at 12:15 PM, DRC <dco...@us...> wrote:
> On 4/18/14 5:10 AM, Vincent Torri wrote:
>> each time i tried to use cmake on windows, i failed :) I had to hack
>> the cmake files, and as there is no help like autotools...
>
> Like I said, we have a very well-defined and supported build procedure
> for doing that, described in BUILDING.txt.
>
>
>> and i have other reasons to not like cmake.
>
> I'm sure you do, and no one is asking you to use it in your own project,
> but you can't honestly expect me to support another build system just
> because of your personal hang-ups.
>
>
>> you could also do cross compilation on linux for the windows build,
>> which is even faster. But cmake is like hell when doing
>> cross-compilation
>
> Again, we have a very well-defined and supported build procedure for
> that, described in BUILDING.txt.
>
> ------------------------------------------------------------------------------
> Learn Graph Databases - Download FREE O'Reilly Book
> "Graph Databases" is the definitive new guide to graph databases and their
> applications. Written by three acclaimed leaders in the field,
> this first edition is now available. Download your free book today!
> http://p.sf.net/sfu/NeoTech
> _______________________________________________
> Libjpeg-turbo-devel mailing list
> Lib...@li...
> https://lists.sourceforge.net/lists/listinfo/libjpeg-turbo-devel