Linux – Using symbolic links and git to manage build versions

The other answer that got downvoted for some reason is completely right: .configure will produce a log file config.log, which will show the details of the checking if libcurl supports https test (most likely via an attempt to compile a given program).

Look at this log file, find out if your version of libcurl really doesn't support http, or if there is some other problem (e.g. missing/wrong library or include paths, or wrong library order, or trouble with your gcc variant, or changes in the library). In the latter case, fix the problem, possibly in configure.in or the equivalent, possibly by adding more options to the ones you already have, or changing the order of the libraries, or using a different gcc version.

In the former case, since you compiled libcurl yourself, make sure it's configured correctly and does support https.

I've done similar things on multiple occasions when self-compiling stuff.

You won't find "official sources" on this, that's just basic developing technique. You can easily convince yourself that the log file contains more detailed information by looking at it. It's a bit verbose, search for the checking if libcurl string to see the important part.

Randomly installing different versions of libraries without knowing what's wrong is not going to help.

As alice has write permission to stuff/ directory, alice can modify its contents even if she isn't the owner of the files.

When using Linux ACLs, when file is created (or copied, as copy creates new file at target) permissions are applied as described by man acl. Moving a file with mv preserves permissions when the file can be moved without copying. Looks like for some reason mv can not move the file and does a copy instead, since ACLs are applied to myfile.

Creating a hard link is quite different. Creating a hard link creates a directory entry (at the target directory), which points to the same inode as the original file, in other words, the same file exists in more than one directory. File permissions, both ACLs and traditional UNIX permissions, are stored in the inode. As both /home/stuff/myfile and /home/bob/myfile point to the same inode, any change in either will reflect to the other. This is why alice can access the hard link. The permissions of /home/bob/myfile (777) are the same as the permissions of /home/stuff/myfile.

Symbolic links instead points to the target path. Accessing the file that the symbolic link is pointing to requires the same permissions as accessing the target file. Possibly alice doesn't have search (execute bit) access to bob's home directory, and therefore access fails.