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

[volkertb]

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]

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.

[volkertb]

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]

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]

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]

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]

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]

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]

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]

You are quick!
Trying now...

[stsp]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

Fixed it.

[stsp]

:)

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]

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

[stsp]

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

[stsp]

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

[jwt27]

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]

I fixed that just now by running dos2unix manually.

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

[jwt27]

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

[stsp]

Looks functional!
Thanks again.

[kostyan900ua]

Love