Re: [E-devel] evil trouble
Vincent Torri wrote: Hey I had to compile the link code with g++, hence putting IID_PersistFile was not possible (at least, i didn't succeed). So I put the code in a separate file like Lars did. I've attached a patch. Please test it. It compiles correctly on my system. Vincent compiles fine here too. patch didnt apply cleanly from latest svn tho, configure.ac and makefile.am i manually resolved having it depend on c++ for such a small thing IMHO aint all that great.. (i was going to apply lars's patch to test, but since it worked i wasnt going to mess furthur) changing CHECK_HEADERS_ONCE wasnt necessary so i didnt put that part in you ppl are awesome thx ps.. looks like eina uses pkgconfig macro in its configure script to find evil and ememoa. so I suggest editing the wiki slightly :) - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] evil trouble
On Mon, 27 Oct 2008, Samuel Nicholas wrote: compiles fine here too. ok patch didnt apply cleanly from latest svn tho, configure.ac and makefile.am i manually resolved yes, I know, but didn't have time this morning to fix that. having it depend on c++ for such a small thing IMHO aint all that great.. (i was going to apply lars's patch to test, but since it worked i wasnt going to mess furthur) actually, it's better to have c++ here: the COM interface (used for generating .lnk files) is C++, it's simpler than using the C interface. In additin, i am not sure that the previous code were working correctly... changing CHECK_HEADERS_ONCE wasnt necessary so i didnt put that part in it was for me. Problem with autoconf... I'll check again. ps.. looks like eina uses pkgconfig macro in its configure script to find evil and ememoa. so I suggest editing the wiki slightly :) Indeed. I'll do that this evening. thank you Vincent - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] evil trouble
hay guise cause eina has recently been added as a dependancy i was updating my libs and ran into trouble... so i decided to start from scratch again. now i have a problem I didn't have before when compiling evil: ... /bin/sh ../../libtool --tag=CC --mode=link gcc -g -O2 -no-undefined -Wl,--enable-auto-import -version-info 0:1:0 -L/usr/local/lib -o libevil.la -rpath /usr/local/lib libevil_la-evil_errno.lo libevil_la-evil_fcntl.lo libevil_la-evil_fnmatch.lo libevil_la-evil_fnmatch_list_of_states.lo libevil_la-evil_langinfo.lo libevil_la-evil_mman.lo libevil_la-evil_pwd.lo libevil_la-evil_stdlib.lo libevil_la-evil_stdio.lo libevil_la-evil_string.lo libevil_la-evil_time.lo libevil_la-evil_unistd.lo libevil_la-evil_util.lo -lole32 -luuid -lws2_32 -lsecur32 libtool: link: rm -fr .libs/libevil.a .libs/libevil.la .libs/libevil.lai *** Warning: linker path does not have real file for library -luuid. *** I have the capability to make that library automatically link in when *** you link to this library. But I can only do this if you have a *** shared version of the library, which you do not appear to have *** because I did check the linker path looking for a file starting *** with libuuid and none of the candidates passed a file format test *** using a file magic. Last file checked: /mingw/lib//libuuid.a *** The inter-library dependencies that have been dropped here will be *** automatically added whenever a program is linked with this library *** or is declared to -dlopen it. *** Since this library must not contain undefined symbols, *** because either the platform does not support them or *** it was explicitly requested with -no-undefined, *** libtool will only create a static version of it. ... which then, later on, fails completely when it goes to make the shared lib. libuuid.a exists at c:/msys/1.0/mingw/lib/ The frustrating thing is that from googling and reading emails vincent has written i thought that this error was from having too old a libtool version... ive since re-installed my msys/mingw 4 times being absolutely to follow wiki instructions to the letter making sure all my versions match. even tried the latest libtool but to no avail.. so i guess it has nothing to do with libtools version(in this case) I'm just out of ideas for now and google aint got answers for me today. it just sucks that i remember this happening the first time and getting around it, but i cant remember how... cheers :) - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] evil trouble
On Sun, 26 Oct 2008, Samuel Nicholas wrote: hay guise cause eina has recently been added as a dependancy i was updating my libs and ran into trouble... so i decided to start from scratch again. now i have a problem I didn't have before [snip] ive since re-installed my msys/mingw 4 times being absolutely to follow wiki instructions to the letter making sure all my versions match. even tried the latest libtool but to no avail.. so i guess it has nothing to do with libtools version(in this case) It is a libtool problem. Which version did you installed, exactly ? Vincent - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] evil trouble
On Sun, Oct 26, 2008 at 06:26:01PM +1030, Samuel Nicholas wrote: libuuid.a exists at c:/msys/1.0/mingw/lib/ Only the static archive or also a shared library? The reason libtool is complaining is it only finds the former. Joerg - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] evil trouble
On Sun, Oct 26, 2008 at 06:26:01PM +1030, Samuel Nicholas wrote: hay guise cause eina has recently been added as a dependancy i was updating my libs and ran into trouble... so i decided to start from scratch again. now i have a problem I didn't have before when compiling evil: ... /bin/sh ../../libtool --tag=CC --mode=link gcc -g -O2 -no-undefined -Wl,--enable-auto-import -version-info 0:1:0 -L/usr/local/lib -o libevil.la -rpath /usr/local/lib libevil_la-evil_errno.lo libevil_la-evil_fcntl.lo libevil_la-evil_fnmatch.lo libevil_la-evil_fnmatch_list_of_states.lo libevil_la-evil_langinfo.lo libevil_la-evil_mman.lo libevil_la-evil_pwd.lo libevil_la-evil_stdlib.lo libevil_la-evil_stdio.lo libevil_la-evil_string.lo libevil_la-evil_time.lo libevil_la-evil_unistd.lo libevil_la-evil_util.lo -lole32 -luuid -lws2_32 -lsecur32 libtool: link: rm -fr .libs/libevil.a .libs/libevil.la .libs/libevil.lai *** Warning: linker path does not have real file for library -luuid. *** I have the capability to make that library automatically link in when *** you link to this library. But I can only do this if you have a *** shared version of the library, which you do not appear to have *** because I did check the linker path looking for a file starting *** with libuuid and none of the candidates passed a file format test *** using a file magic. Last file checked: /mingw/lib//libuuid.a *** The inter-library dependencies that have been dropped here will be *** automatically added whenever a program is linked with this library *** or is declared to -dlopen it. *** Since this library must not contain undefined symbols, *** because either the platform does not support them or *** it was explicitly requested with -no-undefined, *** libtool will only create a static version of it. ... which then, later on, fails completely when it goes to make the shared lib. libuuid.a exists at c:/msys/1.0/mingw/lib/ Do you have the file utility installed in mingw? Having this utility will make libtool fail in this manor, because it will detect libraries differently, since file can tell the difference between a static library and a dll. The above also happens if you try to cross compile evil linux-mingw. IMHO it is not a libtool problem, but the problem is that evil.dll tries to link to at static library (uuid in this case), which is generally considered bad. I currently use the attached patch to get around this problem. Regards Lars Munch Index: src/lib/evil_uuid.c === --- src/lib/evil_uuid.c (revision 0) +++ src/lib/evil_uuid.c (revision 0) @@ -0,0 +1,12 @@ +/* + * This file defines all the windows UUID used in evil. This is here + * since uuid.lib is a static only library and libtool does not allow + * you to link a DLL against a static library. + */ +#ifndef __CEGCC__ + +#define INITGUID +#include basetyps.h +DEFINE_OLEGUID(IID_IPersistFile, 0x010BL, 0, 0); + +#endif Index: src/lib/Makefile.am === --- src/lib/Makefile.am (revision 37141) +++ src/lib/Makefile.am (working copy) @@ -36,7 +36,8 @@ evil_string.c \ evil_time.c \ evil_unistd.c \ -evil_util.c +evil_util.c \ +evil_uuid.c libevil_la_CPPFLAGS = @win32_cppflags@ libevil_la_CFLAGS = @win32_cflags@ Index: configure.ac === --- configure.ac (revision 37141) +++ configure.ac (working copy) @@ -35,7 +35,7 @@ win32_libs= case $host_os in mingw | mingw32 | mingw32msvc) -win32_libs=-lole32 -luuid -lws2_32 -lsecur32 +win32_libs=-lole32 -lws2_32 -lsecur32 ;; cegcc*) win32_libs=-lws2 - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] evil trouble
On Sun, 26 Oct 2008, Joerg Sonnenberger wrote: On Sun, Oct 26, 2008 at 06:26:01PM +1030, Samuel Nicholas wrote: libuuid.a exists at c:/msys/1.0/mingw/lib/ Only the static archive or also a shared library? The reason libtool is complaining is it only finds the former. the problem is that libtool is not detecting that libuuid.a is an import library Vincent - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] evil trouble
On Sun, 26 Oct 2008, Lars Munch wrote: IMHO it is not a libtool problem, but the problem is that evil.dll tries to link to at static library (uuid in this case), which is generally considered bad. it is a libtool problem, in a manner or another. Your remark: + * This file defines all the windows UUID used in evil. This is here + * since uuid.lib is a static only library and libtool does not allow + * you to link a DLL against a static library. is wrong. We can link a lib against a static lib to produce a dll. Check when I link against libm.a, libws2_32.a, etc... in evil or other efl lib. There is no dll for those lib. But libtool detects that it is an import lib (look at the function func_win32_libid() in ltmain.sh or libtool scripts) and accepts to create the dll. about the 'file' program, i didn't know. Vincent - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] evil trouble
On Sun, 26 Oct 2008, Samuel Nicholas wrote: hay guise cause eina has recently been added as a dependancy i was updating my libs and ran into trouble... so i decided to start from scratch again. now i have a problem I didn't have before when compiling evil: *** Warning: linker path does not have real file for library -luuid. *** I have the capability to make that library automatically link in when *** you link to this library. But I can only do this if you have a *** shared version of the library, which you do not appear to have *** because I did check the linker path looking for a file starting *** with libuuid and none of the candidates passed a file format test *** using a file magic. Last file checked: /mingw/lib//libuuid.a *** The inter-library dependencies that have been dropped here will be *** automatically added whenever a program is linked with this library *** or is declared to -dlopen it. *** Since this library must not contain undefined symbols, *** because either the platform does not support them or *** it was explicitly requested with -no-undefined, *** libtool will only create a static version of it. ... i think that you will hate me: i don't have the problem... I don't know what to say. May as Lars said, a program that makes libtool crazy. Vincent - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] evil trouble
On Sun, Oct 26, 2008 at 04:59:19PM +0100, Vincent Torri wrote: On Sun, 26 Oct 2008, Lars Munch wrote: IMHO it is not a libtool problem, but the problem is that evil.dll tries to link to at static library (uuid in this case), which is generally considered bad. it is a libtool problem, in a manner or another. Your remark: + * This file defines all the windows UUID used in evil. This is here + * since uuid.lib is a static only library and libtool does not allow + * you to link a DLL against a static library. is wrong. We can link a lib against a static lib to produce a dll. Check when I link against libm.a, libws2_32.a, etc... in evil or other efl lib. There is no dll for those lib. But libtool detects that it is an import lib (look at the function func_win32_libid() in ltmain.sh or libtool scripts) and accepts to create the dll. But there are dll's for those libs: libws2_32.a is an import library for windows\system32\ws2_32.dll. libole32.a is an import library for windows\system32\ole32.dll. libsecur32.a is an import library for windows\system32\secur32.dll. libuuid.a on the other hand is not an import library but a real static library, hence the error when not detected as an import library. about the 'file' program, i didn't know. The func_win32_libid function is different if you got the file utility on your system (as most people do on linux). This version is actually better at identifying a static library vs. import library. See for instance: http://www.cygwin.com/ml/cygwin/2003-02/msg01464.html I went for a modified version of point 1) in my patch. -- Lars Munch - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] evil trouble
On Sun, 26 Oct 2008, Lars Munch wrote: libuuid.a on the other hand is not an import library but a real static library, hence the error when not detected as an import library. if so, then your approach is better. But instead of adding a new file, i would put it directly in evil_unistd.c, as I use that value only here. and about symlink, after some new searches, it seems that my code is not correct (4th parameter of CoCreateInstance) and in addition can be simplified (no need of lpVtbl pointer). I'll add a unit test for that function. That would also help the cross-compilation on linux too. I'll do that tomorrow. thank you Vincent - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] evil trouble
Hey
I had to compile the link code with g++, hence putting IID_PersistFile was
not possible (at least, i didn't succeed). So I put the code in a separate
file like Lars did.
I've attached a patch. Please test it. It compiles correctly on my system.
VincentIndex: src/lib/evil_uuid.c
===
--- src/lib/evil_uuid.c (révision 0)
+++ src/lib/evil_uuid.c (révision 0)
@@ -0,0 +1,13 @@
+
+#if ! defined(__CEGCC__) ! defined(__MINGW32CE__)
+/*
+ * Defines the windows UUID IID_IPersistFile used for links in
+ * evil. This is here since uuid.lib is a static only library and
+ * libtool does not allow you to link a DLL against a static library.
+ */
+
+# define INITGUID
+# include basetyps.h
+DEFINE_OLEGUID(IID_IPersistFile, 0x010BL, 0, 0);
+
+#endif /* ! __CEGCC__ ! __MINGW32CE__ */
Index: src/lib/evil_unistd.cpp
===
--- src/lib/evil_unistd.cpp (révision 0)
+++ src/lib/evil_unistd.cpp (révision 0)
@@ -0,0 +1,430 @@
+
+#ifdef HAVE_CONFIG_H
+# include config.h
+#endif /* HAVE_CONFIG_H */
+
+#ifdef HAVE_ERRNO_H
+#include errno.h
+#endif /* HAVE_ERRNO_H */
+
+#define WIN32_LEAN_AND_MEAN
+#include winsock2.h
+#undef WIN32_LEAN_AND_MEAN
+
+#if defined(_MSC_VER) || \
+ (defined(__MINGW32__) ! defined(__MINGW32CE__))
+# include shlobj.h
+# include objidl.h
+#endif
+
+#include Evil.h
+#include evil_private.h
+
+/*
+ * Process identifer related functions
+ *
+ */
+
+pid_t
+getpid(void)
+{
+ return (pid_t)GetCurrentProcessId();
+}
+
+
+/*
+ * Symbolic links and directory related functions
+ *
+ */
+
+#if defined(__CEGCC__) || defined(__MINGW32CE__)
+
+DWORD SHCreateShortcutEx(LPTSTR lpszDir,
+ LPTSTR lpszTarget,
+ LPTSTR szShortcut,
+ LPDWORD lpcbShortcut);
+
+BOOL SHGetShortcutTarget(LPTSTR szShortcut,
+ LPTSTR szTarget,
+ int cbMax );
+
+#endif /* __CEGCC__ || __MINGW32CE__ */
+
+
+/* REMARK: Windows has no symbolic link. */
+/* Nevertheless, it can create and read .lnk files */
+int
+symlink(const char *oldpath, const char *newpath)
+{
+#if defined(__CEGCC__) || defined(__MINGW32CE__)
+ wchar_t *w_oldpath;
+ wchar_t *w_newpath;
+ BOOL res;
+
+ w_oldpath = evil_char_to_wchar(oldpath);
+ if (!w_oldpath)
+ return -1;
+
+ w_newpath = evil_char_to_wchar(newpath);
+ if (!w_newpath)
+ {
+free(w_oldpath);
+return -1;
+ }
+
+ res = SHCreateShortcutEx(w_newpath, w_oldpath, NULL, NULL);
+
+ free(w_oldpath);
+ free(w_newpath);
+
+ return res ? 0 : -1;
+#else
+ wchar_tnew_path[MB_CUR_MAX];
+ IShellLink*pISL;
+ IShellLink **shell_link;
+ IPersistFile *pIPF;
+ IPersistFile **persit_file;
+ HRESULTres;
+
+ res = CoInitialize(NULL);
+ if (FAILED(res))
+ {
+if (res == E_OUTOFMEMORY)
+#ifdef HAVE_ERRNO_H
+ errno = ENOMEM;
+#endif /* HAVE_ERRNO_H */
+return -1;
+ }
+
+ /* Hack to cleanly remove a warning */
+ shell_link = pISL;
+ if (FAILED(CoCreateInstance(CLSID_ShellLink,
+ NULL,
+ CLSCTX_INPROC_SERVER,
+ IID_IShellLink,
+ (void **)shell_link)))
+ goto no_instance;
+
+ if (FAILED(pISL-SetPath(oldpath)))
+ goto no_setpath;
+
+ /* Hack to cleanly remove a warning */
+ persit_file = pIPF;
+ if (FAILED(pISL-QueryInterface(IID_IPersistFile, (void **)persit_file)))
+ goto no_queryinterface;
+
+ mbstowcs(new_path, newpath, MB_CUR_MAX);
+ if (FAILED(pIPF-Save(new_path, FALSE)))
+ goto no_save;
+
+ pIPF-Release();
+ pISL-Release();
+ CoUninitialize();
+
+ return 0;
+
+ no_save:
+ pIPF-Release();
+ no_queryinterface:
+ no_setpath:
+ pISL-Release();
+ no_instance:
+ CoUninitialize();
+ return -1;
+#endif /* ! __CEGCC__ ! __MINGW32CE__ */
+}
+
+ssize_t
+readlink(const char *path, char *buf, size_t bufsiz)
+{
+#if defined(__CEGCC__) || defined(__MINGW32CE__)
+ wchar_t *w_path;
+ wchar_t w_newpath[MB_CUR_MAX];
+ char*newpath;
+ size_t length;
+ BOOL res;
+
+ w_path = evil_char_to_wchar(path);
+ if (!w_path)
+ return -1;
+
+ res = SHGetShortcutTarget(w_path, w_newpath, MB_CUR_MAX);
+
+ free(w_path);
+
+ if (!res)
+ return -1;
+
+ newpath = evil_wchar_to_char(w_newpath);
+ if (!newpath)
+ return -1;
+
+ length = strlen(newpath);
+ if (length bufsiz)
+ length = bufsiz;
+
+ memcpy(buf, newpath, length);
+
+ free(newpath);
+
+ return length;
+#else
+ wchar_told_path[MB_CUR_MAX];
+ char new_path[PATH_MAX];
+ IShellLink*pISL;
+ IShellLink **shell_link;
+ IPersistFile *pIPF;
+ IPersistFile **persit_file;
+ unsigned int length;
+ HRESULTres;
+
+ res =
