Bug 181244 - New port: devel/ocl-icd OpenCL Installable Client Driver
Summary: New port: devel/ocl-icd OpenCL Installable Client Driver
Status: Closed FIXED
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: amd64 Any
: Normal Affects Some People
Assignee: Koop Mast
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-08-12 21:40 UTC by O. Hartmann
Modified: 2015-09-20 02:40 UTC (History)
2 users (show)

See Also:


Attachments
file.shar (4.95 KB, text/plain)
2013-08-12 21:40 UTC, O. Hartmann
no flags Details
Updated ocl-icd port, build tested with 9.x and 10.x on amd64 and i386 (2.93 KB, text/plain)
2014-10-04 09:59 UTC, Marcus von Appen
no flags Details
proposed port devel/ocl-icd (4.55 KB, text/plain)
2015-04-10 10:27 UTC, O. Hartmann
no flags Details
Proposed update to 2.2.7. (5.01 KB, patch)
2015-06-30 11:36 UTC, Koop Mast
kwm: maintainer-approval? (kwm)
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description O. Hartmann 2013-08-12 21:40:01 UTC
The port provides a OpenCL Installable Client Driver as provided by https://forge.imag.fr/projects/ocl-icd/.

Fix: Patch attached with submission follows:
Comment 1 Marcus von Appen freebsd_committer freebsd_triage 2013-12-02 18:10:07 UTC
Responsible Changed
From-To: freebsd-ports-bugs->mva

I'll take it.
Comment 2 Marcus von Appen freebsd_committer freebsd_triage 2013-12-02 20:51:44 UTC
The port misses a dependency on ruby, which seems to be required for
building. On adding USE_RUBY=yes, it fails with

[...]
gmake[2]: Entering directory `/usr/ports/devel/ocl-icd/work/ocl-icd-2.0.2'
  CC       libOpenCL_la-ocl_icd_loader.lo
  CC       libOpenCL_la-ocl_icd_loader_gen.lo
  CC       libdummy_icd.lo
  CC       libdummy_icd_gen.lo
cc1: warnings being treated as errors
In file included from ocl_icd_loader.h:30,
                 from ocl_icd_loader_gen.c:29:
ocl_icd.h:30: warning: expected [error|warning|ignored] after '#pragma GCC diagnostic'
ocl_icd.h:31: warning: unknown option after '#pragma GCC diagnostic' kind
cc1: warnings being treated as errors
ocl_icd_loader.c:40: warning: expected [error|warning|ignored] after '#pragma GCC diagnostic'
ocl_icd_loader.c:41: warning: unknown option after '#pragma GCC diagnostic' kind
In file included from ocl_icd_loader.h:30,
                 from ocl_icd_loader_gen.c:29:
[...]

on RELENG_9 (gcc 4.2.1). Can you please fix this?

Thanks
Marcus
Comment 3 Marcus von Appen freebsd_committer freebsd_triage 2014-01-06 07:01:40 UTC
On, Mon Dec 02, 2013, Marcus von Appen wrote:

> The port misses a dependency on ruby, which seems to be required for
> building. On adding USE_RUBY=yes, it fails with
>
> [...]
> gmake[2]: Entering directory `/usr/ports/devel/ocl-icd/work/ocl-icd-2.0.2'
>   CC       libOpenCL_la-ocl_icd_loader.lo
>   CC       libOpenCL_la-ocl_icd_loader_gen.lo
>   CC       libdummy_icd.lo
>   CC       libdummy_icd_gen.lo
> cc1: warnings being treated as errors
> In file included from ocl_icd_loader.h:30,
>                  from ocl_icd_loader_gen.c:29:
> ocl_icd.h:30: warning: expected [error|warning|ignored] after '#pragma GCC diagnostic'
> ocl_icd.h:31: warning: unknown option after '#pragma GCC diagnostic' kind
> cc1: warnings being treated as errors
> ocl_icd_loader.c:40: warning: expected [error|warning|ignored] after '#pragma GCC diagnostic'
> ocl_icd_loader.c:41: warning: unknown option after '#pragma GCC diagnostic' kind
> In file included from ocl_icd_loader.h:30,
>                  from ocl_icd_loader_gen.c:29:
> [...]
>
> on RELENG_9 (gcc 4.2.1). Can you please fix this?


This port as well as ports/181243 (devel/opencl-icd) are required for
ports/171914 (devel/pocl). Please let me know about the required changes
from above.

Thanks
Marcus
Comment 4 Marcus von Appen freebsd_committer freebsd_triage 2014-10-04 09:59:28 UTC
Created attachment 147961 [details]
Updated ocl-icd port, build tested with 9.x and 10.x on amd64 and i386

An updated version of the ocl-icd port, with many fixes to pet portlint. The build was tested on 9.x and 10.x amd64/i386.

Doesn't it need a pkg-message similar to the one from opencl-icd?
Comment 5 Marcus von Appen freebsd_committer freebsd_triage 2014-11-12 07:26:10 UTC
Is this still valid and does the patch look good to you?
Comment 6 Marcus von Appen freebsd_committer freebsd_triage 2015-02-07 08:43:24 UTC
Over to kwm
Comment 7 O. Hartmann 2015-04-10 10:27:33 UTC
Created attachment 155414 [details]
proposed port devel/ocl-icd
Comment 8 O. Hartmann 2015-04-10 10:28:49 UTC
The latest SHAR targets recent OCL-ICD 2.2.3. I've successfully built the port on CURRENT (as I do not have other versions at hand).
Comment 9 Koop Mast freebsd_committer 2015-04-19 17:03:30 UTC
hartman do you object to putting this port in the lang category? It seems to fit beter, we planning to put clover and beignet also in lang/. And there is the fact that devel/ is kind of over stuffed already.
Comment 10 O. Hartmann 2015-04-20 16:50:38 UTC
(In reply to Koop Mast from comment #9)

Mast, thank you very much for informing me about the plans. I object - since I see no reason putting this port into another category due to "overcrowding" categories. if this would be a reason, then the concept of categorization is a bit inappropriate.

Why "lang"? POCL is definitely no solitair language, like C or CLANG. Spekaing of CLANG, we have lang/clang and devel/llvm. LLVM is the backend of clang and it resides, for a good reason, in devel. 

I understand POCL, as ocl-icd too, as a architectural backend for openCL.

Having made my statement to this, I'm open for other arguments. I also admit that my understanding of POCL could be wrong.


By the way, I played around with new POCL 0.11 and I have another SHAR ready. There are two problems with the tests I ran into. The OpenCL examples compile/work not properly in two cases. 

I'll post another SHAR later this day with some comments on the last Makefile posted here (which didn't work for me!).

Regards,

O. Hartmann
Comment 11 Koop Mast freebsd_committer 2015-06-30 11:36:13 UTC
Created attachment 158177 [details]
Proposed update to 2.2.7.

Update to 2.2.7.

Add patch to build with clang.
Add LICENSE_FILE
No need to overwrite PKGCONFIGDIR
Make manpage regenration optional, don't try to build manpage even if depends are available.
Instead of patching the location of OpenCL/vendors use sed, since we need to patch two files.
Comment 12 O. Hartmann 2015-07-04 09:05:35 UTC
 I'm working on most recent CURRENT, if this is important (no 10.1 or 10.2 availble).

Droped in the latest patchset as provided - but build fails with error:

[...]
===>  Building for ocl-icd-2.2.7
gmake[2]: Entering directory '/usr/ports/devel/ocl-icd/work/ocl-icd-2.2.7'
 cd . && /bin/sh /usr/ports/devel/ocl-icd/work/ocl-icd-2.2.7/build-aux/missing automake-1.14 --foreign Makefile
/usr/ports/devel/ocl-icd/work/ocl-icd-2.2.7/build-aux/missing: automake-1.14: not found
[...]

This can be resolved by performing autoreconf and setting 

[...]
USES = gmake pathfix autoreconf libtool 
[...]

in Makefile.

With that, build performs well. But installation fails with

[...]
===>   Registering installation for ocl-icd-2.2.7
pkg-static: Unable to access file /usr/ports/devel/ocl-icd/work/stage/usr/local/libdata/pkgconfig/OpenCL.pc: No such file or directory
pkg-static: Unable to access file /usr/ports/devel/ocl-icd/work/stage/usr/local/libdata/pkgconfig/ocl-icd.pc: No such file or directory
*** Error code 74
[...]

since the files in question are about to be installed in ${PREFIX}/lib/pkgconfigdir instead of desired ${PREFIX}/libdata/pkgconfigdir as of my understanding would be the more clean location (lib is supposed to hold libraries and the metadata/config data should go to libdata).

Is there a voodoo trick delegating $(libdir) from the Ports framework? In my original patch, I had to patch Makefile.am to meet this aspect, but this seems not to be of convenience for you.
Comment 13 Koop Mast freebsd_committer 2015-07-09 10:55:55 UTC
(In reply to ohartman from comment #12)
> [...]
> ===>  Building for ocl-icd-2.2.7
> gmake[2]: Entering directory '/usr/ports/devel/ocl-icd/work/ocl-icd-2.2.7'
>  cd . && /bin/sh /usr/ports/devel/ocl-icd/work/ocl-icd-2.2.7/build-aux/missing automake-1.14 --foreign Makefile
> /usr/ports/devel/ocl-icd/work/ocl-icd-2.2.7/build-aux/missing: automake-1.14: not found
> [...]

I can't reproduce this, neither on my devel machine nor with poudriere. Most of the time it has something to do with time not being set correctly.

The missing libdata/pkgconfig files is due to running autoreconf since that overwrites the pathfix changes.
Comment 14 O. Hartmann 2015-07-11 07:40:01 UTC
(In reply to Koop Mast from comment #13)

"... it has something to do with time not being set correctly [...]"

I do not understand. I see this error on several boxes I have installed and setup recently. I do not use poudriere. The boxes in questions are setup from scratch, last one a week ago. /usr/ports is a SVN tree, checked out via svn (not svnlite).All systems in question are CURRENT (most recent) and one 10.1-STABLE.

I see this error also on devel/pocl I propoesed also. In devel/pocl it is aclocal-1.4 missing. Installed is devel/autotools which reels in a bunch of GNU autotools and I consider it correct.

Since I do not see where the time comes into play I consider a problem in the Mk-setups, which are very hard to investigate for my opinion. Have you any idea to track down the problem further?

I think the problem is a kind of serious since I consider the ports system have to be robust against localised/local configurations. What works in a sterile jail or pudriere hasn't implicitely work on a "grown" system with individual configured ports.

Regards,
Oliver
Comment 15 O. Hartmann 2015-07-28 04:36:50 UTC
@Koop Mast :
I was just wondering on what platform you succeeded compiling the port. On all CURRENT systems, longer running and fresh installations, I wasn't able to compile the ports with your suggestion. I had always have to use the option

USE_AUTOTOOLS= aclocal

A manual installation trial in work with the unpacked/patched sources always revelas that automake 1.14 was used generating some of the scripts and is missing.

Today, I see this on several updated CURRENT boxes of mine (most recent ports tree update as of today, "... Updated to revision 393050."

[...]
===>>> Starting check of installed ports for available updates

===>>> The devel/automake14 port has been deleted: Has expired: Not used in the ports tree anymore
===>>> Aborting update

I will provide you soon with another patchset, aclocal included.
Comment 16 Tijl Coosemans freebsd_committer 2015-08-09 20:06:09 UTC
(In reply to ohartman from comment #15)
> I wasn't able to compile the ports with your suggestion. I had always have to use the option
> 
> USE_AUTOTOOLS= aclocal
> 
> A manual installation trial in work with the unpacked/patched sources always revelas that automake 1.14 was used generating some of the scripts and is missing.

Upstream used automake 1.14, but we have automake 1.15 in the ports tree.  The reason it's looking for automake is probably because you have USE_AUTOTOOLS=aclocal.  Automake has to be run after aclocal.  So try removing that and also try without /etc/make.conf.
Comment 17 O. Hartmann 2015-08-10 04:43:26 UTC
(In reply to Tijl Coosemans from comment #16)

Without make.conf and USE_AUTOTOOLS=aclocal the port searches for automake 1.14! On CURRENT/ports tree most recent, I'm unable to reproduce Koop Maast's positive report of compilation.

I consider now USE_AUTOTOOLS=aclocal as a required tag. The port compiles with that tag set successfully. there is only one bug in one test only shwoing up on FreeBSD and needs to be dealt with.
Comment 18 Tijl Coosemans freebsd_committer 2015-08-10 08:19:03 UTC
So I downloaded "Proposed update to 2.2.7" to /tmp and did the following:

cd /usr/ports
svn patch /tmp/ocl-icd-2.2.7.diff
cd devel/ocl-icd
make

And it just worked.  I looked at the distfile contents and all time stamps look good, meaning all files generated by autotools are generated in the correct order.  There's also a script named "bootstrap" there that runs autoreconf which guarantees all the different autotools are run correctly.  So, there should be no need to rerun any autotool.  I suspect you still have other modifications besides USE_AUTOTOOL=aclocal that are causing problems.  Try moving your devel/ocl-icd out of the way and then run the above commands.
Comment 19 commit-hook freebsd_committer 2015-09-17 17:45:59 UTC
A commit references this bug:

Author: kwm
Date: Thu Sep 17 17:45:24 UTC 2015
New revision: 397197
URL: https://svnweb.freebsd.org/changeset/ports/397197

Log:
  Add ocl-icd - OpenCL Installable Client Driver.

  This library provides a way that OpenCL programs can open several
  ICD's. The Intel (beignet) and AMD/ATI (Clover for Mesa) OpenCL
  implimentations will be build as ICD's. This has as benefit
  that programs will not link directly against the OpenCL
  implimentation but against ocl-icd. The user needs to manualy
  install the OpenCL implimentation they want to use.

  PR:		181244
  Submitted by:	ohartman@zedat.fu-berlin.de

Changes:
  head/devel/Makefile
  head/devel/ocl-icd/
  head/devel/ocl-icd/Makefile
  head/devel/ocl-icd/distinfo
  head/devel/ocl-icd/files/
  head/devel/ocl-icd/files/patch-ocl__icd__debug.h
  head/devel/ocl-icd/files/patch-ocl__icd__loader.c
  head/devel/ocl-icd/pkg-descr
  head/devel/ocl-icd/pkg-plist
Comment 20 Mark Linimon freebsd_committer freebsd_triage 2015-09-20 02:40:48 UTC
Committed by kwm as revision 397197.