The libgdiplus slackbuild is broken if $LIBS shell variable is set. The quick fix should be turned into a full fix.
https://www.linuxquestions.org/quest...ls-4175529346/

is that ($LIBS) a standard env variable?

it depends what you mean by "standard". I don't know how often if it used in Makefiles, but it's not listed among the "variables that are frequently exported by widely used command interpreters and applications" according to the Environment Variables chapter in the current the POSIX specification.

How is that relevant to the issue at hand ? It is picked up by the configure file, and if you use sed later it messes things up. Using sed here is not the right fix, it's a quick fix.

sorry metaschima, but 55020 already gave you the answer in the other thread: I think too the sed is the correct fix there.

if you export in your ~/.bashrc a custom LIBS variable trying to fix some underlinking situations you have to deal with it later: IMHO you should patch the scripts that cause underlinking errors instead and not exporting a custom LIBS variable that will make a lot of libraries/application link to unneded stuff.

of course there is. :banghead:
or is it totally ok and accepted by SBo that a buildscript does something it should not do, like creating dirs and writing stuff in you root directory?
a failure like this should not exist, it is juts an other prove that the 'it is ok to do it as root' approach as currently propagated is broken.

Except that a lot of programs won't build unless they have '-lm -ldl'. Originally, I exported this manually for every program, but having gotten sick of that I exported the LIBS variable. I don't see anything particularly wrong with that. Why is 'sed' the correct fix again ? It clearly fails if LIBS is set. It cannot be the correct solution if it fails in set cases.

That type of error should be stated when the bug report is filed (it wasn't mentioned when rg3 posted in this thread), and that type of error isn't something you need fakeroot to determine, so the fact that fakeroot builds aren't supported has nothing to do with the bug. The bug can be found by running the script as a regular user rather than root. When that issue is brought forward, I doubt the SBo maintainers would ignore it.

If you can produce errors in a non-standard environment (in this case, using fakeroot), try to produce the errors in a standard environment to see if it is a fakeroot problem, or a script/program problem. It's the same reason it is difficult to diagnose Salix from a Slackware perspective. It could very well be an issue with a Slackware package, but it could also be a dependency problem or a problem with Salix itself. They can't be expected to support everything, so the SBo maintainers have determined that they aren't supporting alternative build options like fakeroot. Try your problem again and see if it can be reproduced without using fakeroot (ie, try building as a normal user), then if the problem is still there, let them know.

I don't blame them for ignoring the error if someone states they use fakeroot. We did the same thing on the CyanogenMod forum when people posted about CM issues when they were using 3rd party kernels. They needed to replicate the issue with the stock kernel before CM devs would even bother to look at it, otherwise they could be taking valuable time to find a fix for something that was created by a kernel they have no control over (and that they can't fix with their software since it needs to be fixed by the kernel dev).

a build script that creates anything outside it's allowd directories in tmp is buggy, there is no discussion.

using fakeroot is not a feature, if your build scrips has no bugs it just works, selling it as a feature is ridiculous.

using it can help avoid such bugs, you can use also one of the other methods we have recently discussed, chroot env, and even work as root to avoid such bugs.

doing nothing and ignore that such bugs exist is not good.
declaring fakeroot as a feature is absurd

as long as such bugs exist SBo quality control is buggy, as long as they do not use fakeroot or one of the other methodes they will stay buggy because nobody, not even they guys at SBo, is perfect, is was proven more than once.

what you are reporting is not what has been by rg3 and I'll take care of fixing it.

I think the contrary has never been stated.

As stated a couple of times before - SBo follows the way of working of Slackware itself if it comes to package building.
No amount of lobbying for fakeroot will change that.
If a SlackBuild submitter wants to QA-test his script using fakeroot, then that is OK of course. But the SBo submissions are what they are and fakeroot support is not added in as a feature.

@a4z, if there is a problem with the build script operating outside of the package/build directories, then that should be brought up, but fakeroot doesn't NEED to be a part of that discussion. "I found that the lua build script is attempting to use /usr/lib64/lua instead of $PKG/usr/lib64/lua" Simple, concise, and pertinent. There's no need to mention that you use fakeroot, that you have all the dependencies required, or that your dog recently turned 7. fakeroot can certainly be used as a tool to find issues with build scripts, but it doesn't need to be mentioned when filing the bug report.

@ponce, yes, I realize that slackbuilds aren't designed to be built as users (since the chown would fail), but if it fails due to trying to create or modify a directory inside the regular filesystem instead of in the package directory, it seems you'd be more than willing to get that issue fixed in the scripts (correct me if I'm wrong -- but it seems to be the recommended test to make sure running as root won't wreak havoc on your system (FAQ #11)). If that isn't fixed, it could cause issues if a user wants to use one machine (or virtual machine) as a build box and then try and transfer that resulting package to another machine (which I do a lot, since I have one machine that is substantially faster than my others).

rtorrent/libtorrent doesn't need libsigc++ anymore. already mailed maintainer.

something as a fakeroot support does not exist, is this so hard to understand?
arguing with a 'fakeroot support' or a 'fakeroot feature' is therefore absurd.
arguing for bug free build scripts not.

you can call arguing for more QA as lobbying, but I do see nothing bad in this (especially because it is proven that bugs exist)

Don't worry, it didn't sound rude. :)

Now, specifically, I made a quick comment in this thread because I wasn't sure the mail had arrived or been read. In doing so, I omitted most of the details, but in the mail I sent I did explain the installation phase was writing outside the temporary directories, and I saw that because I use fakeroot. I build packages as a separate non-root user in my system because that's my personal policy. I think it's acceptable to require root, though.