The Place to Start for Operating System Developers
https://f.osdev.org/
I think you somehow need to retain the "root" or administrator account to grant permission to other users (or apps).Combuster wrote:Removing root is certainly a fix for a lot of things.
The user root
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.bluemoon wrote:I think you somehow need to retain the "root" or administrator account to grant permission to other users (or apps).Combuster wrote:Removing root is certainly a fix for a lot of things.
The user root
However I do agree the system should block root user for all other activities, including executing program.
Code: Select all
echo "Sudo sandwich is icky, but MonoDevelop must run in user mode."
sudo -p "[sudo] password to setup /usr/bin/gcc: " $0 setup
monodevelop
sudo -p "[sudo] password to reset /usr/bin/gcc: " $0 resetNo, 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).iansjack wrote: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.
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.Brynet-Inc wrote: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.
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....Brynet-Inc wrote: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.
Humorously enough, you hit the nail on the head. C/C++ in MonoDevelop doesn't work on Windows.iansjack wrote: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.
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.iansjack wrote: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.
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?SoulofDeity wrote:I assure you, it's hardcoded.
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.iansjack wrote: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?SoulofDeity wrote:I assure you, it's hardcoded.
Wow. You really are going out of your way to prove I'm stupid or something.iansjack wrote:I can only think that your cross-compiler isn't properly built or installed.
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.SoulofDeity wrote:Just because it builds doesn't mean it's using the right compiler.
I'm going out of my way to try to find an explanation for your experience. I can't think of another one.SoulofDeity wrote:Wow. You really are going out of your way to prove I'm stupid or something.
So, you did the exact same thing that I did. There was no simple 'change the PATH' variable fix.iansjack wrote: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.SoulofDeity wrote:Just because it builds doesn't mean it's using the right compiler.
No.SoulofDeity wrote:So, you did the exact same thing that I did. There was no simple 'change the PATH' variable fix.iansjack wrote: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.SoulofDeity wrote:Just because it builds doesn't mean it's using the right compiler.