building on mingw #17
Labels
No Milestone
No project
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: ariadne/pkgconf#17
Loading…
Reference in New Issue
There is no content yet.
Delete Branch "%!s(<nil>)"
Deleting a branch is permanent. Although the deleted branch may exist for a short time before cleaning up, in most cases it CANNOT be undone. Continue?
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.
For
alloca()
, I think it should#include <alloca.h>
instead, per the manpage.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?
On Wed, May 9, 2012 1:45 pm, William Pitcock wrote:
I don't have git running on any of my machines at this point, so all I can
do submit patches.
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.
On Wed, May 9, 2012 6:39 pm, William Pitcock wrote:
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
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?
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.
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).
On Fri, May 11, 2012 11:20 am, Michał Górny wrote:
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:
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.
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
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.
On Fri, 11 May 2012 17:45:02 -0700
William Pitcock
reply@reply.github.com
wrote:
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
can you test this commit? it should be functionally equivalent to the patch you submitted. if it doesn't work, include compile errors etc.
seems to work for me with mingw-crosscompiler. if not, we'll do a 0.8.1.
On Sat, May 12, 2012 12:27 am, William Pitcock wrote:
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=""
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.
On Sun, July 1, 2012 8:45 pm, William Pitcock wrote:
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.