Wt

In my opinion when installing packages/software you should make use of the "install" program to ensure proper file and directory permission and ownership, whatever the root umask is.

For WEBUSER and WEBGROUP you are definitely right, while /var/run/wt needs to be 0770 anyway.

This applies to v3.3.5.

While the stuff in /usr/local/lib and /usr/local/share seems to have the right permissions, the files in /usr/local/include/Wt, as well as the /usr/local/share/Wt itself still don't get the proper permissions.

This applied also to v3.3.6.

Please, keep in mind that if you run "sudo make install", then you need to know root password, otherwise sudo will fail.

It's really unlikely that root will install a system wide library like Wt just for himself.

Thus the need to use the standard install tool (from the GNU coreutils package) to install files and directories with proper permissions.

Please, refer to this page for basic details.

This applies to 3.3.7-rc1 as well.

The directory /usr/local/share/Wt is "drwx---------" (700), should be "drwxr-xr-x" (755).

The same goes for /usr/local/include/Wt

The same goes for Auth, Chart, Dbo, Dbo/backend, Http, Json, Mail, Payment, Render and Test under /usr/local/include/Wt.

Files seems to be ok as "-rwxr---r---" (644) .

And also applies to v3.3.7.

The library binaries (*.so.3.3.7) get installed under /usr/local/lib with proper permissions that make sense for users to use.

The support files in /usr/local/share/Wt/resources have proper permissions, while the parent directory /usr/local/share/Wt doesn't!

The header files under /usr/local/include/Wt are readable only by root.

Finally, WEBUSER and WEBGROUP variable values could be inferred during source tree configuration (by inspecting /etc/passwd).

There's also another missing step in the installation process.

You need to run

sudo ldconfig -v

or, in case you installed the shared library binaries under a directory other than those listed into

/etc/ld.so.conf and /etc/ld.so.conf.d/*

sudo ldconfig -v YOUR_LIBRARY_PATH_HERE

I'd suggest you to either add this to the "make install" actions or to document it in the "InstallationUnix.html" page.

Whatever the root's umask is, there are differences between the permission of the installed resource and shared library files (0644) and those of the include files (0600).

Both are installed as root (of course) but show differente permissions.

Anyway, besides the point of views (which I respect, but are opinions), I would like also to check the facts.

Installing a new shared library an a linux system without running soon after ldconfig will not make that library available for linking or loading.

Here's a quote from the top of man ldconfig:

ldconfig  creates  the necessary links and cache to the most recent shared
libraries found in the directories specified on the command line, in the
file /etc/ld.so.conf, and in the trusted directories, /lib and /usr/lib
(on some 64-bit architectures such as x86-64, lib and /usr/lib are
the trusted directories for 32-bit libraries, while /lib64 and /usr/lib64
are used for 64-bit libraries).

The cache is used by the run-time linker, ld.so or ld-linux.so.
ldconfig checks the header and filenames of the libraries it encounters
when determining which  versions  should  have  their  links updated.

At least on my system (Ubuntu Server) the default destination for the compiled libraries is /usr/local/lib which is mentioned in the /etc/ld.so.conf.d/libc.conf.

So, if I don't run ldconfig after the installation, those files won't be loaded at run time and the (Wt) application won't start.

hey Vincenzo,

You're right that ldconfig has to be executed after installing a library in one of the system library directories. In my experience however, 'make install' copies files, and very few 'make install' scripts run ldconfig.

Whether 'make install' has to run ldconfig is subject to opinions. It's complex to know whether you should run ldconfig or not, since it at least depends on the OS (Linux/Windows/OSX), the rights of the user invoking 'make install', the contents of /etc/ld.config.so, the fact if you're allowed to run ldconfig as sudoer, and possibly many other things. Which is according to me the reason that most 'make install's, in my experience, don't run ldconfig.

Whether you have to run ldconfig to make the dynamic linker find the libraries (installed in a system folder) is indeed a fact, that system administrators and package managers are well aware of.

Best regards,

Wim.

You are right. When make install (actually sudo make install) installs just binaries and other files, there's no need to run ldconfig (even though it wouldn't harm).

But when you install dynamically loaded libraries (aka shared libraries, aka .so files) you have to. Or wait until next reboot (that will run ldconfig). Linux admins hate reboots! ;-)

An installation by of shared libraries run by root without ldconfig is a half-installation.

An installation of just binaries and files with ldconfig does nothing bad, just an extra harmless command.

I wonder why you are so scared by ldconfig.

Because others don't think it's needed or don't believe is something that should be in a make install stanza?

I think you and the other guys at the Wt project are more smart than this, by far!

I think you can give the right motivation.

If I am root and install Wt, then I need to run ldconfig or you won't be able to run any application linked against Wt.

If I am not root, then I won't we able to do any system installation at all, running ldconfig as non-root will be uneffective.

If I am not root but I can install on world-writable system directory (aka 777), I think I have worse problems than a single ldconfig run.

Anyay, it's OK for me to go on running

sudo make install
sudo ldconfig -v

in case you decided to go without ldconfig.

P.S.

I can speak for Linux alone. I don't know how other OSes handle this kind of issues.

The issue is still present and both file and directory permissions and ldconfig manual workaround are needed in order to have the library and the development files usable.

LIbrary files have the proper permissions, but without ldconfig to be run they are useless.

As a reference, I just manually updated my jemalloc (v5.0.1) installation, as my Ubuntu server is stuck with an official older version.

This is the output for sudo make install once I ran make and make check

[enzo@Feynman ~/Desktop/Download/jemalloc-5.0.1] sudo make install
/usr/bin/install -c -d /usr/local/bin
/usr/bin/install -c -m 755 bin/jemalloc-config /usr/local/bin
/usr/bin/install -c -m 755 bin/jemalloc.sh /usr/local/bin
/usr/bin/install -c -m 755 bin/jeprof /usr/local/bin
/usr/bin/install -c -d /usr/local/include/jemalloc
/usr/bin/install -c -m 644 include/jemalloc/jemalloc.h /usr/local/include/jemalloc
/usr/bin/install -c -d /usr/local/lib
/usr/bin/install -c -m 755 lib/libjemalloc.so.2 /usr/local/lib
ln -sf libjemalloc.so.2 /usr/local/lib/libjemalloc.so
/usr/bin/install -c -d /usr/local/lib
/usr/bin/install -c -m 755 lib/libjemalloc.a /usr/local/lib
/usr/bin/install -c -m 755 lib/libjemalloc_pic.a /usr/local/lib
/usr/bin/install -c -d /usr/local/lib/pkgconfig
/usr/bin/install -c -m 644 jemalloc.pc /usr/local/lib/pkgconfig
/usr/bin/install -c -d /usr/local/share/doc/jemalloc
/usr/bin/install -c -m 644 doc/jemalloc.html /usr/local/share/doc/jemalloc
/usr/bin/install -c -d /usr/local/share/man/man3
/usr/bin/install -c -m 644 doc/jemalloc.3 /usr/local/share/man/man3

Please, pay attention on how the files get "installed" in the proper directory with proper permissions.

Under POSIX Unix-like OSes this is the proper way to do it.