pkgconf --list-all includes extra '/' character in front of each package name on Windows #209
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?
On Windows, running
pkgconf --list-all
prints the name of each package with an extra/
character at the front:Compare this to the output of
pkg-config --list-all
:This isn't just a cosmetic issue, as the
cabal-install
tool, which usespkg-config --list-all
to determine what packages are available, fails to parse when the extra/
is present. As a result, it's impossible to usecabal-install
withpkg-config
symlinked topkgconf
.I am not at all familiar with the codebase, but I took a shot at attempting to diagnose the issue. I've narrowed down to this code:
869f2a84d6/libpkgconf/pkg.c (L387-L400)
The
pkg->id = strdup(idptr);
part is where a string like/sdl2.pc
is given to a particularpkg
, and the two lines after that remove the.pc
extension, leaving just/sdl2
. Before the#ifdef _WIN32
part,idptr
is an absolute path likeC:/msys64/mingw64/lib/pkgconfig/sdl2.pc
, so that part of the code removes everything up to (but not including) the last/
character. Why doesn't it remove the last/
character? I think it's because of this line:869f2a84d6/libpkgconf/pkg.c (L394)
If I'm reading that correctly, this will make
idptr
point to the same string asmungeptr
and then incrementmungeptr
's address. For example, ifmungeptr
is/sdl2.pc
before this line of code, then afterwardsidptr
will be/sdl2.pc
andmungeptr
will besdl2.pc
. This means thatmungeptr
actually points to the string that we want, butmungeptr
is never used again after this line of code.One possible fix would be to increment
mungeptr
before assigning it toidptr
, like so:This fixes the issue for me locally.
See #210.