Move atomic_ops libs into Requires.private

[fundawang]

Acturally, bdwgc it self may requires atomic_ops, but it does not require downstream packages (like guile) requires atomic_ops. So I would suggest that move @ATOMIC_OPS_LIBS@ into Requires.private, so that won't confuse downstream packages, especially when performing check.

https://people.freedesktop.org/~dbn/pkg-config-guide.html#faq

My library z uses libx internally, but does not expose libx data types in its public API. What do I put in my z.pc file?
Again, add the module to Requires.private if it supports pkg-config. In this case, the compiler flags will be emitted unnecessarily, but it ensures that the linker flags will be present when linking statically. If libx does not support pkg-config, add the necessary linker flags to Libs.private.

So I think, move atomic_ops is a more appropriate solution.

[ivmai]

Please rebase to fresh master and explain the difference from the previous PR I just merged.

[ivmai]

set ATOMIC_OPS_LIBS using value of ATOMIC_OPS_PC

[ivmai]

Also, update comment "ATOMIC_OPS_LIBS, PACKAGE_VERSION are defined above" below

[ivmai]

Define ATOMIC_OPS_LIBS based on ATOMIC_OPS_PC value.

[ivmai]

Also define ATOMIC_OPS_PC="" below (for internal "internal" case)

[fundawang]

I suddenly realized a problem. atomic_ops shipped atomic_ops.pc starting from 7.2. If bdwgc is built upon atomic_ops 7.1, then we should not put it in bdwgc.pc file, because there is no atomic_ops.pc at that time.

Maybe we should leave it into Libs.private for now, till the time of bdwgc relies on atomic_ops >= 7.2.

[ivmai]

Maybe we should leave it into Libs.private for now, till the time of bdwgc relies on atomic_ops >= 7.2.

Although, 7.1 or 7.2 is not hard-coded in bdwgc source. I agree that we could leave this change for the future - I will create the relevant issue and close this PR.