When I try to check for a package using pkg-config it is not
  able to find the package even that it is properly installed.
  Current output
  $ pkg-config --modversion gthread-2.0
  Package gthread-2.0 was not found in the pkg-config search path.
  Perhaps you should add the directory containing `gthread-2.0.pc'
  to the PKG_CONFIG_PATH environment variable
  Package 'gthread-2.0', required by 'virtual:world', not found

  Workaround
  $ env PKG_CONFIG_PATH="$PKG_CONFIG_PATH:/usr/lib/x86_64-linux-gnu/pkgconfig/"
pkg-config --modversion gthread-2.0
  2.74.4

  Expected output
  $ pkg-config --modversion gthread-2.0
  2.74.4

  The problem is that pkg-config does not know anything about this directory
  since it is not present in its default search directories
  $ pkg-config --variable pc_path pkg-config
  /usr/local/lib/i386-linux-gnu/pkgconfig:/usr/local/lib/pkgconfig:/usr/local/share/pkgconfig:/usr/lib/i386-linux-gnu/pkgconfig:/usr/lib/pkgconfig:/usr/share/pkgconfig

  I am using Debian GNU/Linux 6.0.12-1 (2022-12-09), kernel 6.0.0-6-amd64
  and libc6 2.36-7.

Att,
Allan Krama Guimarães

I am also having this problem I just wanted to add that on my machine if I
use:

$ pkg-config --dump-personality
Triplet: default
DefaultSearchPaths: /usr/lib/pkgconfig /usr/share/pkgconfig
SystemIncludePaths: /usr/include
SystemLibraryPaths: /lib /lib/i386-linux-gnu /lib/x86_64-linux-gnu
/lib/x86_64-linux-gnux32 /lib64 /libx32 /usr/lib /usr/lib/i386-linux-gnu
/usr/lib/x86_64-linux-gnu /usr/lib/x86_64-linux-gnux32 /usr/lib64
/usr/libx32

As you can see, Triplet is "default" and there are only two dirs in
DefaultSearchPath. There is a file installed on my machine at
/usr/share/pkgconfig/personality.d/x86_64-linux-gnu.personality. The
contents of this file are as follows:

$cat /usr/share/pkgconfig/personality.d/x86_64-linux-gnu.personality

Triplet: x86_64-linux-gnu
DefaultSearchPaths:
/usr/local/lib/x86_64-linux-gnu/pkgconfig:/usr/local/lib/pkgconfig:/usr/local/share/pkgconfig:/usr/lib/x86_64-linux-gnu/pkgconfig:/usr/lib/pkgconfig:/usr/share/pkgconfig
SystemIncludePaths: /usr/include
SystemLibraryPaths:
/lib:/lib/i386-linux-gnu:/lib/x86_64-linux-gnu:/lib/x86_64-linux-gnux32:/lib32:/libx32:/usr/lib:/usr/lib/i386-linux-gnu:/usr/lib/x86_64-linux-gnu:/usr/lib/x86_64-linux-gnux32:/usr/lib32:/usr/libx32

Note that all the expected information is present. So it seems I have the
correct file on my machine but pkg-config isn't "seeing" it for some
reason.

Pkg-config is version 1.8.1-1 and my architecture is amd64.

You didn’t use reportbug to file this bug report, so I cannot verify it
from the list of dependencies, but it seems that you have
pkgconf-bin:i386 installed on your system instead of pkgconf-bin:amd64.
This is what causes pkgconf or pkg-config to default to the i386 flags.

A better workaround would be to call pkg-config or pkgconf but
annotating the command with the architecture name, in your case
x86_64-linux-gnu-pkg-config or x86_64-linux-gnu-pkgconf.

I ran into this same issue today, and would like to confirm the bug:

1) The workaround suggested by Andrej is not functional, because x86_64-linux-gnu-pkgconf (or pkg-config) is really just a symlink to whatever pkgconf binaries are installed on the system.

2) The binary architecture of the pkgconf application itself has no relation whatsoever to the binary architecture of libraries available on the system, and therefore the search path for packet configuration files (.pc) should never make assumptions about the architecture of the library on a multiarch system

Expected behavior
-----------------
Regardless of whether pkgconf is installed in i386 or amd64 (or whatever architecture, really), it should include in the default search paths for libraries ALL architectures that are in use on the system.
(Or, if that leads to packet configuration file conflicts: Provide a command line option --64 / --32 to select one set of search paths. Keep in mind that these are not include paths themselves, just paths to search for .pc files - so I believe the "search in all" solution should be conflict-free)

Actual behavior
---------------
When pkgconf-bin:i386 is installed:
$ pkgconf  --variable pc_path pkgconf
/usr/local/lib/i386-linux-gnu/pkgconfig:/usr/local/lib/pkgconfig:/usr/local/share/pkgconfig:/usr/lib/i386-linux-gnu/pkgconfig:/usr/lib/pkgconfig:/usr/share/pkgconfig

When pkgconf-bin:amd64 is installed:
$ pkgconf  --variable pc_path pkgconf
/usr/local/lib/x86_64-linux-gnu/pkgconfig:/usr/local/lib/pkgconfig:/usr/local/share/pkgconfig:/usr/lib/x86_64-linux-gnu/pkgconfig:/usr/lib/pkgconfig:/usr/share/pkgconfig


Note: Switching between the two versions works on both debian testing (trixie) and stable (bookworm) via
$ aptitude purge pkgconf-bin:i386
and
$ aptitude purge pkgconf-bin:amd64
, accepting the aptitude proposed solution that replaces *only* libpgkconf3 and pkgconf-bin with the respective other architecture.

A fix would be very much appreciated!

    /Lars

Hello,

So, if you run x86_64-linux-gnu-pkgconf, what do you get?

$ ls -l /usr/bin/x86_64-linux-gnu-pkgconf
lrwxrwxrwx 1 root root 7 Oct 20 20:10 /usr/bin/x86_64-linux-gnu-pkgconf -> pkgconf

So I get the same output as binary with the respective currently installed architecture would generate.

I.e. if i386 is installed:
/usr/local/lib/i386-linux-gnu/pkgconfig:/usr/local/lib/pkgconfig:/usr/local/share/pkgconfig:/usr/lib/i386-linux-gnu/pkgconfig:/usr/lib/pkgconfig:/usr/share/pkgconfig

and if amd64 is installed:
/usr/local/lib/x86_64-linux-gnu/pkgconfig:/usr/local/lib/pkgconfig:/usr/local/share/pkgconfig:/usr/lib/x86_64-linux-gnu/pkgconfig:/usr/lib/pkgconfig:/usr/share/pkgconfig

Hello,

It's not *just* a symlink. Pkgconf behaves differently depending on what name it's called as. Have you actually tried it?

Damn, now I forgot editing my sender email and exposed my for-private-use email. Is there a chance to delete the previous one and let me re-send it?

Yes, yes I had - and just did it again:

$ x86_64-linux-gnu-pkgconf  --variable pc_path pkgconf
/usr/local/lib/i386-linux-gnu/pkgconfig:/usr/local/lib/pkgconfig:/usr/local/share/pkgconfig:/usr/lib/i386-linux-gnu/pkgconfig:/usr/lib/pkgconfig:/usr/share/pkgconfig

What I apparently did not see before though, was that
$ x86_64-linux-gnu-pkgconf --cflags jsoncpp
-I/usr/include/jsoncpp

I suspect that was because by the time I learned about x86_64-linux-gnu-pkgconf, I was already to the point in my troubleshooting of directly checking the --variable pc_path option.

So I'd still consider it a bug in that
1) my original point stands: there's no reason for pkgconf (even without a symlink call) to assume any specific architecture for libraries on multiarch systems, especially not based on the binary architecture of pkgconf itself
2) the config output of --variable pc_path should also respect that "what name it's called as"

And I stand by my "it would be appreciated if this can be fixed" :)

Kind regards
    Lars

Hi,

I don't think so, but in any case it wasn't that difficult to guess it, was it? :)