From: Tripp <el...@ya...> - 2008-04-30 14:50:52
|
hi, trying to compile imlib2, and again it's not close to being a simple, configure & make & make install. got up to here: on configure i get this, checking for X... no checking for XOpenDisplay in -lX11... no configure: error: ERROR: libX11 not found. plus a crash on conftest.exe as it runs through configure. so i looked for libx11, and on configuring it looks for xproto, so i got xproto and on configure i get this: checking for sys/time.h... yes checking for fd_set.fds_bits... no checking for fd_set.__fds_bits... no configure: error: Could not determine how to access the fds_bits or equivalent structure in fd_set on your platform. searched fd_set, but i'm not finding anything downloadable, or looking like an answer. thanks tripp ____________________________________________________________________________________ Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it now. http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ |
From: Keith M. <kei...@us...> - 2008-04-30 16:36:45
|
On Wednesday 30 April 2008 15:50, Tripp wrote: > trying to compile imlib2, > and again it's not close to being a simple, > configure & make & make install. > > got up to here: > on configure i get this, > > checking for X... no > checking for XOpenDisplay in -lX11... no > configure: error: ERROR: libX11 not found. I suspect that you're heading for a hiding to nothing with this one; if the package can't be built --without-x, then it is going to have a very torrid time in a native Win32 environment. It isn't in MinGW's remit to provide services for POSIX or X-Window, so you either have a major porting exercise ahead, to replace all the X-Window API references with native MS-Windows API alternatives, or you need an emulation framework. For your needs, you may do better looking at Cygwin. Regards, Keith. |
From: Tripp <el...@ya...> - 2008-05-01 03:06:58
|
--- Keith Marshall <kei...@us...> wrote: > On Wednesday 30 April 2008 15:50, Tripp wrote: > > trying to compile imlib2, > > and again it's not close to being a simple, > > configure & make & make install. > > > > got up to here: > > on configure i get this, > > > > checking for X... no > > checking for XOpenDisplay in -lX11... no > > configure: error: ERROR: libX11 not found. > > I suspect that you're heading for a hiding to nothing with this one; > For your needs, you may do better looking at Cygwin. yeah, i might try cygwin or xming. > if the package can't be built --without-x, i'd settle for that. but: c:/mingw/include/ctype.h:255: warning: C99 inline functions are not supported; using GNU89 api.c: In function 'imlib_context_new': api.c:170: error: 'imlib_context_new': definition is marked as dllimport api.c: At top level: api.c:4787: warning: 'imlib_rotate_image_from_buffer' redeclared without dllimport attribute: previous dllimport ignored make[3]: *** [api.lo] Error 1 make[3]: Leaving directory `/c/test/imlib2/src/lib' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/c/test/imlib2/src' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/c/test/imlib2' make: *** [all] Error 2 thanks for the suggestions, tripp ____________________________________________________________________________________ Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it now. http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ |
From: Vincent T. <vt...@un...> - 2008-05-01 05:53:41
|
>> On Wednesday 30 April 2008 15:50, Tripp wrote: >>> trying to compile imlib2, >>> and again it's not close to being a simple, >>> configure & make & make install. >>> >>> got up to here: >>> on configure i get this, >>> >>> checking for X... no >>> checking for XOpenDisplay in -lX11... no >>> configure: error: ERROR: libX11 not found. >> >> I suspect that you're heading for a hiding to nothing with this one; >> For your needs, you may do better looking at Cygwin. > > yeah, > i might try cygwin or xming. > >> if the package can't be built --without-x, > > i'd settle for that. > but: > c:/mingw/include/ctype.h:255: warning: C99 inline functions are not > supported; using GNU89 > api.c: In function 'imlib_context_new': > api.c:170: error: 'imlib_context_new': definition is marked as > dllimport > api.c: At top level: > api.c:4787: warning: 'imlib_rotate_image_from_buffer' redeclared > without dllimport attribute: previous dllimport ignored > make[3]: *** [api.lo] Error 1 > make[3]: Leaving directory `/c/test/imlib2/src/lib' > make[2]: *** [all-recursive] Error 1 > make[2]: Leaving directory `/c/test/imlib2/src' > make[1]: *** [all-recursive] Error 1 > make[1]: Leaving directory `/c/test/imlib2' > make: *** [all] Error 2 1) In Imlib2.h, replace: # ifdef WIN32 # ifdef BUILDING_DLL # define EAPI __declspec(dllexport) # else # define EAPI __declspec(dllimport) # endif # else by #ifdef _WIN32 # ifdef EFL_IMLIB2_BUILD # ifdef DLL_EXPORT # define EAPI __declspec(dllexport) # else # define EAPI # endif /* ! DLL_EXPORT */ # else # define EAPI __declspec(dllimport) # endif /* ! EFL_IMLIB2_BUILD */ #else 2) In configure.in add: AC_LIBTOOL_WIN32_DLL before AC_PROG_LIBTOOL and add, for example after AC_PROG_LIBTOOL : case "$host_os" in mingw*|cegcc) AC_DEFINE(EFL_IMLIB2_BUILD, 1, [Define to mention that imlib2 is built]) esac and tell me if it works. Vincent Torri |
From: Tripp <el...@ya...> - 2008-05-01 22:30:55
|
--- Vincent Torri <vt...@un...> wrote: > >> On Wednesday 30 April 2008 15:50, Tripp wrote: > > api.c: In function 'imlib_context_new': > > api.c:170: error: 'imlib_context_new': definition is marked as > > dllimport > > api.c: At top level: > > api.c:4787: warning: 'imlib_rotate_image_from_buffer' redeclared > > without dllimport attribute: previous dllimport ignored > > 1) In Imlib2.h, replace: > > # ifdef WIN32 > # ifdef BUILDING_DLL > # define EAPI __declspec(dllexport) > # else > # define EAPI __declspec(dllimport) > # endif > # else > > by > > #ifdef _WIN32 > # ifdef EFL_IMLIB2_BUILD > # ifdef DLL_EXPORT > # define EAPI __declspec(dllexport) > # else > # define EAPI > # endif /* ! DLL_EXPORT */ > # else > # define EAPI __declspec(dllimport) > # endif /* ! EFL_IMLIB2_BUILD */ > #else > > 2) In configure.in > > add: > > AC_LIBTOOL_WIN32_DLL > > before AC_PROG_LIBTOOL > > and add, for example after AC_PROG_LIBTOOL : > > case "$host_os" in > mingw*|cegcc) > AC_DEFINE(EFL_IMLIB2_BUILD, 1, [Define to mention that imlib2 is > built]) > esac > > and tell me if it works. ty, first, in configure.in, there is no: AC_PROG_LIBTOOL it's AM_PROG_LIBTOOL i applied the changes anyway, and on make it starts off with these 'suspicious'warnings: $ make cd . && /bin/sh /c/test/imlib2/missing --run autoconf configure.in:33: warning: AC_CACHE_VAL(lt_prog_compiler_pic_works, ...): suspicious cache-id, must contain _cv_ to be cached ../../lib/autoconf/general.m4:1987: AC_CACHE_VAL is expanded from... ../../lib/autoconf/general.m4:2000: AC_CACHE_CHECK is expanded from... aclocal.m4:659: AC_LIBTOOL_COMPILER_OPTION is expanded from... aclocal.m4:5318: AC_LIBTOOL_PROG_COMPILER_PIC is expanded from... aclocal.m4:2713: _LT_AC_LANG_C_CONFIG is expanded from... aclocal.m4:2644: AC_LIBTOOL_LANG_C_CONFIG is expanded from... aclocal.m4:226: AC_LIBTOOL_SETUP is expanded from... aclocal.m4:81: _AC_PROG_LIBTOOL is expanded from... aclocal.m4:61: AC_PROG_LIBTOOL is expanded from... aclocal.m4:6301: AM_PROG_LIBTOOL is expanded from... configure.in:33: the top level configure.in:33: warning: AC_CACHE_VAL(lt_prog_compiler_static_works, ...): suspicious cache-id, must contain _cv_ to be cached aclocal.m4:696: AC_LIBTOOL_LINKER_OPTION is expanded from... configure.in:33: warning: AC_CACHE_VAL(lt_prog_compiler_pic_works_CXX, ...): suspicious cache-id, must contain _cv_ to be cached aclocal.m4:3717: _LT_AC_LANG_CXX_CONFIG is expanded from... aclocal.m4:2721: AC_LIBTOOL_LANG_CXX_CONFIG is expanded from... aclocal.m4:1880: _LT_AC_TAGCONFIG is expanded from... configure.in:33: warning: AC_CACHE_VAL(lt_prog_compiler_static_works_CXX, ...): suspicious cache-id, must contain _cv_ to be cached configure.in:33: warning: AC_CACHE_VAL(lt_prog_compiler_pic_works_F77, ...): suspicious cache-id, must contain _cv_ to be cached aclocal.m4:3978: _LT_AC_LANG_F77_CONFIG is expanded from... aclocal.m4:3884: AC_LIBTOOL_LANG_F77_CONFIG is expanded from... configure.in:33: warning: AC_CACHE_VAL(lt_prog_compiler_static_works_F77, ...): suspicious cache-id, must contain _cv_ to be cached configure.in:33: warning: AC_CACHE_VAL(lt_prog_compiler_pic_works_GCJ, ...): suspicious cache-id, must contain _cv_ to be cached aclocal.m4:4034: _LT_AC_LANG_GCJ_CONFIG is expanded from... aclocal.m4:3986: AC_LIBTOOL_LANG_GCJ_CONFIG is expanded from... configure.in:33: warning: AC_CACHE_VAL(lt_prog_compiler_static_works_GCJ, ...): suspicious cache-id, must contain _cv_ to be cached /bin/sh ./config.status --recheck and at the end of make it error out like so: file.c:13:17: error: pwd.h: No such file or directory file.c: In function '__imlib_FileCanRead': file.c:234: error: 'S_IRGRP' undeclared (first use in this function) file.c:234: error: (Each undeclared identifier is reported only once file.c:234: error: for each function it appears in.) file.c:234: error: 'S_IROTH' undeclared (first use in this function) file.c: In function '__imlib_FileHomeDir': file.c:382: warning: implicit declaration of function 'getuid' file.c:387: warning: implicit declaration of function 'getpwuid' file.c:387: warning: assignment makes pointer from integer without a cast file.c:390: error: dereferencing pointer to incomplete type make[3]: *** [file.lo] Error 1 make[3]: Leaving directory `/c/test/imlib2/src/lib' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/c/test/imlib2/src' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/c/test/imlib2' make: *** [all] Error 2 i'd tried Ramiro's patch already. no diff to the problem i was having. i also tried applying the patch after the diff sugested above, and got a bunch of these messages on make: updates.c: In function '__imlib_MergeUpdate': updates.c:141: warning: visibility attribute not supported in this configuration; ignored and it finally rrored out on a string of these errors: asm_blend.S:28: Error: unknown pseudo-op: `.hidden' asm_blend.S:28: Warning: .type pseudo-op used outside of .def/.endef ignored. asm_blend.S:28: Error: junk at end of line, first unrecognized character is `_' thanks for the assistance tripp ____________________________________________________________________________________ Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it now. http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ |
From: Vincent T. <vt...@un...> - 2008-05-02 06:14:03
|
> first, in configure.in, there is no: > AC_PROG_LIBTOOL > it's > AM_PROG_LIBTOOL it's not a problem. > i applied the changes anyway, > and on make it starts off with these 'suspicious'warnings: > > $ make > cd . && /bin/sh /c/test/imlib2/missing --run autoconf > configure.in:33: warning: AC_CACHE_VAL(lt_prog_compiler_pic_works, > ...): suspicious cache-id, must contain _cv_ to be cached > ../../lib/autoconf/general.m4:1987: AC_CACHE_VAL is expanded from... > ../../lib/autoconf/general.m4:2000: AC_CACHE_CHECK is expanded from... > aclocal.m4:659: AC_LIBTOOL_COMPILER_OPTION is expanded from... > aclocal.m4:5318: AC_LIBTOOL_PROG_COMPILER_PIC is expanded from... > aclocal.m4:2713: _LT_AC_LANG_C_CONFIG is expanded from... > aclocal.m4:2644: AC_LIBTOOL_LANG_C_CONFIG is expanded from... > aclocal.m4:226: AC_LIBTOOL_SETUP is expanded from... > aclocal.m4:81: _AC_PROG_LIBTOOL is expanded from... > aclocal.m4:61: AC_PROG_LIBTOOL is expanded from... > aclocal.m4:6301: AM_PROG_LIBTOOL is expanded from... > configure.in:33: the top level > configure.in:33: warning: AC_CACHE_VAL(lt_prog_compiler_static_works, > ...): suspicious cache-id, must contain _cv_ to be cached > aclocal.m4:696: AC_LIBTOOL_LINKER_OPTION is expanded from... > configure.in:33: warning: AC_CACHE_VAL(lt_prog_compiler_pic_works_CXX, > ...): suspicious cache-id, must contain _cv_ to be cached > aclocal.m4:3717: _LT_AC_LANG_CXX_CONFIG is expanded from... > aclocal.m4:2721: AC_LIBTOOL_LANG_CXX_CONFIG is expanded from... > aclocal.m4:1880: _LT_AC_TAGCONFIG is expanded from... > configure.in:33: warning: > AC_CACHE_VAL(lt_prog_compiler_static_works_CXX, ...): > suspicious cache-id, must contain _cv_ to be cached > configure.in:33: warning: AC_CACHE_VAL(lt_prog_compiler_pic_works_F77, > ...): suspicious cache-id, must contain _cv_ to be cached > aclocal.m4:3978: _LT_AC_LANG_F77_CONFIG is expanded from... > aclocal.m4:3884: AC_LIBTOOL_LANG_F77_CONFIG is expanded from... > configure.in:33: warning: > AC_CACHE_VAL(lt_prog_compiler_static_works_F77, ...): suspicious > cache-id, must contain _cv_ to be cached > configure.in:33: warning: AC_CACHE_VAL(lt_prog_compiler_pic_works_GCJ, > ...): suspicious cache-id, must contain _cv_ to be cached > aclocal.m4:4034: _LT_AC_LANG_GCJ_CONFIG is expanded from... > aclocal.m4:3986: AC_LIBTOOL_LANG_GCJ_CONFIG is expanded from... > configure.in:33: warning: > AC_CACHE_VAL(lt_prog_compiler_static_works_GCJ, ...): suspicious > cache-id, must contain _cv_ to be cached > /bin/sh ./config.status --recheck replace lines 30 to 33: m4_undefine([AC_PROG_CXX]) m4_defun([AC_PROG_CXX],[]) m4_undefine([AC_PROG_F77]) m4_defun([AC_PROG_F77],[]) by define([AC_LIBTOOL_LANG_CXX_CONFIG], [:])dnl define([AC_LIBTOOL_LANG_F77_CONFIG], [:])dnl it should remove those warnings, I think. > > and at the end of make it error out like so: > > file.c:13:17: error: pwd.h: No such file or directory > file.c: In function '__imlib_FileCanRead': > file.c:234: error: 'S_IRGRP' undeclared (first use in this function) > file.c:234: error: (Each undeclared identifier is reported only once > file.c:234: error: for each function it appears in.) > file.c:234: error: 'S_IROTH' undeclared (first use in this function) > file.c: In function '__imlib_FileHomeDir': > file.c:382: warning: implicit declaration of function 'getuid' > file.c:387: warning: implicit declaration of function 'getpwuid' > file.c:387: warning: assignment makes pointer from integer without a > cast > file.c:390: error: dereferencing pointer to incomplete type > make[3]: *** [file.lo] Error 1 > make[3]: Leaving directory `/c/test/imlib2/src/lib' > make[2]: *** [all-recursive] Error 1 > make[2]: Leaving directory `/c/test/imlib2/src' > make[1]: *** [all-recursive] Error 1 > make[1]: Leaving directory `/c/test/imlib2' > make: *** [all] Error 2 about that, i've written a small library, called 'evil', that tries to implement win32 port of unix functions. I have to use it to port imlib2 to windows. Imlib2 has never been intended to be run on windows. So it's normal that the compilation is not straightforward on that platform. > updates.c: In function '__imlib_MergeUpdate': > updates.c:141: warning: visibility attribute not supported in this > configuration; ignored > > > and it finally rrored out on a string of these errors: > > asm_blend.S:28: Error: unknown pseudo-op: `.hidden' > asm_blend.S:28: Warning: .type pseudo-op used outside of .def/.endef > ignored. > asm_blend.S:28: Error: junk at end of line, first unrecognized > character is `_' i don't know. It's a problem with the visibility feature of gcc 4.*. Is it possible tho use it with __declspec ? Vincent Torri |
From: Ralf W. <Ral...@gm...> - 2008-05-02 06:20:40
|
* Vincent Torri wrote on Fri, May 02, 2008 at 08:13:54AM CEST: > > $ make > > cd . && /bin/sh /c/test/imlib2/missing --run autoconf > > configure.in:33: warning: AC_CACHE_VAL(lt_prog_compiler_pic_works, > > ...): suspicious cache-id, must contain _cv_ to be cached > replace lines 30 to 33: > > m4_undefine([AC_PROG_CXX]) > m4_defun([AC_PROG_CXX],[]) > m4_undefine([AC_PROG_F77]) > m4_defun([AC_PROG_F77],[]) > > by > > define([AC_LIBTOOL_LANG_CXX_CONFIG], [:])dnl > define([AC_LIBTOOL_LANG_F77_CONFIG], [:])dnl > > it should remove those warnings, I think. The replacing is ok, but independent, it will not fix the warnings. The warnings are fixed by using Libtool >= 1.5.26. (You are only seeing them with Autoconf >= 2.62, but only because that does better checking than older Autoconf.) Cheers, Ralf |
From: Vincent T. <vt...@un...> - 2008-05-02 06:26:08
|
On Fri, 2 May 2008, Ralf Wildenhues wrote: > * Vincent Torri wrote on Fri, May 02, 2008 at 08:13:54AM CEST: >>> $ make >>> cd . && /bin/sh /c/test/imlib2/missing --run autoconf >>> configure.in:33: warning: AC_CACHE_VAL(lt_prog_compiler_pic_works, >>> ...): suspicious cache-id, must contain _cv_ to be cached > >> replace lines 30 to 33: >> >> m4_undefine([AC_PROG_CXX]) >> m4_defun([AC_PROG_CXX],[]) >> m4_undefine([AC_PROG_F77]) >> m4_defun([AC_PROG_F77],[]) >> >> by >> >> define([AC_LIBTOOL_LANG_CXX_CONFIG], [:])dnl >> define([AC_LIBTOOL_LANG_F77_CONFIG], [:])dnl >> >> it should remove those warnings, I think. > > The replacing is ok, but independent, it will not fix the warnings. > The warnings are fixed by using Libtool >= 1.5.26. (You are only seeing > them with Autoconf >= 2.62, but only because that does better checking > than older Autoconf.) indeed, it's autoconf >= 2.62 that displays those warnings. But i don't see anything in configure.in that can display those warnings, except those m4_* calls. I can't test imlib2 right now, and configure.in must be fixed (some things are not correct. Ralf, don't look at it or you'll cry). I'll fix it next week. Vincent Torri |
From: Ralf W. <Ral...@gm...> - 2008-05-02 08:39:55
|
* Vincent Torri wrote on Fri, May 02, 2008 at 08:25:57AM CEST: > On Fri, 2 May 2008, Ralf Wildenhues wrote: > > > > The replacing is ok, but independent, it will not fix the warnings. > > The warnings are fixed by using Libtool >= 1.5.26. (You are only seeing > > them with Autoconf >= 2.62, but only because that does better checking > > than older Autoconf.) > > indeed, it's autoconf >= 2.62 that displays those warnings. But i don't > see anything in configure.in that can display those warnings, except those > m4_* calls. A[CM]_PROG_LIBTOOL is what evokes these warnings. Look at the warning output, it even tells you so in the traces. It's simply a bug in libtool.m4 for Libtool <= 1.5.24. > I can't test imlib2 right now, and configure.in must be fixed These are only warnings, not errors. They are harmless. > (some things are not correct. Ralf, don't look at it or you'll cry). I'll > fix it next week. Don't worry, I won't look. ;-) Cheers, Ralf |
From: Vincent T. <vt...@un...> - 2008-05-02 13:31:26
|
>> I can't test imlib2 right now, and configure.in must be fixed > > These are only warnings, not errors. They are harmless. if you look at the code, you'll understand what i mean by "fix" :) It's not about those warnings :) Vincent Torri |
From: Ramiro P. <ra...@li...> - 2008-05-01 23:11:02
|
Hello, > i'd tried Ramiro's patch already. > no diff to the problem i was having. I think I updated autotools also as in http://arrozcru.no-ip.org/ffmpeg_wiki/tiki-index.php?page=Installling+newest+autotools And maybe I had to pass some -D parameter to CFLAGS too, I don't remember. Ramiro Polla |
From: Ramiro P. <ra...@li...> - 2008-05-01 23:50:46
Attachments:
imlib2-1.4.0.diff
|
Ramiro Polla wrote: > Hello, > >> i'd tried Ramiro's patch already. >> no diff to the problem i was having. > > I think I updated autotools also as in > http://arrozcru.no-ip.org/ffmpeg_wiki/tiki-index.php?page=Installling+newest+autotools > > And maybe I had to pass some -D parameter to CFLAGS too, I don't remember. Install dlfcn-win32 Install FreeType2 tar zxfv imlib2-1.4.0.tar.gz patch -p0 < imlib2-1.4.0.diff cd imlib2-1.4.0 CFLAGS=-DBUILDING_DLL ./configure --without-x --disable-mmx make make install I didn't bother trying to fix more stuff (like asm) because imlib2 will probably be dropped from FFmpeg once libavfilter takes in... I also attached the patch in case the server goes south again. Ramiro Polla |
From: Keith M. <kei...@us...> - 2008-05-02 09:54:31
|
On Friday 02 May 2008 00:50, Ramiro Polla wrote: > Ramiro Polla wrote: > CFLAGS=-DBUILDING_DLL ./configure --without-x --disable-mmx Unless the configure script was built with a very old autoconf, (pre-2.50), this is better expressed as ./configure CFLAGS=-DBUILDING_DLL --without-x --disable-mmx and, while it's harmless, you don't *need* this sort of nonsense... > +#define LOADERS_STR "\\loaders" > - sprintf(s, SYS_LOADERS_PATH "/loaders"); > + sprintf(s, SYS_LOADERS_PATH LOADERS_STR); ...to replace slashes in path names by backslashes; MS-Windows is perfectly happy to resolve path names expressed with the *nix style slash as an alternative to its default backslash, and always has been; even MS-DOS before it could handle this. > - if (!(__imlib_FilePermissions(fl) & (S_IRUSR | S_IRGRP | S_IROTH))) > + if (!(__imlib_FilePermissions(fl) & (S_IRUSR))) Rather than patch this in place, (where the code would normally apply for every supported platform), it is usually cleaner to add a guarded define for each platform specific unsupported attribute, e.g. ... #ifdef _WIN32 # define S_IRGRP 0 # define S_IROTH 0 #endif Regards, Keith. |
From: Ramiro P. <ra...@li...> - 2008-05-02 10:34:06
|
Hello, >> +#define LOADERS_STR "\\loaders" > >> - sprintf(s, SYS_LOADERS_PATH "/loaders"); >> + sprintf(s, SYS_LOADERS_PATH LOADERS_STR); > > ...to replace slashes in path names by backslashes; MS-Windows is > perfectly happy to resolve path names expressed with the *nix style > slash as an alternative to its default backslash, and always has been; > even MS-DOS before it could handle this. LoadLibrary() http://msdn.microsoft.com/en-us/library/ms886736.aspx IIRC dlfcn-win32 does this by itself, so it should be fine to use forward slashes. But I only wrote dlfcn-win32 after this patch. >> - if (!(__imlib_FilePermissions(fl) & (S_IRUSR | S_IRGRP | S_IROTH))) >> + if (!(__imlib_FilePermissions(fl) & (S_IRUSR))) > > Rather than patch this in place, (where the code would normally apply > for every supported platform), it is usually cleaner to add a guarded > define for each platform specific unsupported attribute, e.g. ... > > #ifdef _WIN32 > # define S_IRGRP 0 > # define S_IROTH 0 > #endif Oh, I am completely aware that this patch is an ugly mess =) I also just thought "who cares about targa?" and removed any reference from it to the Makefiles. If I had to clean this up myself, I would have done differently. But now I see that there is an Enlightment project for GSoC 2008 about this, so someone will take care of it. Ramiro Polla |
From: Keith M. <kei...@us...> - 2008-05-02 11:31:06
|
On Friday 02 May 2008 11:33, Ramiro Polla wrote: > > [It shouldn't be necessary...] > > ...to replace slashes in path names by backslashes; MS-Windows is > > perfectly happy to resolve path names expressed with the *nix style > > slash as an alternative to its default backslash, and always has > > been; even MS-DOS before it could handle this. > > LoadLibrary() > http://msdn.microsoft.com/en-us/library/ms886736.aspx Hmm. That's the first time I've ever seen it stated "be sure to use backslashes, not slashes". Does LoadLibrary() *really* fail if you ignore this advice? If so, then it isn't consistent with the normal behaviour of the Windows API. BTW, the link you provided relates specifically to WinCE, but the same statement appears in MSDN's more general Windows documentation too. > IIRC dlfcn-win32 does this by itself, so it should be fine to use > forward slashes. But I only wrote dlfcn-win32 after this patch. In `man' I use a path name normalisation function, to help with various required manipulations; in that case, I normalise to slashes, because it is more convenient for commonality with the POSIX code, but my function, (which performs the normalisation in the wchar_t domain), could equally well normalise to backslashes. BTW, I know you've suggested it before; would you still be interested in distributing dlfcn-win32 as a User Contributed add-on for MinGW, making it directly available from our download page, as a possible convenience for MinGW users? > Oh, I am completely aware that this patch is an ugly mess... Understood. My comments weren't intended so much as criticism--there's nothing inherently wrong with how you did it--but rather as just one or two tips to suggest how you might have done it more cleanly. Regards, Keith. |
From: Earnie B. <ea...@us...> - 2008-05-02 14:17:20
|
Quoting Keith Marshall <kei...@us...>: > On Friday 02 May 2008 11:33, Ramiro Polla wrote: >> > [It shouldn't be necessary...] >> > ...to replace slashes in path names by backslashes; MS-Windows is >> > perfectly happy to resolve path names expressed with the *nix style >> > slash as an alternative to its default backslash, and always has >> > been; even MS-DOS before it could handle this. >> >> LoadLibrary() >> http://msdn.microsoft.com/en-us/library/ms886736.aspx > > Hmm. That's the first time I've ever seen it stated "be sure to use > backslashes, not slashes". Does LoadLibrary() *really* fail if you > ignore this advice? If so, then it isn't consistent with the normal > behaviour of the Windows API. > It's consistent with CreateProcess[1]. > BTW, the link you provided relates specifically to WinCE, but the same > statement appears in MSDN's more general Windows documentation too. > Is this one[2] better? [1] http://msdn.microsoft.com/en-us/library/ms682425.aspx [2] http://msdn.microsoft.com/en-us/library/ms684175(VS.85).aspx Earnie |
From: Keith M. <kei...@us...> - 2008-05-03 14:04:59
|
On Friday 02 May 2008 15:17, Earnie Boyd wrote: > >> LoadLibrary() > >> http://msdn.microsoft.com/en-us/library/ms886736.aspx > > > > Hmm. That's the first time I've ever seen it stated "be sure to > > use backslashes, not slashes". Does LoadLibrary() *really* fail if > > you ignore this advice? If so, then it isn't consistent with the > > normal behaviour of the Windows API. > > It's consistent with CreateProcess[1]. I couldn't see any explicit statement, on that page, that said you couldn't use forward slashes as an alternative to backslashes. FWIW, I've never encountered the slightest problem with doing just that, and I don't normally ever use backslashes when I specify a path name--it's just too ugly for words to describe it. However, I must also confess that I don't think I've ever called CreateProcess directly, preferring the simpler syntax of spawn(), (via a wrapper to correctly preserve whitespace in the arguments). > > BTW, the link you provided relates specifically to WinCE, but the > > same statement appears in MSDN's more general Windows documentation > > too. > > Is this one[2] better? Yep. I think it's the same one I was looking at, when I said "the same statement appears in MSDN's more general Windows documentation too". Regards, Keith. |
From: Ramiro P. <ra...@li...> - 2008-05-02 16:41:54
|
Hello, Keith Marshall wrote: > On Friday 02 May 2008 11:33, Ramiro Polla wrote: >>> [It shouldn't be necessary...] >>> ...to replace slashes in path names by backslashes; MS-Windows is >>> perfectly happy to resolve path names expressed with the *nix style >>> slash as an alternative to its default backslash, and always has >>> been; even MS-DOS before it could handle this. >> LoadLibrary() >> http://msdn.microsoft.com/en-us/library/ms886736.aspx > > Hmm. That's the first time I've ever seen it stated "be sure to use > backslashes, not slashes". Does LoadLibrary() *really* fail if you > ignore this advice? Yes. > If so, then it isn't consistent with the normal > behaviour of the Windows API. > > BTW, the link you provided relates specifically to WinCE, but the same > statement appears in MSDN's more general Windows documentation too. MSDN's organization confuses me =) >> IIRC dlfcn-win32 does this by itself, so it should be fine to use >> forward slashes. But I only wrote dlfcn-win32 after this patch. > > In `man' I use a path name normalisation function, to help with various > required manipulations; in that case, I normalise to slashes, because > it is more convenient for commonality with the POSIX code, but my > function, (which performs the normalisation in the wchar_t domain), > could equally well normalise to backslashes. > > BTW, I know you've suggested it before; would you still be interested in > distributing dlfcn-win32 as a User Contributed add-on for MinGW, making > it directly available from our download page, as a possible convenience > for MinGW users? Sure. What must I (or someone else) do for that to happen? Ramiro Polla |
From: Keith M. <kei...@us...> - 2008-05-03 14:14:13
|
On Friday 02 May 2008 16:41, Ramiro Polla wrote: > >> LoadLibrary() > >> http://msdn.microsoft.com/en-us/library/ms886736.aspx > > > > Hmm. That's the first time I've ever seen it stated "be sure to > > use backslashes, not slashes". Does LoadLibrary() *really* fail if > > you ignore this advice? > > Yes. Hmm. I thought about adding a sarcastic comment, along the lines of "don't you just love the consistency of Microsoft's API?", but then I thought "why bother; everyone knows the low level of esteem in which I hold Microsoft anyway". Oh, rats. I guess I just said it anyway :-) Regards, Keith. |
From: Tripp <el...@ya...> - 2008-05-03 16:37:24
|
--- Keith Marshall <kei...@us...> wrote: > On Friday 02 May 2008 00:50, Ramiro Polla wrote: > > Ramiro Polla wrote: > > CFLAGS=-DBUILDING_DLL ./configure --without-x --disable-mmx > > Unless the configure script was built with a very old autoconf, > (pre-2.50), this is better expressed as > > ./configure CFLAGS=-DBUILDING_DLL --without-x --disable-mmx this worked, i just started of with source, patched with Vincent's patch and then with Ramiro's. didn't test other combinations. already had dlfcn-win32 installed, didn't apply changes Vincent mentioned on m4 lies in configure.in. ty tripp ____________________________________________________________________________________ Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it now. http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ |
From: Ramiro P. <ra...@li...> - 2008-05-01 18:19:27
|
Hello, Tripp wrote: > --- Keith Marshall <kei...@pu...> wrote: > >> On Wednesday 30 April 2008 15:50, Tripp wrote: >>> trying to compile imlib2, >>> and again it's not close to being a simple, >>> configure & make & make install. >>> >>> got up to here: >>> on configure i get this, >>> >>> checking for X... no >>> checking for XOpenDisplay in -lX11... no >>> configure: error: ERROR: libX11 not found. >> I suspect that you're heading for a hiding to nothing with this one; >> For your needs, you may do better looking at Cygwin. > > yeah, > i might try cygwin or xming. > >> if the package can't be built --without-x, When I read this post I thought "Didn't I have a page explaining how to compile imlib2 in Windows?", then I remember my host (eMaxHosting) lost that page in an HD failure it had last year. I still have a patch though [0]. Make some sense out of it and when you get it done, please add the page again to the FFmpeg on Windows Wiki =) All I remember is that I did disable X. Ramiro Polla [0] http://arrozcru.no-ip.org/ffmpeg_patches/imlib2-1.4.0.diff |
From: Vincent T. <vt...@un...> - 2008-05-01 18:33:53
|
On Thu, 1 May 2008, Ramiro Polla wrote: > Hello, > > Tripp wrote: >> --- Keith Marshall <kei...@pu...> wrote: >> >>> On Wednesday 30 April 2008 15:50, Tripp wrote: >>>> trying to compile imlib2, >>>> and again it's not close to being a simple, >>>> configure & make & make install. >>>> >>>> got up to here: >>>> on configure i get this, >>>> >>>> checking for X... no >>>> checking for XOpenDisplay in -lX11... no >>>> configure: error: ERROR: libX11 not found. >>> I suspect that you're heading for a hiding to nothing with this one; >>> For your needs, you may do better looking at Cygwin. >> >> yeah, >> i might try cygwin or xming. >> >>> if the package can't be built --without-x, > > When I read this post I thought "Didn't I have a page explaining how to > compile imlib2 in Windows?", then I remember my host (eMaxHosting) lost > that page in an HD failure it had last year. > > I still have a patch though [0]. Make some sense out of it and when you > get it done, please add the page again to the FFmpeg on Windows Wiki =) > All I remember is that I did disable X. better use the enlightenment wiki for windows: http://wiki.enlightenment.org/index.php/EFL_Windows_XP also, as i'm the one who is involved in the win32 port of the efl, i'll try to fix the compilation of imlib2 with msys/mingw, and update the wiki accordingly Vincent Torri |
From: Earnie B. <ea...@us...> - 2008-04-30 18:31:08
|
Quoting Keith Marshall <kei...@us...>: > On Wednesday 30 April 2008 15:50, Tripp wrote: >> trying to compile imlib2, >> and again it's not close to being a simple, >> configure & make & make install. >> >> got up to here: >> on configure i get this, >> >> checking for X... no >> checking for XOpenDisplay in -lX11... no >> configure: error: ERROR: libX11 not found. > > I suspect that you're heading for a hiding to nothing with this one; if > the package can't be built --without-x, then it is going to have a very > torrid time in a native Win32 environment. > > It isn't in MinGW's remit to provide services for POSIX or X-Window, so > you either have a major porting exercise ahead, to replace all the > X-Window API references with native MS-Windows API alternatives, or you > need an emulation framework. For your needs, you may do better looking > at Cygwin. > Right but then their are others[1]. I've not used xming nor do I know if they provide a libX11 to use. [1] http://en.wikipedia.org/wiki/Xming Earnie |
From: Vincent T. <vt...@un...> - 2008-04-30 19:11:25
|
> > Right but then their are others[1]. I've not used xming nor do I know > if they provide a libX11 to use. Afaik, xming provides only an implementation of the X server, no Xlib (what you call libX11) implementation for Windows (6.9 version of xming). I didn't succeed in downloading the latest 7.3 release (a password is required). I think there is an implementation of Xlib in the 7.3 release. Vincent Torri |
From: Keith M. <kei...@us...> - 2008-04-30 20:40:02
|
On Wednesday 30 April 2008 20:11, Vincent Torri wrote: > Afaik, xming provides only an implementation of the X server, no Xlib > (what you call libX11) implementation for Windows (6.9 version of > xming). That's the impression I got too; xming is primarily intended to allow a WinXP+ box to act as an X server viewport, for X client applications running remotely, on networked *nix boxes, not as a toolkit for developing X applications to run natively on Win32. It also didn't appear to support any Win32 variant predating XP. Regards, Keith. |