The FreeType Project - Bugs: bug #45953, Problem with make install
You are not allowed to post comments on this tracker with your current authentication level.
bug #45953: Problem with make install
Submitter: | None | ||
Submitted: | Sun 13 Sep 2015 07:12:25 PM UTC | ||
Severity: | 3 - Normal | Item Group: | None |
Status: | Wont Fix | Privacy: | Public |
Assigned to: | wl | Open/Closed: | Closed |
Planned Release: | None |
Jump to the original submission
Sun 22 Nov 2015 06:10:38 AM UTC, comment #9: |
Werner LEMBERG <wl> |
Sun 22 Nov 2015 06:09:09 AM UTC, comment #8: I've now read various threads related to your problem, e.g.
|
Werner LEMBERG <wl> |
Sun 22 Nov 2015 01:41:53 AM UTC, comment #7: Freetype & other projects: the first time it is called, “make install” will create the required directories in /usr/include and set the rights according to user’s umask e.g. 0700, root being the owner makes for unreadable files in /usr/include, as a simple user anyway. To make them readable to a simple user you need to change permissions so that a simple user can read them e.g. with chmod.
|
Anonymous |
Wed 16 Sep 2015 11:47:37 AM UTC, comment #6: What exactly is the `behaviour of FreeType' that other libraries like HarfBuzz don't show?
|
Werner LEMBERG <wl> |
Wed 16 Sep 2015 09:37:08 AM UTC, comment #5: Fair enough, the projects who don’t exhibit the same behaviour are – amongst others – Harfbuzz, libmatroska, libebml, flac. They’re not 100% C projects but they are using autoconf. I did find some call of the kind “find … -exec chmod u+rwx,go+rx {} \;” but they were in dist targets, not in install.
|
Anonymous |
Mon 14 Sep 2015 05:43:02 AM UTC, comment #4: Well, can you show me a widely used C library that does what you suggest? In particular, it should be based on automake, or at least using autoconf.
|
Werner LEMBERG <wl> |
Mon 14 Sep 2015 03:54:50 AM UTC, comment #3: Sorry for the build problem, just forgot to regenerate configure. |
Anonymous |
Mon 14 Sep 2015 02:16:02 AM UTC, comment #2: Thanks for this very detailed and instructive answer even though I fail to see why it should apply to the headers. I mean the automake team argument is most certainly relevant to some use cases and to some extent it wouldn’t be justified to apply such rights blindly to every directory generated during the build. However Freetype being a dependency of numerous projects, its headers should most likely benefit of being world readable, and I mean even on the machines of the «overly cautious».
|
Anonymous |
Sun 13 Sep 2015 09:54:10 PM UTC, comment #1: In git, I've now modernized the installation a bit by using AC_PROG_MKDIR_P and removing the `mkinstalldirs' script. However, looking into other projects using automake (which produces very solid `make install' targets), I can't find a call to chmod 755 or an equivalent.
- Automake 1.8 used `mkdir -m 0755 -p --' to ensure that directories created by `make install' are always world readable, even if the installer happens to have an overly restrictive umask (e.g. 077). This was a mistake and has been reverted. There are at least two reasons why we must not use `-m 0755': - it causes special bits like SGID to be ignored, - it may be too restrictive (some setups expect 775 directories). So it seems that your idea has been finally rejected... I think that trusting the automake people is the right way. |
Werner LEMBERG <wl> |
Sun 13 Sep 2015 07:12:25 PM UTC, original submission:
There doesn't seem to be any call to chmod 755 in Makefile concerning the target directories in /usr/include namely
|
Anonymous |
No files currently attached
Depends on the following items: None found
Items that depend on this one: None found
There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.
Follow 3 latest changes.
Date | Changed by | Updated Field | Previous Value | => | Replaced by |
---|---|---|---|---|---|
2015-09-13 | wl | Status | None | Wont Fix | |
Assigned to | None | wl | |||
Open/Closed | Open | Closed |
Powered by Savane 3.13-4448.
Corresponding source code
[I hate the primitive, non-standard markup used on Savannah...]
... something like