in the proposed u-config PKG_CONFIG_SYSROOT_DIR support PR, the u-config maintainer goes out of his way to mansplain pkgconf's behavior here, which is *not* strictly about -I and -L flags as he envisions.
-
@ariadne Yeah. I understand the urge to fight the bloat of modern software by going far in the other direction, to the point of having a version that makes Linux syscalls directly and requires no libc; that's an impressive stunt. But it probably isn't good for the maintainability of the tool.
@matt i mean, normally i would be like "oh, someone else has *voluntarily* pinned the pkg-config kick me sign to his back, i'm free!"
but his entire blog where he introduces u-config is just unpleasant to read, and i am horrified of the vision he has for the ecosystem (namely to deprecate it, in favor of nothing).
-
@matt i mean, normally i would be like "oh, someone else has *voluntarily* pinned the pkg-config kick me sign to his back, i'm free!"
but his entire blog where he introduces u-config is just unpleasant to read, and i am horrified of the vision he has for the ecosystem (namely to deprecate it, in favor of nothing).
@ariadne Yeah, I was wondering earlier what he wanted to replace pkg-config with. I assume he wants to replace it with every program vendoring its library dependencies, as seems to be common in indie C++ game dev, ideally using small libraries.
-
@ariadne Yeah, I was wondering earlier what he wanted to replace pkg-config with. I assume he wants to replace it with every program vendoring its library dependencies, as seems to be common in indie C++ game dev, ideally using small libraries.
@matt i don't know, most likely
-
in the proposed u-config PKG_CONFIG_SYSROOT_DIR support PR, the u-config maintainer goes out of his way to mansplain pkgconf's behavior here, which is *not* strictly about -I and -L flags as he envisions. since it is not strictly about -I and -L he calls it "broken".
and, if that were the case, sysroot would be a lot easier.
the whole problem is that ${pc_sysrootdir} was added quietly much later, and so most .pc files have no awareness of ${pc_sysrootdir}.
the original idea was that you would have `prefix=${pc_sysrootdir}%PREFIX%` in your foo.pc.in file, but basically nobody does this. because they copy other .pc files usually.
meanwhile we need to support sysroot.
so pkgconf classic (< 2.0) just automatically mutated -I and -L paths (and some others) as expected when ${pc_sysrootdir} is not used.
but clever workarounds result in new ways to break the system.
remember how i said the intended way to use ${pc_sysrootdir} was to augment ${prefix} with it and make all other paths relative to ${prefix}? (this also makes --define-prefix work meaningfully on windows) well... some pc files do not do that, and instead do things like
```
prefix=/usr
includedir=${pc_sysrootdir}/${prefix}/include
```we used to have a complicated set of heuristics to detect this specific type of mistake. in pkgconf 3 we have moved to bytecode-based string substitution, and have given ${pc_sysrootdir} its own special opcode. this allows us to just look and see if the ${pc_sysrootdir} opcode has ever been encountered. we can then selectively apply mitigations.
anyway. back to the -I and -L thing. it sure would be nice if that was the case, but it isn't. sometimes (gstreamer comes to mind) you need to install new things into the sysroot because there are headers that need to be installed in a special place relative to the sysroot.
what does this mean? it means that --variable also has to be supported. and at that point, you may as well just support it everywhere.
i would again like to stop hearing about this completely broken pkg-config implementation.
projects like meson should mark it as broken instead of wasting their time negotiating with a techbro.
@ariadne tangential, do you have a recommended resource for a pkgconf deep dive, warts and everything?
-
@ariadne tangential, do you have a recommended resource for a pkgconf deep dive, warts and everything?
@dngrs I gave a talk about it last year at seagl
-
in the proposed u-config PKG_CONFIG_SYSROOT_DIR support PR, the u-config maintainer goes out of his way to mansplain pkgconf's behavior here, which is *not* strictly about -I and -L flags as he envisions. since it is not strictly about -I and -L he calls it "broken".
and, if that were the case, sysroot would be a lot easier.
the whole problem is that ${pc_sysrootdir} was added quietly much later, and so most .pc files have no awareness of ${pc_sysrootdir}.
the original idea was that you would have `prefix=${pc_sysrootdir}%PREFIX%` in your foo.pc.in file, but basically nobody does this. because they copy other .pc files usually.
meanwhile we need to support sysroot.
so pkgconf classic (< 2.0) just automatically mutated -I and -L paths (and some others) as expected when ${pc_sysrootdir} is not used.
but clever workarounds result in new ways to break the system.
remember how i said the intended way to use ${pc_sysrootdir} was to augment ${prefix} with it and make all other paths relative to ${prefix}? (this also makes --define-prefix work meaningfully on windows) well... some pc files do not do that, and instead do things like
```
prefix=/usr
includedir=${pc_sysrootdir}/${prefix}/include
```we used to have a complicated set of heuristics to detect this specific type of mistake. in pkgconf 3 we have moved to bytecode-based string substitution, and have given ${pc_sysrootdir} its own special opcode. this allows us to just look and see if the ${pc_sysrootdir} opcode has ever been encountered. we can then selectively apply mitigations.
anyway. back to the -I and -L thing. it sure would be nice if that was the case, but it isn't. sometimes (gstreamer comes to mind) you need to install new things into the sysroot because there are headers that need to be installed in a special place relative to the sysroot.
what does this mean? it means that --variable also has to be supported. and at that point, you may as well just support it everywhere.
i would again like to stop hearing about this completely broken pkg-config implementation.
projects like meson should mark it as broken instead of wasting their time negotiating with a techbro.
@ariadne is there a guide how to do all of this correctly? Asking for a friend… who may have done some cargo cult .pc files...
-
@ariadne is there a guide how to do all of this correctly? Asking for a friend… who may have done some cargo cult .pc files...
@equinox pc(5) has good examples
-
@equinox pc(5) has good examples
@ariadne no pc_sysrootdir though?
-
@ariadne no pc_sysrootdir though?
@equinox at this point I would say don't worry about it. pkgconf will inject it as appropriate.
-
@equinox at this point I would say don't worry about it. pkgconf will inject it as appropriate.
@ariadne mhm. There is a bit of a lack of good manual type docs on .pc... I had trouble explaining the point of -uninstalled.pc to project colleagues as well
… the language and everything is perfectly clear, but not the expected conventions.As an extreme example: is using ${prefix} a MUST, SHOULD, MAY, SHOULD NOT, or MUST NOT? Do things break if you fold it into other vars? (ok clearly not either of the MUSTs, but you get the point)
-
that blog, incidentally, continues to piss me off.
shitting on others to elevate yourself is a classical trait of narcissistic behavior and all it does is hurt the people you are shitting on.
i'm so sorry that when i originally wrote pkgconf i was not even a professional software engineer or had ever even heard of hacker news for that matter. instead, it was a hobby thing: i wanted to make the operating system i use better.
so when i saw strlcpy and strlcat used in a bunch of other FOSS projects, I said "well everyone else is using this, it's probably good enough!"
and, no, it's not good enough. but the version of me that knows that has had 15 years of experience working in tech, and the version of me that decided to use strlcpy was being shot at every day because i had to take methheads' kids away for a living.
Ok, I have not followed the strlcat/strlcpy issues so now I am curious why they are bad to use?
I thought they were the better version of strncpy/strncat?
I know some of these functions will not put a null terminating character on the end if it reaches the size but I always forget which ones even. I try to stay away from string functions in general :). -
Ok, I have not followed the strlcat/strlcpy issues so now I am curious why they are bad to use?
I thought they were the better version of strncpy/strncat?
I know some of these functions will not put a null terminating character on the end if it reaches the size but I always forget which ones even. I try to stay away from string functions in general :).@pinskia silent truncation
-
@pinskia silent truncation
Oh ok that makes sense of why it is an issue.
-
some idiot wanting to turn pc files into an ISO standard because of fucking u-config, i wish this project would just utterly fuck off
@ariadne I started my career at France Telecom R&D, and the guy who was designated to attend standards meetings was the dumbest dullard in the entire division.
-
R relay@relay.infosec.exchange shared this topic
