OSDev.org

I think you somehow need to retain the "root" or administrator account to grant permission to other users (or apps).
However I do agree the system should block root user for all other activities, including executing program.

As long as at least 1 person on the machine has the same privileges as the traditional root user, I agree that there doesn't need to be one. Perhaps adding a new 'admin' group. One thing that is really annoying is when I accidentally run a program as root and it creates a bunch of files with root ownership. It's a pain in the @$$ to take ownership back one-by-one.

There's also been quite a few times that I've had to run gparted to format an sd card or usb stick, and because gparted requires root privileges to run, it [root] takes ownership of the entire device.


EDIT:
When I say "accidentally run as root", I don't mean like, "ohshit, I typed 'sudo' and my password by accident!", the problem I'm talking about can best be explained by the 'sudo sandwich in my "barebones in monodevelop" topic.
You need root to modify /usr, but you can't run the entire script as root because then monodevelop gives ownership of your projects to root.

Any operating system is going to present problems if you torture it in this way. Your script - well, certainly the sudo parts - are totally unnecessary. Why not do the sensible thing and put a link to the cross-compiler in a directory other than /usr/bin (/~/bin would be a possible choice) then add that directory to your PATH in front of /usr/bin? No need to abuse the system by changing things in /usr/bin every time that you run the command. And you don't have to compromise your system by allowing sudo access to people who don't need it.

This is a great example of why you need to understand the filesystem, and use it, rather than fighting against it. KISS.

No, they're not unnecessary if you know what's happening. MonoDevelop requires that /usr/bin/gcc be a either the executable or a link to gcc; no if's ands or buts. If I simply replace /usr/bin/gcc, then the link will be overwritten when GCC is upgraded. The only choice is to temporarily redirect the link to the custom i686-elf-gcc until MonoDevelop is closed, or make a patch for MonoDevelop to make the compiler selectable (which I know I'll personally have to keep updated because third-party fixes like this never make it into the master branch).

If your IDE doesn't honour the CC environment variable, you may want to shift your blame. A user should not typically be messing with the installed system compiler or overriding package managers.

Well, MonoDevelop was made specifically for use with C# and the Mono runtime. The C/C++ was sort of tacked on sloppily by the developers. That said, while it is the fault of the MonoDevelop creators, there have been a few other times when I'd need to run a command as a user between two or more other commands needing to be run as root.

Surely, iansjack is right that there are better approaches than making a sudo sandwich. I had could have ran one part of the script as root and the other as a normal user; then use a lock for the 2 processes to determine when to stop and continue certain steps. Having to go that extra mile though to do something relatively simple is kind of agitating.

Exactly. I find it pretty difficult to believe that any programmer could be so dumb as to hard code an absolute path to the compiler (and I'm not sure that I would trust such a program on my computer). I'm not familiar with monodevelop though from all I read it honours the PATH variable. If not, I'd hate to think what happens on Windows where you can't even guarantee which drive the C compiler is located on, let alone its directory. Of course, in the end, it's open source, so....

You really can't blame the OS for a badly written program. Any OS should provide protection for installed system files.

Humorously enough, you hit the nail on the head. C/C++ in MonoDevelop doesn't work on Windows.

Just for fun I had a look at monodevelop. I'm happy to report that the path to gcc is not hard-wired into it. As long as your cross-compiler is properly built and installed, you just need to add the path to it as the first entry in your PATH environment variable. This is as it should be.

Having said that, I do't think it would be my IDE of choice for C/C++ development.

Apparently, you didn't look hard enough. It only lets you choose from a list of built-in presets (of which there is only 1, /usr/bin/gcc). I've tried creating symlinks and launching monodevelop like: `PATH="/path/to/cross/bin:$PATH" monodevelop` and it doesn't work. I assure you, it's hardcoded. Making a sudo-sandwich was a last resort.

I don't know what you are doing wrong, but I assure you that it isn't. I tried it and it worked. How much harder can I look?

I can only think that your cross-compiler isn't properly built or installed.

Really. Have you tried passing "-dumpmachine" to the project's target options and seeing what the console spits out? Just because it builds doesn't mean it's using the right compiler.

EDIT:

Wow. You really are going out of your way to prove I'm stupid or something.

It had to use the cross-compiler; I moved the normal compiler files and, as an added precaution, renamed them to *.old so that they wouldn't influence things. And I was using a 32-bit cross-compiler on a 64-bit machine to produce 32-bit code.

I'm going out of my way to try to find an explanation for your experience. I can't think of another one.

Really, I'm not fussed one way or another. It works for me, but I won't be using Monodevelop in future.

So, you did the exact same thing that I did. There was no simple 'change the PATH' variable fix.

No.

I only moved and renamed the original compiler files to be absolutely sure that they weren't somehow being used. This was just to make the test valid. (If I hadn't done that you'd be saying that it was using the system compiler all along!) The cross-compiler files were used because I added their path to the head of the PATH environment variable (i.e. simple 'change the PATH' variable). Without making that change to the variable nothing would compile. Afterwards it did, producing the expected object files.

This is, as far as I am concerned, a normal way to use a cross-compiler - just make sure its binaries appears in PATH ahead of any other compilers. That's the way the Unix PATH works, and I can't think that any programmer would be crazy enough to override this by hard-coding the path to a binary into the executable file - it's easier not to.