bugThe 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: 

[I hate the primitive, non-standard markup used on Savannah...]

... something like

umask 0022; make install



Werner LEMBERG <wl>
Group administrator
Sun 22 Nov 2015 06:09:09 AM UTC, comment #8: 

I've now read various threads related to your problem, e.g.

https://lists.gnu.org/archive/html/bug-automake/2012-08/msg00001.html

and I think that there's only one solution for your problem currently: Always set the umask while doing `make install', something like
+verbatim+
umask 0022; make install-verbatim-

Perhaps it makes sense for you to create a small script that you can use for all packages whenever you have to say `make install'.

And yes, FreeType does remove include directories while doing `make install', because the header directory layout has changed between versions, and I want to be sure that no stale header files are interfering.

Werner LEMBERG <wl>
Group administrator
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.

The behaviour I was previously referring to pertains to what happens after that.

Freetype: for every subsequent make install you have to repeat the previous procedure i.e. correct manually to make headers readable.

Other projects: you don’t need to, that’s it.

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>
Group administrator
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.

Just to be sure, I tried removing the directories each of these projects added in /usr/include during a make install and it appears you were right. None of them actually did a chmod or any operation to the same effect. So the directory does take the current umask of the user into account, which in my case implies attributing rights 0700.

That being said and as I stated previously, none of them do exhibit the same behavior as Freetype. Once the (manual) call to chmod has been done, there is no need to do it at every subsequent make install. I’ll have to do some more digging to establish the reason why the pre-existing rights are preserved. I don’t think the directory isn’t deleted though, since its ctime is systematically updated.

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.

I don't say that the automake team is right for every use case.  I simply didn't found another reference after a quick search.

Werner LEMBERG <wl>
Group administrator
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».

From what I read the automake team stanza states why it is a bad idea to do so indiscriminately and on automake’s side and I agree with it. Especially since it could overwrite setgid bits but none of the concerned headers or directories is in that case. Anyway it’s trivial to overcome, for instance with chmod og+rx such bits are preserved if ever they were needed.

Moreover there are a few other projects I usually build, I doubt that Freetype is the only one relying on autotools however except Freetype none of them happens to generate this kind of behaviour. I might have been wrong by suggesting that it could be done with chmod 755, as obviously chmod og+rx should work as well, but apparently you checked for it too.

Best regards,

Raphaël Bazaud

PS: «make install» seems temporarily broken, as if MKDIR_P wasn’t properly substitued. After doing a distclean, configure I get the following error message

rm -rf /usr/include/freetype2
/bin/bash: MKDIR_P@ : commande introuvable
/home/xxxxxxx/src/freetype2/builds/unix/install.mk:32: recipe for target
'install' failed
make: * [install] Error 127

«commande introuvable» being the french translation of «command not found.»

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.

Looking into automake's NEWS file, I see this remark for an older release:




  - 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>
Group administrator
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

/usr/include/freetype2/
/usr/include/freetype2/freetype/
/usr/include/freetype2/freetype/config/

That isn't a problem as long as users don't change the default umask i.e. 0022 for Debian. However if someone uses for instance 0077 then make install allows only root to read the previously mentionned directories thus making it impossible to build any project depending on freetype as a user e.g. Harfbuzz unless doing a chmod 755 manually afterward.

Anonymous

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by wl (Posted a comment)
  •  

    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 StatusNone Wont Fix
        Assigned toNone wl
        Open/ClosedOpen Closed

    Back to the top

    Powered by Savane 3.13-4448.
    Corresponding source code