pkg-config --static not working #310

New Issue

claunia · 2026-01-29T20:41:44Z

claunia commented

2026-01-29 20:41:44 +00:00

Originally created by @jay on GitHub (Feb 14, 2020).

The static libraries have the name -static appended to them but pkg-config --static returns the regular name. I don't think there is a way to treat the library name as different for static in pkg-config.

libbrotlicommon-static.a
libbrotlidec-static.a
libbrotlienc-static.a

git clone https://github.com/google/brotli.git
mkdir brotli-build
cd brotli-build/
cmake -DBUILD_{SHARED,STATIC}_LIBS=ON ../brotli
make
sudo make install

cat << EOF > a.c
 #ifdef __cplusplus
 extern "C"
 #endif
 char BrotliDecoderDecompress ();
 int main (void)
 {
 return BrotliDecoderDecompress ();
  ;
  return 0;
 }
EOF

$ gcc -o a a.c -static `pkg-config --static --libs libbrotlidec`
/usr/bin/ld: cannot find -lbrotlidec
/usr/bin/ld: cannot find -lbrotlicommon
collect2: error: ld returned 1 exit status
$ pkg-config --static --libs libbrotlidec
-L/usr/local/lib -lbrotlidec -lbrotlicommon
$ gcc -o a a.c -static -L/usr/local/lib -lbrotlidec-static -lbrotlicommon-static
$

Originally created by @jay on GitHub (Feb 14, 2020). The static libraries have the name -static appended to them but pkg-config --static returns the regular name. I don't think there is a way to treat the library name as different for static in pkg-config. libbrotlicommon-static.a libbrotlidec-static.a libbrotlienc-static.a ~~~ git clone https://github.com/google/brotli.git mkdir brotli-build cd brotli-build/ cmake -DBUILD_{SHARED,STATIC}_LIBS=ON ../brotli make sudo make install ~~~ ~~~ cat << EOF > a.c #ifdef __cplusplus extern "C" #endif char BrotliDecoderDecompress (); int main (void) { return BrotliDecoderDecompress (); ; return 0; } EOF ~~~ ~~~ $ gcc -o a a.c -static `pkg-config --static --libs libbrotlidec` /usr/bin/ld: cannot find -lbrotlidec /usr/bin/ld: cannot find -lbrotlicommon collect2: error: ld returned 1 exit status $ pkg-config --static --libs libbrotlidec -L/usr/local/lib -lbrotlidec -lbrotlicommon $ gcc -o a a.c -static -L/usr/local/lib -lbrotlidec-static -lbrotlicommon-static $ ~~~

claunia commented

2026-01-29 20:41:45 +00:00

@emerzon commented on GitHub (Mar 1, 2020):

I have same issue. Quick and Dirty workaround was to symlink libs to their names without the "-static" suffix.

@emerzon commented on GitHub (Mar 1, 2020): I have same issue. Quick and Dirty workaround was to symlink libs to their names without the "-static" suffix.

claunia commented

2026-01-29 20:41:45 +00:00

@jay commented on GitHub (Mar 3, 2020):

I did something similar

for m in mingw32 mingw64; do
  for f in libbrotlidec libbrotlienc libbrotlicommon; do
    cp "C:/msys64/$m/lib/$f-static.a" "C:/msys64/$m/lib/$f.a"
  done
done

@jay commented on GitHub (Mar 3, 2020): I did something similar ~~~ for m in mingw32 mingw64; do for f in libbrotlidec libbrotlienc libbrotlicommon; do cp "C:/msys64/$m/lib/$f-static.a" "C:/msys64/$m/lib/$f.a" done done ~~~

claunia commented

2026-01-29 20:41:45 +00:00

@wader commented on GitHub (Jun 17, 2020):

Hello! i was bitten by this and wondering if i could help resolve it somehow.

@eustas i'm curious when you were working on https://github.com/google/brotli/pull/599 was there reason the static library ended up having a -static suffix?

@wader commented on GitHub (Jun 17, 2020): Hello! i was bitten by this and wondering if i could help resolve it somehow. @eustas i'm curious when you were working on https://github.com/google/brotli/pull/599 was there reason the static library ended up having a -static suffix?

claunia commented

2026-01-29 20:41:46 +00:00

@ILW000 commented on GitHub (Apr 21, 2021):

I did workaround similar in the opposite way. I edited files libbrotl*.pc to provide static only compilation (replaced -lbrotl* to -lbrotl*-static inside all libbrotl*.pc files). It's Dirty workaround method of course.

@ILW000 commented on GitHub (Apr 21, 2021): I did workaround similar in the opposite way. I edited files `libbrotl*.pc` to provide static only compilation (replaced `-lbrotl*` to `-lbrotl*-static` inside all `libbrotl*.pc` files). It's Dirty workaround method of course.

claunia commented

2026-01-29 20:41:46 +00:00

@eustas commented on GitHub (Jan 6, 2023):

Should work now. Feel free to reopen if it doesn't.

@eustas commented on GitHub (Jan 6, 2023): Should work now. Feel free to reopen if it doesn't.

claunia commented

2026-01-29 20:41:46 +00:00

@nh2 commented on GitHub (Jul 13, 2023):

Should work now. Feel free to reopen if it doesn't.

@eustas What was changed?

@nh2 commented on GitHub (Jul 13, 2023): > Should work now. Feel free to reopen if it doesn't. @eustas What was changed?

claunia commented

2026-01-29 20:41:46 +00:00

@eustas commented on GitHub (Jul 14, 2023):

#599

@eustas commented on GitHub (Jul 14, 2023): #599

claunia commented

2026-01-29 20:41:47 +00:00

@nh2 commented on GitHub (Jul 14, 2023):

@eustas How can/does it fix this issue though?

PR #599 was merged in 2017; this issue was filed in 2020.

Aren't the generated files still suffixed -static.a, but the .pc file does not mention this suffix, as the issue description here describes?

@nh2 commented on GitHub (Jul 14, 2023): @eustas How can/does it fix this issue though? PR #599 was merged in 2017; this issue was filed in 2020. Aren't the generated files still suffixed `-static.a`, but the `.pc` file does not mention this suffix, as the issue description here describes?

claunia commented

2026-01-29 20:41:48 +00:00

@eustas commented on GitHub (Jul 14, 2023):

Indeed, did not read through the thread carefully.

@eustas commented on GitHub (Jul 14, 2023): Indeed, did not read through the thread carefully.

claunia commented

2026-01-29 20:41:48 +00:00

@nh2 commented on GitHub (Jul 14, 2023):

@eustas If there is no drawback for your use case from it, I propose to just name the files

libbrotlidec.a
libbrotlienc.a
libbrotlicommon.a

without any suffix. This way, systems such as pkg-config and GCC will pick them up correctly automatically.

Given that .a files are always static, the -static suffix in the file name is semantically not necessary.

@nh2 commented on GitHub (Jul 14, 2023): @eustas If there is no drawback for your use case from it, I propose to just name the files ``` libbrotlidec.a libbrotlienc.a libbrotlicommon.a ``` without any suffix. This way, systems such as `pkg-config` and GCC will pick them up correctly automatically. Given that `.a` files are always static, the `-static` suffix in the file name is semantically not necessary.

claunia commented

2026-01-29 20:41:48 +00:00

@eustas commented on GitHub (Jul 14, 2023):

There are #601 and #655; I was under impression that the later dealt with -static suffix... Going to re-check on Monday.

@eustas commented on GitHub (Jul 14, 2023): There are #601 and #655; I was under impression that the later dealt with `-static` suffix... Going to re-check on Monday.

claunia commented

2026-01-29 20:41:49 +00:00

@eustas commented on GitHub (Jul 14, 2023):

Yes, CMake now builds without suffix... but shared and static builds have to be done in separate runs...

@eustas commented on GitHub (Jul 14, 2023): Yes, CMake now builds without suffix... but shared and static builds have to be done in separate runs...

claunia commented

2026-01-29 20:41:49 +00:00

@eustas commented on GitHub (Jul 14, 2023):

Likely that is ok, since CMake is not a solution responsible for making packages...

@eustas commented on GitHub (Jul 14, 2023): Likely that is ok, since CMake is not a solution responsible for making packages...

claunia commented

2026-01-29 20:41:49 +00:00

@nh2 commented on GitHub (Jul 14, 2023):

but shared and static builds have to be done in separate runs...

CMake now does have a feature to build .a and .so from the same .o files so that you don't have to compile twice:

https://stackoverflow.com/questions/2152077/is-it-possible-to-get-cmake-to-build-both-a-static-and-shared-library-at-the-sam/29824424#29824424

The drawback, as described there:

The price you pay is that the object files must be built as position-independent [-fPIC] code because shared libraries need this (static libs don't care). Note that position-independent code may be less efficient, so if you aim for maximal performance then you'd go for static libraries [without position-independent code].

From a distro packager's perspective, it is usually fine if the CMake builds .o files multiple times, as long as I can conveniently end up with both .a and .so and control them independently e.g. using CMake variables.

@nh2 commented on GitHub (Jul 14, 2023): > but shared and static builds have to be done in separate runs... CMake now does have a feature to build `.a` and `.so` from the same `.o` files so that you don't have to compile twice: https://stackoverflow.com/questions/2152077/is-it-possible-to-get-cmake-to-build-both-a-static-and-shared-library-at-the-sam/29824424#29824424 The drawback, as described there: > The price you pay is that the object files must be built as position-independent [`-fPIC`] code because shared libraries need this (static libs don't care). Note that position-independent code may be less efficient, so if you aim for maximal performance then you'd go for static libraries [without position-independent code]. From a distro packager's perspective, it is usually fine if the CMake builds `.o` files multiple times, as long as I can conveniently end up with both `.a` and `.so` and control them independently e.g. using CMake variables.

claunia commented

2026-01-29 20:41:50 +00:00

@eustas commented on GitHub (Jul 14, 2023):

Yup, we've moved to object libraries in fresher projects, perhaps it is time to modernize brotli as well. PIC is fine, it is better for security... There are other problems in CMake object libraries, we already know how to deal with them =)

@eustas commented on GitHub (Jul 14, 2023): Yup, we've moved to object libraries in fresher projects, perhaps it is time to modernize brotli as well. PIC is fine, it is better for security... There are other problems in CMake object libraries, we already know how to deal with them =)

claunia commented

2026-01-29 20:41:51 +00:00

@arp242 commented on GitHub (Jun 6, 2024):

I don't know anything that works like brotli does now by allowing only building one or the other; having both static and dynamic libraries built is the desirable situation on pretty much any Linux package system. I don't see what #655 fixed, it only broke things.

Package systems don't have a way to say "use cmake, but run it twice, with different options", so need to kludge around all of this. The old situation with -static suffix wasn't ideal, but could be worked around with a bit of sed.

Right now I can't recompile anything that depends on brotli unless I also manually compile brotli instead of using the distro package. There isn't any (reasonable) way distro packages can ship the .a files at all. All of this is a huge hassle especially if you're compiling to a different target (I now need to set up an entire build environment for that, instead of being able to rely on packages).

(I'd send a patch if I could understand any of this cmake magic...)

@arp242 commented on GitHub (Jun 6, 2024): I don't know anything that works like brotli does now by allowing only building one or the other; having both static and dynamic libraries built is the desirable situation on pretty much any Linux package system. I don't see what #655 fixed, it only broke things. Package systems don't have a way to say "use cmake, but run it twice, with different options", so need to kludge around all of this. The old situation with -static suffix wasn't ideal, but could be worked around with a bit of sed. Right now I can't recompile anything that depends on brotli unless I also manually compile brotli instead of using the distro package. There isn't any (reasonable) way distro packages can ship the .a files at all. All of this is a huge hassle especially if you're compiling to a different target (I now need to set up an entire build environment for that, instead of being able to rely on packages). (I'd send a patch if I could understand any of this cmake magic...)

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: starred/brotli#310