Arch Linux

Description:

This very likely to be considered "upstream", ie at NVIDIA, however,
whilst logged into NVIDIA's "Developer Zone", their "Submit a new bug"
page allowed me to type the whole report in, and press the Submit
button before telling me I wasn't a "Registered" developer and so
couldn't submit a bug - hmmm ?

Anyroad, we're thinking that as you are packaging cuda-sdk and
cuda-toolkit for Arch, you have more chance of being a "Registered"
developer and so getting something passed upstream, or in this case,
applying an Arch-specific patch.

Basically, any sample that uses findgllib.mk to determine where
libGL.so, libGLU.so and even libX11.so will spew out warnings
because the code that checks for the distribution fails to parse
Arch's /etc/issue.

It's a simple patch. we went with this (also attached) one, against

/opt/cuda/samples/5_Simulations/nbody/findgllib.mk

--- findgllib.mk.dist 2016-05-01 23:04:03.000000000 +1200
+++ findgllib.mk 2016-09-16 13:47:21.100160762 +1200
@@ -64,6 +64,7 @@
RHEL = $(shell echo $(DISTRO) | grep -i 'red\|rhel' >/dev/null 2>&1; echo $$?)
CENTOS = $(shell echo $(DISTRO) | grep -i centos >/dev/null 2>&1; echo $$?)
SUSE = $(shell echo $(DISTRO) | grep -i suse >/dev/null 2>&1; echo $$?)
+ ARCHL = $(shell echo $(DISTRO) | grep -i arch >/dev/null 2>&1; echo $$?)
ifeq ("$(UBUNTU)","0")
ifeq ($(HOST_ARCH)-$(TARGET_ARCH),x86_64-armv7l)
GLPATH := /usr/arm-linux-gnueabihf/lib
@@ -102,6 +103,11 @@
GLPATH ?= /usr/lib64/nvidia
GLLINK ?= -L/usr/lib64/nvidia
DFLT_PATH ?= /usr/lib64
+ endif
+ ifeq ("$(ARCHL)","0")
+ GLPATH ?= /usr/lib64/nvidia
+ GLLINK ?= -L/usr/lib64/nvidia
+ DFLT_PATH ?= /usr/lib64
endif

# find libGL, libGLU, libXi,


although, given that on our 64-bit Arch, /usr/lib64 is a link to
/usr/lib, using the latter may be the more "correct" solution. We
leave that as an exercise for the reader!


As to using "ARCHL" for the name of $(DISTRO), I recalled that using
"ARCH" wasn't a good choice, eg, when I patched this last year, I used
"ARCHLX," however I wasn't aware then (indeed, only found out today!)
that cuda-sdk and cuda-toolkit were Arch packages, not PkgSrc additions
to our Arch systems (someone else handles that), hence not thinking to
flag this up.

Clearly, nearly every sample that has a graphical component is going
to need to find these libs, and so it likely to have a findgllib.mk, and
of course, they are all stand-alone files within a given sample's
source directory rather than something above all the sample, which is
slightly odd, given that most of the sample Makefiles all use relative
paths, as though no-one would ever want build outside of the Tookit
tree - but I digress.

According to an

md5sum /opt/cuda/samples/*/*/findgllib.mk

there are 23 identical findgllib.mk within the samples directory hierarchy.

Hoping this is useful

School of Engineering and Computer Science
Victoria University of Wellington
New Zealand

Additional info:
* package version(s)
* config and/or log files etc.

4.6.2-1-ARCH #1 SMP PREEMPT Wed Jun 8 08:40:59 CEST 2016 x86_64 GNU/Linux

cuda 7.5.18-2

although this will have been an issue for the NVIDIA sources for a long time,
maybe even "for ever".

Steps to reproduce:

Clearly I am not building the sample inside the system install so
a Makefile patch is also applied, but you'ld get the same if you
tried to build the samples in the Arch package "in situ".

$ cp -a /opt/cuda/samples/5_Simulations/nbody nbody-2016
$ cd nbody-2016
$ cp Makefile Makefile.dist
$ vim Makefile
$ diff Makefile.dist Makefile
134,135c134,135
< CCFLAGS :=
< LDFLAGS :=
---
> CCFLAGS := -std=gnu++98
> LDFLAGS := -L/usr/pkg/lib -rpath /usr/pkg/lib
184c184
< INCLUDES := -I../../common/inc
---
> INCLUDES := -I$(CUDA_PATH)/samples/common/inc
201c201
< LIBRARIES += -L../../common/lib/$(TARGET_OS)/$(TARGET_ARCH) $(GLLINK)
---
> LIBRARIES += -L$(CUDA_PATH)/common/lib/$(TARGET_OS)/$(TARGET_ARCH) $(GLLINK)
255,256c255,256
< $(EXEC) mkdir -p ../../bin/$(TARGET_ARCH)/$(TARGET_OS)/$(BUILD_TYPE)
< $(EXEC) cp $@ ../../bin/$(TARGET_ARCH)/$(TARGET_OS)/$(BUILD_TYPE)
---
> $(EXEC) mkdir -p ./bin/$(TARGET_ARCH)/$(TARGET_OS)/$(BUILD_TYPE)
> $(EXEC) cp $@ ./bin/$(TARGET_ARCH)/$(TARGET_OS)/$(BUILD_TYPE)
263c263
< rm -rf ../../bin/$(TARGET_ARCH)/$(TARGET_OS)/$(BUILD_TYPE)/nbody
---
> rm -rf ./bin/$(TARGET_ARCH)/$(TARGET_OS)/$(BUILD_TYPE)/nbody
$
$ make
>>> WARNING - libGL.so not found, refer to CUDA Getting Started Guide for how to find and install them. <<<
>>> WARNING - libGLU.so not found, refer to CUDA Getting Started Guide for how to find and install them. <<<
>>> WARNING - libX11.so not found, refer to CUDA Getting Started Guide for how to find and install them. <<<
...
... list of echo-ed Makefile commands that could be used to build the sample,
... as long as you know how to fix things for libGLEW being below /usr/pkg/lib
... as shown in the Makefile diff
...
$

Probably also worth pointing out that because you overide CCFLAGS to avoid
the GGC 6 issues, and not a specific CXXFLAGSm you get 12 (I counted them)
warnings about

cc1: warning: command line option '-std=gnu++98' is valid for C++/ObjC++ but not for C

but let's not go there in this issue.