building on mingw #17

New Issue

ariadne · 2012-05-09T19:04:37Z

lm8 commented

2012-05-09 19:04:37 +00:00

(Migrated from github.com)

Really nice program. I've been looking for a pkg-config replacement that doesn't require glib.

Tried building the application using mingw and msys. Had trouble compiling. It couldn't find alloca needed in pkg.c. Also noticed there's some code in the program to check the registry on Windows. Is there any way to optionally avoid the code so that it doesn't have to run? Maybe a flag or environment variable could be set to use (or avoid the registry)? Some Windows users like myself prefer to run portable apps and avoid registry calls if possible. Don't know if it'll format properly, but am adding a patch below that fixes the alloca issue and a problem I had with the makefile's default definition of -DPKG_DEFAULT_PATH (which also prevented compilation). If no environment variable is found for PKG_CONFIG_LIBDIR, this will look for the .pc files in ..\lib\pkgconfig. So, if I place the program in the /usr/local/bin directory within msys, it looks for the pkgconfig files within the msys directory under \usr\local\lib\pkgconfig.

diff -Naurp src/nenolod-pkgconf-b408a62/pkg.c tmp/nenolod-pkgconf-b408a62/pkg.c
--- src/nenolod-pkgconf-b408a62/pkg.c   2012-05-07 05:04:41 -0400
+++ tmp/nenolod-pkgconf-b408a62/pkg.c   
@@ -279,6 +279,12 @@ pkg_find(const char *name, unsigned int
    const char *env_path;
    pkg_t *pkg = NULL;
    FILE *f;
+#ifdef _WIN32   
+   char namebuf[MAX_PATH];
+   int i;
+   int loop;
+   size_t cnt;
+#endif   
 
    /* name might actually be a filename. */
    if (str_has_suffix(name, PKG_CONFIG_EXT))
@@ -303,7 +309,27 @@ pkg_find(const char *name, unsigned int
 
    env_path = getenv("PKG_CONFIG_LIBDIR");
    if (env_path == NULL)
+#ifndef _WIN32      
        env_path = PKG_DEFAULT_PATH;
+#else
+      GetModuleFileName (NULL, namebuf, MAX_PATH);
+      loop = 0;
+      cnt = strlen (namebuf);
+      for (i = cnt - 1; i >= 0; i--)
+      {
+         if (namebuf[i] == '\\')
+         {
+            loop++;
+            if (loop >= 2)
+            {
+               namebuf[i] = '\0';
+               strcat (namebuf, "\\lib\\pkgconfig");
+               env_path = namebuf;
+               break;
+            }
+         }   
+      }   
+#endif   
 
    if (!(flags & PKGF_ENV_ONLY))
    {
diff -Naurp src/nenolod-pkgconf-b408a62/pkg.h tmp/nenolod-pkgconf-b408a62/pkg.h
--- src/nenolod-pkgconf-b408a62/pkg.h   2012-05-07 05:04:41 -0400
+++ tmp/nenolod-pkgconf-b408a62/pkg.h   
@@ -32,6 +32,9 @@
 #include <stdlib.h>
 #include <stdbool.h>
 #include <string.h>
+#ifdef _WIN32
+#include <malloc.h>
+#endif
 
 #ifndef BUFSIZ
 #define BUFSIZ 65535

Really nice program. I've been looking for a pkg-config replacement that doesn't require glib. Tried building the application using mingw and msys. Had trouble compiling. It couldn't find alloca needed in pkg.c. Also noticed there's some code in the program to check the registry on Windows. Is there any way to optionally avoid the code so that it doesn't have to run? Maybe a flag or environment variable could be set to use (or avoid the registry)? Some Windows users like myself prefer to run portable apps and avoid registry calls if possible. Don't know if it'll format properly, but am adding a patch below that fixes the alloca issue and a problem I had with the makefile's default definition of -DPKG_DEFAULT_PATH (which also prevented compilation). If no environment variable is found for PKG_CONFIG_LIBDIR, this will look for the .pc files in ..\lib\pkgconfig. So, if I place the program in the /usr/local/bin directory within msys, it looks for the pkgconfig files within the msys directory under \usr\local\lib\pkgconfig. <pre> diff -Naurp src/nenolod-pkgconf-b408a62/pkg.c tmp/nenolod-pkgconf-b408a62/pkg.c --- src/nenolod-pkgconf-b408a62/pkg.c 2012-05-07 05:04:41 -0400 +++ tmp/nenolod-pkgconf-b408a62/pkg.c @@ -279,6 +279,12 @@ pkg_find(const char *name, unsigned int const char *env_path; pkg_t *pkg = NULL; FILE *f; +#ifdef _WIN32 + char namebuf[MAX_PATH]; + int i; + int loop; + size_t cnt; +#endif /* name might actually be a filename. */ if (str_has_suffix(name, PKG_CONFIG_EXT)) @@ -303,7 +309,27 @@ pkg_find(const char *name, unsigned int env_path = getenv("PKG_CONFIG_LIBDIR"); if (env_path == NULL) +#ifndef _WIN32 env_path = PKG_DEFAULT_PATH; +#else + GetModuleFileName (NULL, namebuf, MAX_PATH); + loop = 0; + cnt = strlen (namebuf); + for (i = cnt - 1; i >= 0; i--) + { + if (namebuf[i] == '\\') + { + loop++; + if (loop >= 2) + { + namebuf[i] = '\0'; + strcat (namebuf, "\\lib\\pkgconfig"); + env_path = namebuf; + break; + } + } + } +#endif if (!(flags & PKGF_ENV_ONLY)) { diff -Naurp src/nenolod-pkgconf-b408a62/pkg.h tmp/nenolod-pkgconf-b408a62/pkg.h --- src/nenolod-pkgconf-b408a62/pkg.h 2012-05-07 05:04:41 -0400 +++ tmp/nenolod-pkgconf-b408a62/pkg.h @@ -32,6 +32,9 @@ #include <stdlib.h> #include <stdbool.h> #include <string.h> +#ifdef _WIN32 +#include <malloc.h> +#endif #ifndef BUFSIZ #define BUFSIZ 65535 </pre>

mgorny commented

2012-05-09 19:33:26 +00:00

(Migrated from github.com)

For alloca(), I think it should #include <alloca.h> instead, per the manpage.

For `alloca()`, I think it should `#include <alloca.h>` instead, per the manpage.

ariadne commented

2012-05-09 20:45:40 +00:00

Agreed, we should pull in alloca.h. Can you submit this as a proper pull request so we can review the remaining issues more effectively?

lm8 commented

2012-05-09 22:09:46 +00:00

(Migrated from github.com)

On Wed, May 9, 2012 1:45 pm, William Pitcock wrote:

Agreed, we should pull in alloca.h. Can you submit this as a proper pull
request so we can review the remaining issues more effectively?

I don't have git running on any of my machines at this point, so all I can
do submit patches.

On Wed, May 9, 2012 1:45 pm, William Pitcock wrote: > Agreed, we should pull in alloca.h. Can you submit this as a proper pull > request so we can review the remaining issues more effectively? I don't have git running on any of my machines at this point, so all I can do submit patches.

ariadne commented

2012-05-10 01:39:48 +00:00

Would it be possible to use / as filesystem path delimiter? Both \ and / are legal for path delimiting on Windows, and would result in slightly cleaner code.

lm8 commented

2012-05-10 21:59:34 +00:00

(Migrated from github.com)

On Wed, May 9, 2012 6:39 pm, William Pitcock wrote:

Would it be possible to use / as filesystem path delimiter? Both \ and /
are legal for path delimiting on Windows, and would result in slightly
cleaner code.

It works in systems that are built with msys or cygwin or with
cross-platform libraries, but I'm thinking when you get to the low level
calls like for opening files, it'll fail on Windows. I believe mingw just
wraps the native msvcrt.dll (Windows runtime dll) and it wasn't designed
for POSIX compatibility. I will double check and try it out on my system
though and let you know if it works. Since the section is ifdef'd and
using a Windows specific call anyway, I don't think a Windows specific
directory path delimiter should be an issue. What I usually do on my own
code is create a define for the delimiter that's specific to the operating
system and use the define exclusively instead of hard-coding slashes and
backslashes. Will test out using / tomorrow and let you know the results.

By the way, I added a mention of pkgconf at the MinGW site in the
Community Supplied links.

Sincerely,
Laura
http://www.distasis.com/cpp

On Wed, May 9, 2012 6:39 pm, William Pitcock wrote: > Would it be possible to use / as filesystem path delimiter? Both \ and / > are legal for path delimiting on Windows, and would result in slightly > cleaner code. It works in systems that are built with msys or cygwin or with cross-platform libraries, but I'm thinking when you get to the low level calls like for opening files, it'll fail on Windows. I believe mingw just wraps the native msvcrt.dll (Windows runtime dll) and it wasn't designed for POSIX compatibility. I will double check and try it out on my system though and let you know if it works. Since the section is ifdef'd and using a Windows specific call anyway, I don't think a Windows specific directory path delimiter should be an issue. What I usually do on my own code is create a define for the delimiter that's specific to the operating system and use the define exclusively instead of hard-coding slashes and backslashes. Will test out using / tomorrow and let you know the results. By the way, I added a mention of pkgconf at the MinGW site in the Community Supplied links. Sincerely, Laura http://www.distasis.com/cpp

ariadne commented

2012-05-11 05:09:40 +00:00

hi,

using / as path separator will work on NT-based windows, as NT's filesystem service considers both / and \ to be path separators.

you are right that / path separator won't work on DOS-based windows, but do those really matter?

hi, using / as path separator will work on NT-based windows, as NT's filesystem service considers both / and \ to be path separators. you are right that / path separator won't work on DOS-based windows, but do those really matter?

mgorny commented

2012-05-11 18:20:46 +00:00

(Migrated from github.com)

I don't think it's even possible to run MinGW on those nowadays. Not to mention last time I tried, win9x didn't support my CPU...

nenolod, maybe we should make pkgconf quasi-modular, having modules like 'unix' (for PKG_CONFIG_PATH), 'registry', 'local' (using relative path; I think we could support this in a more portable manner using argv[0]). Then user could specify necessary modules to ./configure.

I don't think it's even possible to run MinGW on those nowadays. Not to mention last time I tried, win9x didn't support my CPU... nenolod, maybe we should make pkgconf quasi-modular, having modules like 'unix' (for PKG_CONFIG_PATH), 'registry', 'local' (using relative path; I think we could support this in a more portable manner using argv[0]). Then user could specify necessary modules to ./configure.

ariadne commented

2012-05-11 18:34:48 +00:00

this sounds like a good plan. i'll hack it up this weekend (would do it now but i have to get my house presentable for guests which are coming).

lm8 commented

2012-05-11 21:01:32 +00:00

(Migrated from github.com)

On Fri, May 11, 2012 11:20 am, Michał Górny wrote:

I don't think it's even possible to run MinGW on those nowadays. Not to
mention last time I tried, win9x didn't support my CPU...

Actually, there's a project to keep running MinGW and other newer Windows
programs on older systems (Win9x). The last machine I had that was
running Win9x is currently running FreeBSD now. So, I personally don't
have any test machines to try that. I do still test out some applications
with djgpp though.

I switched the \ in the patch to / as below:

          strcat (namebuf, "/lib/pkgconfig");

Looks like the fopen on Windows call is working fine either way and
doesn't care if part of the path is / instead of . I only tested this on
Windows 7 at this point.

nenolod, maybe we should make pkgconf quasi-modular, having modules like
'unix' (for PKG_CONFIG_PATH), 'registry', 'local' (using relative path; I
think we could support this in a more portable manner using argv[0]).
Then user could specify necessary modules to ./configure.

Having access to argv[0] to get the executable location on all systems
would be a nice feature for anyone wanting to use relative paths. Don't
know how many Linux users are into portable apps and being able to run
programs for other than standard directories, but I think it's pretty
popular on Windows.

Thanks for looking into this. If you need any testing done on Windows or
FreeBSD, let me know.

Sincerely,
Laura
http://www.distasis.com/cpp

On Fri, May 11, 2012 11:20 am, Michał Górny wrote: > I don't think it's even possible to run MinGW on those nowadays. Not to > mention last time I tried, win9x didn't support my CPU... Actually, there's a project to keep running MinGW and other newer Windows programs on older systems (Win9x). The last machine I had that was running Win9x is currently running FreeBSD now. So, I personally don't have any test machines to try that. I do still test out some applications with djgpp though. I switched the \ in the patch to / as below: - strcat (namebuf, "/lib/pkgconfig"); Looks like the fopen on Windows call is working fine either way and doesn't care if part of the path is / instead of . I only tested this on Windows 7 at this point. > nenolod, maybe we should make pkgconf quasi-modular, having modules like > 'unix' (for PKG_CONFIG_PATH), 'registry', 'local' (using relative path; I > think we could support this in a more portable manner using argv[0]). > Then user could specify necessary modules to ./configure. Having access to argv[0] to get the executable location on all systems would be a nice feature for anyone wanting to use relative paths. Don't know how many Linux users are into portable apps and being able to run programs for other than standard directories, but I think it's pretty popular on Windows. Thanks for looking into this. If you need any testing done on Windows or FreeBSD, let me know. Sincerely, Laura http://www.distasis.com/cpp

ariadne commented

2012-05-12 00:45:02 +00:00

hi,

primary concern with using argv[0] directly for relative path discovery is that we plan to turn pkgconf core into a library for use with other applications (say gcc itself so you can specify "-framework gtk+-2.0") down the line (pkgconf 0.9).

we should add an API to set/retrieve the running pathname, that way it doesn't clash with pkgconf 0.9 plans.

hi, primary concern with using argv[0] directly for relative path discovery is that we plan to turn pkgconf core into a library for use with other applications (say gcc itself so you can specify "-framework gtk+-2.0") down the line (pkgconf 0.9). we should add an API to set/retrieve the running pathname, that way it doesn't clash with pkgconf 0.9 plans.

mgorny commented

2012-05-12 06:16:08 +00:00

(Migrated from github.com)

On Fri, 11 May 2012 17:45:02 -0700
William Pitcock
reply@reply.github.com
wrote:

primary concern with using argv[0] directly for relative path
discovery is that we plan to turn pkgconf core into a library for use
with other applications (say gcc itself so you can specify
"-framework gtk+-2.0") down the line (pkgconf 0.9).

we should add an API to set/retrieve the running pathname, that way
it doesn't clash with pkgconf 0.9 plans.

True. But this way, it is likely to get overcomplex. Maybe we'll just
stay with with GetModulePath(), and think about it again whenever
someone actually wants that on unix.

Best regards,
Michał Górny

On Fri, 11 May 2012 17:45:02 -0700 William Pitcock reply@reply.github.com wrote: > primary concern with using argv[0] directly for relative path > discovery is that we plan to turn pkgconf core into a library for use > with other applications (say gcc itself so you can specify > "-framework gtk+-2.0") down the line (pkgconf 0.9). > > we should add an API to set/retrieve the running pathname, that way > it doesn't clash with pkgconf 0.9 plans. True. But this way, it is likely to get overcomplex. Maybe we'll just stay with with GetModulePath(), and think about it again whenever someone actually wants that on unix. ## Best regards, Michał Górny

ariadne commented

2012-05-12 07:27:44 +00:00

can you test this commit? it should be functionally equivalent to the patch you submitted. if it doesn't work, include compile errors etc.

ariadne commented

2012-05-12 08:02:34 +00:00

seems to work for me with mingw-crosscompiler. if not, we'll do a 0.8.1.

lm8 commented

2012-05-16 20:29:58 +00:00

(Migrated from github.com)

On Sat, May 12, 2012 12:27 am, William Pitcock wrote:

can you test this commit?

Downloaded nenolod-pkgconf-pkgconf-0.8-2-g495f586.tar.gz

The code now reads:
#ifdef _WIN32
GetModuleFileName(NULL, namebuf, sizeof namebuf);

p = strrchr(namebuf, '');
if (p == NULL)
p = strrchr(namebuf, '/');
if (p == NULL)
return PKG_DEFAULT_PATH;

*p = '\0';
strlcpy(outbuf, namebuf, sizeof outbuf);
strlcat(outbuf, "/lib/pkgconfig", sizeof outbuf);

return outbuf;
#endif

So on my system that makes namebuf:
C:\mingw\msys\usr\local\bin\pkgconf.exe

The first strrchr finds the backslash before pkgconf.exe.
The second strrchr doesn't find a forward slash.
That makes the outbuf:
C:\mingw\msys\usr\local\bin/lib/pkgconfig

I think the second strrchr needs a backslash ('') in order to find the
bin directory in the filepath
provided by GetModeuleFileName and remove it. I don't think most users
will be keeping their
lib files under the bin directory (even on Windows).

I'm also still having some trouble with the Makefile on Windows.

-DPKG_DEFAULT_PATH="{libdir}/pkgconfig:{datadir}/pkgconfig"

used by pkg.c line 112 (return PKG_DEFAULT_PATH;) causes the following error:

CompileExe: pkg.o
pkg.c: In function 'get_pkgconfig_path':
pkg.c:112:10: warning: unknown escape sequence: '\m' [enabled by default]
pkg.c:112:10: warning: unknown escape sequence: '\m' [enabled by default]
pkg.c:112:10: error: incomplete universal character name \u
pkg.c:112:10: warning: unknown escape sequence: '\l' [enabled by default]
pkg.c:112:10: warning: unknown escape sequence: '\l' [enabled by default]
pkg.c:112:10: warning: unknown escape sequence: '\p' [enabled by default]
pkg.c:112:10: warning: unknown escape sequence: '\m' [enabled by default]
pkg.c:112:10: warning: unknown escape sequence: '\m' [enabled by default]
pkg.c:112:10: error: incomplete universal character name \u
pkg.c:112:10: warning: unknown escape sequence: '\l' [enabled by default]
pkg.c:112:10: warning: unknown escape sequence: '\s' [enabled by default]
pkg.c:112:10: warning: unknown escape sequence: '\p' [enabled by default]
pkg.c:121:9: warning: unknown escape sequence: '\m' [enabled by default]
pkg.c:121:9: warning: unknown escape sequence: '\m' [enabled by default]
pkg.c:121:9: error: incomplete universal character name \u
pkg.c:121:9: warning: unknown escape sequence: '\l' [enabled by default]
pkg.c:121:9: warning: unknown escape sequence: '\l' [enabled by default]
pkg.c:121:9: warning: unknown escape sequence: '\p' [enabled by default]
pkg.c:121:9: warning: unknown escape sequence: '\m' [enabled by default]
pkg.c:121:9: warning: unknown escape sequence: '\m' [enabled by default]
pkg.c:121:9: error: incomplete universal character name \u
pkg.c:121:9: warning: unknown escape sequence: '\l' [enabled by default]
pkg.c:121:9: warning: unknown escape sequence: '\s' [enabled by default]
pkg.c:121:9: warning: unknown escape sequence: '\p' [enabled by default]
pkg.c: In function 'pkg_find_in_registry_key':
pkg.c:293:4: warning: pointer targets in passing argument 1 of
'pkg_try_specific
_path' differ in signedness [-Wpointer-sign]
pkg.c:247:1: note: expected 'const char ' but argument is of type 'BYTE *'
make: ** [pkg.o] Error 1

It's being set in the Makefile by default on my system to:
"/usr/local/lib/pkgconfig:/usr/local/share/pkgconfig"

When I change the Makefile to use this, it builds with no errors:
-DPKG_DEFAULT_PATH=""

On Sat, May 12, 2012 12:27 am, William Pitcock wrote: > can you test this commit? Downloaded nenolod-pkgconf-pkgconf-0.8-2-g495f586.tar.gz The code now reads: #ifdef _WIN32 GetModuleFileName(NULL, namebuf, sizeof namebuf); p = strrchr(namebuf, '\'); if (p == NULL) p = strrchr(namebuf, '/'); if (p == NULL) return PKG_DEFAULT_PATH; *p = '\0'; strlcpy(outbuf, namebuf, sizeof outbuf); strlcat(outbuf, "/lib/pkgconfig", sizeof outbuf); return outbuf; #endif So on my system that makes namebuf: C:\mingw\msys\usr\local\bin\pkgconf.exe The first strrchr finds the backslash before pkgconf.exe. The second strrchr doesn't find a forward slash. That makes the outbuf: C:\mingw\msys\usr\local\bin/lib/pkgconfig I think the second strrchr needs a backslash ('\') in order to find the bin directory in the filepath provided by GetModeuleFileName and remove it. I don't think most users will be keeping their lib files under the bin directory (even on Windows). I'm also still having some trouble with the Makefile on Windows. -DPKG_DEFAULT_PATH=\"${libdir}/pkgconfig:${datadir}/pkgconfig\" used by pkg.c line 112 (return PKG_DEFAULT_PATH;) causes the following error: CompileExe: pkg.o pkg.c: In function 'get_pkgconfig_path': pkg.c:112:10: warning: unknown escape sequence: '\m' [enabled by default] pkg.c:112:10: warning: unknown escape sequence: '\m' [enabled by default] pkg.c:112:10: error: incomplete universal character name \u pkg.c:112:10: warning: unknown escape sequence: '\l' [enabled by default] pkg.c:112:10: warning: unknown escape sequence: '\l' [enabled by default] pkg.c:112:10: warning: unknown escape sequence: '\p' [enabled by default] pkg.c:112:10: warning: unknown escape sequence: '\m' [enabled by default] pkg.c:112:10: warning: unknown escape sequence: '\m' [enabled by default] pkg.c:112:10: error: incomplete universal character name \u pkg.c:112:10: warning: unknown escape sequence: '\l' [enabled by default] pkg.c:112:10: warning: unknown escape sequence: '\s' [enabled by default] pkg.c:112:10: warning: unknown escape sequence: '\p' [enabled by default] pkg.c:121:9: warning: unknown escape sequence: '\m' [enabled by default] pkg.c:121:9: warning: unknown escape sequence: '\m' [enabled by default] pkg.c:121:9: error: incomplete universal character name \u pkg.c:121:9: warning: unknown escape sequence: '\l' [enabled by default] pkg.c:121:9: warning: unknown escape sequence: '\l' [enabled by default] pkg.c:121:9: warning: unknown escape sequence: '\p' [enabled by default] pkg.c:121:9: warning: unknown escape sequence: '\m' [enabled by default] pkg.c:121:9: warning: unknown escape sequence: '\m' [enabled by default] pkg.c:121:9: error: incomplete universal character name \u pkg.c:121:9: warning: unknown escape sequence: '\l' [enabled by default] pkg.c:121:9: warning: unknown escape sequence: '\s' [enabled by default] pkg.c:121:9: warning: unknown escape sequence: '\p' [enabled by default] pkg.c: In function 'pkg_find_in_registry_key': pkg.c:293:4: warning: pointer targets in passing argument 1 of 'pkg_try_specific _path' differ in signedness [-Wpointer-sign] pkg.c:247:1: note: expected 'const char _' but argument is of type 'BYTE *' make: *_\* [pkg.o] Error 1 It's being set in the Makefile by default on my system to: "/usr/local/lib/pkgconfig:/usr/local/share/pkgconfig" When I change the Makefile to use this, it builds with no errors: -DPKG_DEFAULT_PATH=\"\"

ariadne commented

2012-07-02 03:45:06 +00:00

make check passes excluding 1 test (PKG_CONFIG_SYSROOT_DIR conformance which mingw seems to be breaking). please reopen if it doesn't work for you.

lm8 commented

2012-07-05 21:27:29 +00:00

(Migrated from github.com)

On Sun, July 1, 2012 8:45 pm, William Pitcock wrote:

make check passes excluding 1 test (PKG_CONFIG_SYSROOT_DIR conformance
which mingw seems to be breaking). please reopen if it doesn't work for
you.

Wasn't sure if you wanted a reply to this or not since you're closing
this, but I thought I'd just let you know, I tried the latest version out
on my end and it seems okay now.

On Sun, July 1, 2012 8:45 pm, William Pitcock wrote: > make check passes excluding 1 test (PKG_CONFIG_SYSROOT_DIR conformance > which mingw seems to be breaking). please reopen if it doesn't work for > you. Wasn't sure if you wanted a reply to this or not since you're closing this, but I thought I'd just let you know, I tried the latest version out on my end and it seems okay now.

Sign in to join this conversation.