Bug 90147

Summary: swrast: build error undeclared _SC_PHYS_PAGES on osx
Product: Mesa Reporter: Julien Isorce <julien.isorce>
Component: Mesa coreAssignee: mesa-dev
Status: RESOLVED FIXED QA Contact: mesa-dev
Severity: normal    
Priority: medium CC: brianp, jeremyhu, jon.turney, julien.isorce
Version: unspecified   
Hardware: Other   
OS: Mac OS X (All)   
Whiteboard:
i915 platform: i915 features:
Attachments: swrast: can retrieve system memory on osx
swrast: Build fix for darwin
Fix compilation when sys/sysctl.h is not present

Description Julien Isorce 2015-04-22 22:30:53 UTC
swrast.c:141:48: error: use of undeclared identifier '_SC_PHYS_PAGES'
      const long system_memory_pages = sysconf(_SC_PHYS_PAGES);

OSX 10.10.3
gcc --version
Configured with: --prefix=/Library/Developer/CommandLineTools/usr --with-gxx-include-dir=/usr/include/c++/4.2.1
Apple LLVM version 6.1.0 (clang-602.0.49) (based on LLVM 3.6.0svn)
Target: x86_64-apple-darwin14.3.0
Thread model: posix
Comment 2 Julien Isorce 2015-05-05 21:50:30 UTC
Created attachment 115565 [details] [review]
swrast: Build fix for darwin

Other solution from macports.
Comment 3 Brian Paul 2015-05-05 22:17:34 UTC
So which patch do you want to use?  Either looks OK to me.
Comment 4 Julien Isorce 2015-05-05 22:34:03 UTC
I would go for Jeremy's patch. Jeremy what do you think ?
Comment 5 Jeremy Huddleston Sequoia 2015-05-06 02:49:04 UTC
Yeah, I think the sysctl() approach is probably more portable if you want to go that route.

I was also thinking that this should be refactored into a more abstract layer since other places in mesa would benefit from it.
Comment 6 Brian Paul 2015-05-06 15:42:30 UTC
(In reply to Jeremy Huddleston from comment #5)
> Yeah, I think the sysctl() approach is probably more portable if you want to
> go that route.
> 

OK, I can commit that patch, but the cherry-pick info:

(cherry picked from commit 8da9f46f18fd4c73f2a9d708c86e7e3d5535b3d8)

refers to a commit that's not in Mesa, AFAICT.  Should I remove/fix that?



> I was also thinking that this should be refactored into a more abstract
> layer since other places in mesa would benefit from it.

src/gallium/auxiliary/os/os_misc.c has similar code but that's kind of unreachable from src/mesa/drivers/ so I'm content with this patch.
Comment 7 Jeremy Huddleston Sequoia 2015-05-06 15:47:46 UTC
Yes, please remove the 8da9f46f18fd4c73f2a9d708c86e7e3d5535b3d8 before commit to master.  I suspect it refers to the commit on my (unmerged) master branch from which I cherry-picked to an (also unmerged) release branch from which I generated the patches for MacPorts.
Comment 8 Brian Paul 2015-05-06 16:03:26 UTC
Pushed as commit 5b2d3480f57168d50ad24cf0b8c9244414bd3701
Comment 9 Jon Turney 2015-05-11 16:59:39 UTC
Created attachment 115698 [details] [review]
Fix compilation when sys/sysctl.h is not present

Unfortunately, this patch unconditionally includes sys/sysctl.h, which breaks compilation for me (see http://tinderbox.x.org/builds/2015-05-07-0008/logs/mesa-mesa/#build)

I can't find any evidence that sys/sysctl.h is required by POSIX.

Attached is an attempt to fix this.

Additionally, I'm not sure if any platform exists which has both interfaces, but preferring sysctl() to sysconf() as this patch does, would mean on any such platforms a different path would be used to that previously.
Comment 10 Brian Paul 2015-05-12 20:51:14 UTC
Julien, can you test the new patch?
Comment 11 Julien Isorce 2015-05-12 23:31:02 UTC
(In reply to Brian Paul from comment #10)
> Julien, can you test the new patch?

It is missing a #else just before #error "Unsupported platform", otherwise it is working fine.
Comment 12 Jon Turney 2015-05-17 13:24:11 UTC
My patch is superseded by http://lists.freedesktop.org/archives/mesa-dev/2015-May/084445.html
Comment 13 Brian Paul 2015-05-25 14:14:03 UTC
Looks like the patch was commited as 31cd2d75dc3844e40143f649fe383de17c152a13

Bug is resolved as closed so I presume that's it.  Re-open if not.

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.