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 packages...] 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 mentioned sooner.
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 there!
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 this time. Sorry for all the trouble 8-} Alexis
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.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.