Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 261283 - sci-geosciences/grass-6.3.0 fails to build with _FORTIFY_SOURCE=2
Summary: sci-geosciences/grass-6.3.0 fails to build with _FORTIFY_SOURCE=2
Status: RESOLVED FIXED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Current packages (show other bugs)
Hardware: All Linux
: High normal (vote)
Assignee: Steve Arnold
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: fortify-source
  Show dependency tree
 
Reported: 2009-03-05 09:40 UTC by Martin von Gagern
Modified: 2009-03-23 07:21 UTC (History)
1 user (show)

See Also:
Package list:
Runtime testing required: ---


Attachments
Add S_IRUSR|S_IWUSR to tempfile creation (bug261283a.patch,1.43 KB, patch)
2009-03-05 10:04 UTC, Martin von Gagern
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Martin von Gagern 2009-03-05 09:40:43 UTC
grass-6.3.0 doesn't provide mode specifications when creating some temporary files, and current gcc/glibc complain about this, causing the build to fail. Here are the relevant messages from the build log:

...
In function ‘open’,
    inlined from ‘main’ at main.c:299:
/usr/include/bits/fcntl2.h:51: error: call to ‘__open_missing_mode’ declared with attribute error: open with O_CREAT in second argument needs 3 argu
ments
In function ‘open’,
    inlined from ‘main’ at main.c:300:
/usr/include/bits/fcntl2.h:51: error: call to ‘__open_missing_mode’ declared with attribute error: open with O_CREAT in second argument needs 3 argu
ments
make[2]: *** [OBJ.i686-pc-linux-gnu/main.o] Error 1
make[2]: Leaving directory `/var/tmp/portage/sci-geosciences/grass-6.3.0/work/grass-6.3.0/raster/r.drain'
...
In function ‘open’,
    inlined from ‘main’ at main.c:199:
/usr/include/bits/fcntl2.h:51: error: call to ‘__open_missing_mode’ declared with attribute error: open with O_CREAT in second argument needs 3 argu
ments
In function ‘open’,
    inlined from ‘main’ at main.c:200:
/usr/include/bits/fcntl2.h:51: error: call to ‘__open_missing_mode’ declared with attribute error: open with O_CREAT in second argument needs 3 argu
ments
In function ‘open’,
    inlined from ‘main’ at main.c:201:
/usr/include/bits/fcntl2.h:51: error: call to ‘__open_missing_mode’ declared with attribute error: open with O_CREAT in second argument needs 3 argu
ments
make[2]: *** [OBJ.i686-pc-linux-gnu/main.o] Error 1
make[2]: Leaving directory `/var/tmp/portage/sci-geosciences/grass-6.3.0/work/grass-6.3.0/raster/r.fill.dir'
...
Errors in:
/var/tmp/portage/sci-geosciences/grass-6.3.0/work/grass-6.3.0/raster/r.drain
/var/tmp/portage/sci-geosciences/grass-6.3.0/work/grass-6.3.0/raster/r.fill.dir
...
make: *** [default] Error 1
Comment 1 Martin von Gagern 2009-03-05 10:04:05 UTC
Created attachment 183984 [details, diff]
Add S_IRUSR|S_IWUSR to tempfile creation

I've just tested it; with this patch in place, the build succeeds again.
Comment 2 Martin von Gagern 2009-03-05 12:54:48 UTC
Upstream trunk has addressed this issue as well:
http://trac.osgeo.org/grass/changeset/34107
http://trac.osgeo.org/grass/changeset/34108

The mailing list discussion referred to in the commit message is probably this one here: http://thread.gmane.org/gmane.comp.gis.grass.devel/30010/focus=30019

There is also another one about umask and why they chose mode 0666:
http://thread.gmane.org/gmane.comp.gis.grass.devel/6720/focus=6722

So if you want, you can backport those changesets instead of applying my patch.
Comment 3 Steve Arnold gentoo-dev 2009-03-23 03:58:48 UTC
Thanks for the patch; , S_IRUSR|S_IWUSR seems like the clean way to do it, and should result in the proper permissions regardless of the umask, no?  Other than the random parallel make errors and a minor glitch opening workspace files in wxpython gui, it seems to work as expected.
Comment 4 Martin von Gagern 2009-03-23 07:21:15 UTC
(In reply to comment #3)
> Thanks for the patch; , S_IRUSR|S_IWUSR seems like the clean way to do it, and
> should result in the proper permissions regardless of the umask, no?

Personally I think so as well. Especially since temporary files might be placed in some common public tem folder, while users might have set their umask with the intention of creating files in their home, and might have placed some more severe restrictions on thir home directory as a whole. As temporary files are an extension of a processes memory, in my opinion, and never to be shared, least permissions are best. Should we push this view upstream as well?