I'm having problems with pkg-config under MSYS, strings break and I get the
wrong output (thought no crash happen, it still is broken). It looks like you
have bad memory management so I've been looking for bugs in that area. Notice
that I already "fixed" the problem by not removing duplicates in the output, but
of course that's not the best solution and it does not really fix anything.
Anyway, I'll be back later for these.
At this time, I found one bug in version 0.21 in pkg.c at line #191 you have:
char *pkgname = malloc (len - 2);
It MUST be a g_malloc() to match any future g_free() [of which you have one just
a bit lower and I'd bet you g_free() the names when you clear the table of
I'll post a patch once I'm finished with my hunt of memory bugs!
Okay, I got many others! 8-}
The poptParseArgvString() function called, for instance, from parse_libs()
returns a new buffer in the variable 'argv' which you g_free() a little lower in
that function. Argh! This is totally wrong because poptParseArgvString() does
malloc() and free() only (it is not glib aware--should we change that? that's
what I'm gonna do now!)
So here again you were likely destroying memory big time. Patch later, as I
Okay... two things: I was linking against my compiled version of glib and thus
g_malloc() == malloc() and g_free() == free() by default! So no worry there I
guess. I'll still send a patch with my changes.
I looked all around and I could not really find a problem. Yet, the alloca()
function did not need to be defined as you had it. It is available in glib so
all you have to do is include glib.h and you have it.
I suggest the addition of a file named pkg-glib.h and the removal of the
partial-glib.h (the new name makes more sense). It functions the same way, but
all the .c file include it (the popt*.c files too in order to ge the alloca() file).
That is, if you accept my changes... 8-)
So all of that to say that I'm not too sure what the problem was!
Ha! One thing however, which I did not really fix correctly, is the default path
in the main.c file. You define it on the command line with -D...="\"blah\"".
That does not work under MinGW and propably other systems. I get many errors
about extranous backslashes. That's why the pre-compiled version of pkg-config
could never find my files even thought they were at the right place! You need to
have a .h.in with the info (config.h.in would work, you just need to substitute
that variable too.) Another way is to change the main.c into main.c.in but I
think many people would not like that. I'll be glad to make that work for you, I
just need to know how you want to proceed.
Finally, there is another possibly "more serious" problem: the default path
separator under MinGW, according to glib, is ';' and not ':'. I'm not too sure
how to handle that one because MinGW without MSYS, that's correct! (;) but with
MSYS, it's wrong. Since I do not myself need more than one path, I'm fine, but
it could be a problem for some other people.
Created attachment 7890 [details] [review]
g_malloc/free/realloc/strdup + alloca() definitions removal
WARNING: DO NOT INCLUDE main.c; I put it in there so you can see what I used to
test the memory but the path for the default directories is hard-coded in
Okay! I got the gtk+ configuration script to work.
The problem must be the shell because they have something like this:
VAR="`pkg-config --cflags ...` $var1 $var2 ..."
and it breaks after the closing ` by adding a \x01 and ignoring the other variables.
I moved the extras variables first (which is totally fine for MSYS) and the
problem goes away!
VAR="$var1 $var2 ... `pkg-config --cflags ...`"
So really, the only problem I can see is the default path which does not work at
Sorry for all the trouble 8-}
Since popt is removed, I'm pretty sure anything that allocates memory in pkg-config is going through the glib routines except for alloca in rpmvercmp. Since I know people have that working on MSYS (I've done it myself), I'm going to say that this is resolved. Please reopen if you're still finding memory corruption.
And the bug with the \x01 was indeed a MSYS shell bug.