andrewwutw/build-djgpp

build-djgpp.sh requires sudo privileges to build and install in /usr/local/

volkertb opened this issue ยท 34 comments

Hi there,

First of all, awesome project. This script really saves people a lot of time. ๐Ÿ˜ƒ

The issue I'm reporting here is a minor one: by default, the script installs the cross-compiler and tools in /usr/local/djgpp/. However, on most systems, /usr/local/ is not writable for non-root users, so the script will have to be run with sudo privileges, unless an alternative DJGPP_PREFIX somewhere in the user's home folder is specified.

It might be helpful to clarify this in the README.md file.

Thanks and keep up the good work!

stsp commented

I also ran into this problem.
I think the compilation and installation
should be done by separate scripts,
with the second one being run with sudo.

I agree with @stsp. That would be in line with how most Unix/Linux makefiles work, with the compilation being done with "make" and the installation being done with "sudo make install" (or just "make install" when a non-privileged installation folder is specified).

stsp commented

There seem to be a very extensive build
script rework pending: #25.
@jwt27 could you please hint us if your
patch set addresses also this?

jwt27 commented

I hadn't really considered this to be an issue. There is already a check in place to test if you have write access to the installation directory:

build-djgpp/script/7.2.0

Lines 134 to 146 in 4180d92

# create target directory, check writable.
echo "Make prefix directory : $DJGPP_PREFIX"
mkdir -p $DJGPP_PREFIX
if ! [ -d $DJGPP_PREFIX ]; then
echo "Unable to create prefix directory"
exit 1
fi
if ! [ -w $DJGPP_PREFIX ]; then
echo "prefix directory is not writable."
exit 1
fi

https://github.com/jwt27/build-gcc/blob/a8b3e194289c4f29dc820a30c0b5a4bd52de30d9/script/download.sh#L127-L139

I suppose this check could be moved up earlier in the script, before the download phase. Splitting up into separate build/install scripts makes things more complicated, since building gcc requires binutils and the libc headers to be installed first.

stsp commented

libc headers to be installed first.

Ahh, indeed. :(
I wonder how can this be then solved properly.
fakechroot? Too complicated.
Maybe the build scripts should run sudo
themselves before doing the install things,
and the user will have to type the password
from time to time? Doh.

jwt27 commented

Maybe the build scripts should run sudo
themselves before doing the install things,
and the user will have to type the password
from time to time? Doh.

That's an option, albeit somewhat inconvenient. I'll look into it.

stsp commented

Thank you!
Please note that it will do so only if the
write perms are missing by default, so
at least no one from current users would
get sufficiently hurt by such change.

jwt27 commented

See branch sudo on my fork: https://github.com/jwt27/build-gcc/tree/sudo

I am unable to test this myself, being on mingw64 (where sudo doesn't even exist)

stsp commented

You are quick!
Trying now...

stsp commented

First problem: bash (at least on ubuntu)
doesn't seem to like DOSish line endings.
Had to do dos2unix on scripts before they
could be started.

stsp commented
If you wish to change anything, press CTRL-C now. Otherwise, press any other key to continue.
[sudo] password for stas: 
Download source files...
Download http://www.delorie.com/pub/djgpp/current/v2gnu/bnu2311s.zip ...

I wonder why it asked the password before even
starting the download. Does this make any sense?

jwt27 commented

First problem: bash (at least on ubuntu)
doesn't seem to like DOSish line endings.
Had to do dos2unix on scripts before they
could be started.

That's interesting.. I thought git converts line endings automatically? Will need to check my settings.

I wonder why it asked the password before even
starting the download. Does this make any sense?

That is to create the PREFIX directory. You're right, it doesn't make much sense to do that before downloading.

stsp commented

That is to create the PREFIX directory.

Maybe, but now I restarted the script, and
it did the same thing again! (asked the sudo
passwd beforehand). Presumably the PREFIX
dir was already created on the second start,
so there is some bug.

stsp commented
chmod a+x install-sh
chmod a+x missing
/home/stas/src/build-gcc/script/build-binutils.sh: line 9: ../configure: Permission denied

You forgot to chmod also configure.

stsp commented

I wonder how to give the user a confidence
that he isn't working as root most of the time.
Maybe after you ended the sudo operation,
you should print what was done under root,
and say that after a kepress the root privs
will be dropped. Or overkill?

jwt27 commented

Maybe, but now I restarted the script, and it did the same thing again!

That makes sense since it runs sudo mkdir -p ${PREFIX}. I'll have to add a check to see if PREFIX exists instead of relying on -p.

You forgot to chmod also configure.

Thanks, fixed. I don't notice these things on windows....

jwt27 commented

I wonder how to give the user a confidence
that he isn't working as root most of the time.
Maybe after you ended the sudo operation,
you should print what was done under root,
and say that after a kepress the root privs
will be dropped. Or overkill?

I'll have to think about this. You could run the script with set -x, so you can see which lines are being run with sudo. Of course, that doesn't prevent harmful commands from being executed in the first place.

stsp commented

Of course, that doesn't prevent harmful commands from being executed in the first place.

The main point is not to run downloading or
compilation under sudo, as this will create the
files in your home dir owned by root.

I think you left set -x somewhere already as I am getting

++ find /home/stas/src/build-gcc/build/djcross-gcc-8.2.0/gnu/gcc-8.20 -name configure.ac
+ for c in `find $gcc_dir -name 'configure.ac'`
++ dirname /home/stas/src/build-gcc/build/djcross-gcc-8.2.0/gnu/gcc-8.20/intl/configure.ac

traces from some script.

stsp commented
main::scan_file() called too early to check prototype at /home/stas/src/build-gcc/build/djcross-gcc-8.2.0/tmpinst/bin/aclocal line 644.
aclocal: couldn't open directory '/home/stas/src/build-gcc/build/djcross-gcc-8.2.0/tmpinst/share/aclocal': No such file or directory
Patch gcc/doc/gcc.texi
/home/stas/src/build-gcc/build/djcross-gcc-8.2.0
cp: cannot stat '/usr/local/cross/bin/stubify': No such file or directory
stsp commented
checking for shl_load... configure: error: Link tests are not allowed after GCC_NO_EXECUTABLES.

and build failed.
It would be good if you disable the parallel
build for now, otherwise its not clear where
was an error.

jwt27 commented

I think you left set -x somewhere already

That's unpack-gcc.sh from djcross, not mine. I don't know why it's enabled there.

main::scan_file() called too early ...

Whoa, where did this happen?

cp: cannot stat '/usr/local/cross/bin/stubify': No such file or directory

That's a bug. fixed.

It would be good if you disable the parallel build for now, otherwise its not clear where was an error.

Set MAKE_JOBS=1 before running the script.

stsp commented

Whoa, where did this happen?

Here:

patching file /home/stas/src/build-gcc/build/djcross-gcc-8.2.0/gnu/gcc-8.20/include/libiberty.h
Using Plan A...
Hunk #1 succeeded at 108.
done
main::scan_file() called too early to check prototype at /home/stas/src/build-gcc/build/djcross-gcc-8.2.0/tmpinst/bin/aclocal line 644.
aclocal: couldn't open directory '/home/stas/src/build-gcc/build/djcross-gcc-8.2.0/tmpinst/share/aclocal': No such file or directory
main::scan_file() called too early to check prototype at /home/stas/src/build-gcc/build/djcross-gcc-8.2.0/tmpinst/bin/aclocal line 644.
aclocal: couldn't open directory '/home/stas/src/build-gcc/build/djcross-gcc-8.2.0/tmpinst/share/aclocal': No such file or directory
main::scan_file() called too early to check prototype at /home/stas/src/build-gcc/build/djcross-gcc-8.2.0/tmpinst/bin/aclocal line 644.
aclocal: couldn't open directory '/home/stas/src/build-gcc/build/djcross-gcc-8.2.0/tmpinst/share/aclocal': No such file or directory
main::scan_file() called too early to check prototype at /home/stas/src/build-gcc/build/djcross-gcc-8.2.0/tmpinst/bin/aclocal line 644.
aclocal: couldn't open directory '/home/stas/src/build-gcc/build/djcross-gcc-8.2.0/tmpinst/share/aclocal': No such file or directory

That's a bug. fixed.

But nothing changed.
I guess I need to remove what was already
built, and start from the beginning... sigh. :)

jwt27 commented

Okay that's weird. Looks like something went wrong building automake? I haven't seen that before.

I guess I need to remove what was already built, and start from the beginning... sigh. :)

You only need to remove the gcc directory: rm build/djcross-gcc-8.2.0/

stsp commented
Copy long name executables to short name.
/home/stas/src/build-gcc/script/finalize.sh: line 13: /usr/local/cross/setenv-i586-pc-msdosdjgpp: Permission denied
/home/stas/src/build-gcc/script/finalize.sh: line 14: /usr/local/cross/setenv-i586-pc-msdosdjgpp: Permission denied
/home/stas/src/build-gcc/script/finalize.sh: line 15: /usr/local/cross/setenv-i586-pc-msdosdjgpp: Permission denied
/home/stas/src/build-gcc/script/finalize.sh: line 16: /usr/local/cross/setenv-i586-pc-msdosdjgpp: Permission denied
/home/stas/src/build-gcc/script/finalize.sh: line 18: /usr/local/cross/setenv-i586-pc-msdosdjgpp.bat: Permission denied
/home/stas/src/build-gcc/script/finalize.sh: line 19: /usr/local/cross/setenv-i586-pc-msdosdjgpp.bat: Permission denied
/home/stas/src/build-gcc/script/finalize.sh: line 20: /usr/local/cross/setenv-i586-pc-msdosdjgpp.bat: Permission denied
jwt27 commented

Fixed it.

stsp commented

:)

To remove temporary build files, use: rm -rf build/
To remove downloaded source packages, use: rm -rf download/
./build-djgpp.sh: line 283: /usr/local/cross/setenv-i586-pc-msdosdjgpp: Permission denied
./build-djgpp.sh: line 284: /usr/local/cross/setenv-i586-pc-msdosdjgpp.bat: Permission denied

So it just happened in another place.
I think I am done for now, but I'll test the rest tomorrow.

jwt27 commented

Ah, yes. forgot about those. Should be fixed now.

stsp commented

Hmm, looks like it now builds!
Thank you. :)

stsp commented

But your scripts still contain the wrong
line-endings, so I always have to manually
fix them.

jwt27 commented

But your scripts still contain the wrong line-endings, so I always have to manually fix them.

I fixed that just now by running dos2unix manually. No idea why git didn't auto-convert them, I thought I had that set up right. Will have to check my other repos too.

stsp commented

I fixed that just now by running dos2unix manually.

Where?
I don't have that fix in branch sudo.

jwt27 commented

I merged it in the main branch (generic) together with the changes from sudo.

stsp commented

Looks functional!
Thanks again.