Re: fetch(3): Authentication error when URL https://
2012/9/6 O. Hartmann : > Hello. > > Creating a port, I need to fectch sources from a site whos URL is > https://xxx.xxx.xxx. > > Doing so, I end up with an "Authentication error". This makes the fetch > process in the port's Makefile impossible. > > I tried to fetch the source tar-ball via "wget(1)", but this also fails, > wget suggests to use option --no-check-certificate: > > Connecting to launchpad.net (launchpad.net)|91.189.89.223|:443... connected. > ERROR: cannot verify launchpad.net's certificate, issued by > `/C=US/ST=Arizona/L=Scottsdale/O=GoDaddy.com, > Inc./OU=http://certificates.godaddy.com/repository/CN=Go Daddy Secure > Certification Authority/serialNumber=07969287': > Self-signed certificate encountered. > To connect to launchpad.net insecurely, use `--no-check-certificate'. Add in Makefile FETCH_ARGS= -p > > > Doing so succeeds. Is there a possibility to enable this > --no-check-certificate" with fetch, too? > > Regards, > Oliver > -- olivier ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: svn commit: r303789 - head/Mk
On Fri, Sep 07, 2012 at 01:25:24AM +0200, Juergen Lock wrote: > This seems to cause add-plist-buildinfo targets not found outside tb, > I guess you meant this? Yes, you are right. bdrewery appears to have already fixed it. mcl ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: install failure of ports
On 9/6/2012 5:57 PM, Tsurutani Naoki wrote: > I can't install any ports today. > For example: > > # cd /usr/ports/textproc/gsed > # make install > ... > gmake[2]: Nothing to be done for `install-exec-am'. > gmake[2]: Nothing to be done for `install-data-am'. > gmake[2]: Leaving directory > `/usr/local/work/usr/ports/textproc/gsed/work/sed-4.2.1' > gmake[1]: Leaving directory > `/usr/local/work/usr/ports/textproc/gsed/work/sed-4.2.1' > make: don't know how to make add-plist-buildinfo. Stop > *** Error code 2 > > Stop in /usr/ports/textproc/gsed. > # > > "add-plist-buildinfo" is found in Mk/bsd.port.mk, and seems to be added > recently. > > Is there any solution ? > > My host: > h116[root] % uname -a > FreeBSD h116.65.226.10.32118.vlan.kuins.net 8.2-PRERELEASE FreeBSD > 8.2-PRERELEASE #26: Sun > Jan 23 18:42:22 JST 2011 > turut...@h116.65.226.10.32118.vlan.kuins.net:/usr/local/work/usr/obj/usr/src/sys/POLYMER13 > > amd64 This is now fixed by r303796. It will take a while before portsnap picks up the change. Here is the patch againsg /usr/ports/Mk/bsd.port.mk to fix: http://dpaste.com/797570/plain/ -- Regards, Bryan Drewery bdrewery@freenode/EFNet ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
install failure of ports
I can't install any ports today. For example: # cd /usr/ports/textproc/gsed # make install ... gmake[2]: Nothing to be done for `install-exec-am'. gmake[2]: Nothing to be done for `install-data-am'. gmake[2]: Leaving directory `/usr/local/work/usr/ports/textproc/gsed/work/sed-4.2.1' gmake[1]: Leaving directory `/usr/local/work/usr/ports/textproc/gsed/work/sed-4.2.1' make: don't know how to make add-plist-buildinfo. Stop *** Error code 2 Stop in /usr/ports/textproc/gsed. # "add-plist-buildinfo" is found in Mk/bsd.port.mk, and seems to be added recently. Is there any solution ? My host: h116[root] % uname -a FreeBSD h116.65.226.10.32118.vlan.kuins.net 8.2-PRERELEASE FreeBSD 8.2-PRERELEASE #26: Sun Jan 23 18:42:22 JST 2011 turut...@h116.65.226.10.32118.vlan.kuins.net:/usr/local/work/usr/obj/usr/src/sys/POLYMER13 amd64 ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
INDEX now builds successfully on 7.x
___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
fetch(3): Authentication error when URL https://
Hello. Creating a port, I need to fectch sources from a site whos URL is https://xxx.xxx.xxx. Doing so, I end up with an "Authentication error". This makes the fetch process in the port's Makefile impossible. I tried to fetch the source tar-ball via "wget(1)", but this also fails, wget suggests to use option --no-check-certificate: Connecting to launchpad.net (launchpad.net)|91.189.89.223|:443... connected. ERROR: cannot verify launchpad.net's certificate, issued by `/C=US/ST=Arizona/L=Scottsdale/O=GoDaddy.com, Inc./OU=http://certificates.godaddy.com/repository/CN=Go Daddy Secure Certification Authority/serialNumber=07969287': Self-signed certificate encountered. To connect to launchpad.net insecurely, use `--no-check-certificate'. Doing so succeeds. Is there a possibility to enable this --no-check-certificate" with fetch, too? Regards, Oliver signature.asc Description: OpenPGP digital signature
Re: Help. Porting "FreeOCL" fails (atomic_ops.h missing, CLANG++ libc++ issues ...)
On 2012-09-06 20:28, O. Hartmann wrote:
...
With the patch for Mk/bsd.cmake.mk attached, I can not compile the port
with CLANG, compilation results in
[ 15%] Building CXX object src/CMakeFiles/FreeOCL.dir/image.cpp.o
/usr/ports/devel/freeocl/work/FreeOCL-0.3.6-Source/src/image.cpp:442:27:
error: member access into incomplete type 'struct _cl_event'
if (event_wait_list[i]->status < 0)
^
/usr/local/include/CL/cl.h:46:16: note: forward declaration of '_cl_event'
typedef struct _cl_event * cl_event;
^
Which package installed that /usr/local/include/CL/cl.h file? It looks
like it should take this header from the source package, not from
whatever is installed into /usr/local.
In the top-level CMakeLists.txt, there is this fragment:
include_directories(.)
include_directories(include)
include_directories(src)
which indicates to CMake it should add -I flags for each of those
directories. However, it seems -I/usr/local/include is placed earlier
in the arguments of the actual clang++ invocations:
/usr/bin/clang++ -DFreeOCL_EXPORTS -O2 -pipe -I/usr/local/include
-fno-strict-aliasing -I/usr/local/include -stdlib=libc++ -std=c++0x
-DFREEOCL_USE_CXX0X -DFREEOCL_ARCH_amd64 -O3 -ffast-math -fPIC
-I/usr/work/share/dim/ports/devel/freeocl/work/FreeOCL-0.3.6-Source/.
-I/usr/work/share/dim/ports/devel/freeocl/work/FreeOCL-0.3.6-Source/include
-I/usr/work/share/dim/ports/devel/freeocl/work/FreeOCL-0.3.6-Source/src
-o CMakeFiles/FreeOCL.dir/image.cpp.o -c
/usr/work/share/dim/ports/devel/freeocl/work/FreeOCL-0.3.6-Source/src/image.cpp
So it will take /usr/local/include/CL/cl.h before the cl.h under
${WRKSRC}.
Now, as to how we can convince CMake to put the -I/usr/local/include at
the end... Maybe we should just patch the CMakeLists.txt, but that is a
rather ugly solution. :)
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Help. Porting "FreeOCL" fails (atomic_ops.h missing, CLANG++ libc++ issues ...)
On 09/06/12 14:51, Dimitry Andric wrote:
> On 2012-09-05 16:45, O. Hartmann wrote:
> ...
>> Well, I tried LLVM/CLANG, but Cmake of the sources fairly fails many
>> checks especuially for OpenMP.
>
> Yes, it is currently not supported. I am not sure if there are serious
> attempts to add it.
>
>
>> Using clang++ requisites the usage of the
>> new libc++ (CXXFLAGS+= -stdlib=libc++). But this fails with this error:
> ...
>> /usr/ports/devel/freeocl/work/FreeOCL-0.3.6-Source/src/parser/parser.h:118:15:
>>
>> error: no viable conversion from 'std::__1::basic_istream' to
>> 'const bool'
>> const bool ok = in.get(c);
>> ^~
>
> This is a bug in FreeOCL. The istream::get() function returns an
> istream reference, which can't be cast directly to bool. However, there
> is a negation operator defined for istream, so the line can be changed
> to:
>
> const bool ok = !!in.get(c);
>
> I have attached a patch for the port as I have built it here with clang.
> I didn't add the dependency on atomic_ops yet, but it should be fairly
> trivial.
>
> Note I also needed a fix for Mk/bsd.cmake.mk, otherwise the required
> ${CPPFLAGS} would not be passed along to CMake, and then the build would
> still fail to find the atomic_ops headers in /usr/local/include.
With the patch for Mk/bsd.cmake.mk attached, I can not compile the port
with CLANG, compilation results in
[ 15%] Building CXX object src/CMakeFiles/FreeOCL.dir/image.cpp.o
/usr/ports/devel/freeocl/work/FreeOCL-0.3.6-Source/src/image.cpp:442:27:
error: member access into incomplete type 'struct _cl_event'
if (event_wait_list[i]->status < 0)
^
/usr/local/include/CL/cl.h:46:16: note: forward declaration of '_cl_event'
typedef struct _cl_event * cl_event;
^
/usr/ports/devel/freeocl/work/FreeOCL-0.3.6-Source/src/image.cpp:449:58:
error: allocation of incomplete type '_cl_event'
cmd->event = (blocking_read == CL_TRUE || event) ? new
_cl_event(command_queue->context) : NULL;
^
/usr/local/include/CL/cl.h:46:16: note: forward declaration of '_cl_event'
typedef struct _cl_event * cl_event;
^
/usr/ports/devel/freeocl/work/FreeOCL-0.3.6-Source/src/image.cpp:463:14:
error: member access into incomplete type '_cl_event'
cmd->event->command_queue = command_queue;
^
/usr/local/include/CL/cl.h:46:16: note: forward declaration of '_cl_event'
typedef struct _cl_event * cl_event;
^
/usr/ports/devel/freeocl/work/FreeOCL-0.3.6-Source/src/image.cpp:464:14:
error: member access into incomplete type '_cl_event'
cmd->event->command_type = CL_COMMAND_READ_IMAGE;
^
/usr/local/include/CL/cl.h:46:16: note: forward declaration of '_cl_event'
typedef struct _cl_event * cl_event;
Without the patch, CLANG++ doesn't find the atomic_ops.h header as you
wrote.
Oliver
signature.asc
Description: OpenPGP digital signature
New experimental gimp 2.8.2 port
Hi all, I've been continuing to maintain my gimp 2.8 experimental ports, more rigorously checking pkg-plist files and updating to 2.8.2 (well, just incrementing the version number in the Makefile). For those who are interested, until gimp 2.8 is properly imported in the port tree, I've put everything on a github repo: https://github.com/mazhe/gimp28_ports Along a script to update the dependancies and gimp itself. Still missing are the help ports, and a script to revert to the standard versions, I'll check that ASAP. Have a nice day, -- Matthieu Volat ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: RUN_DEPENDS=: not respected? Bug?
On 09/06/12 17:13, Alex Dupre wrote:
> O. Hartmann ha scritto:
>> Working on a small port for OpenCL support for CPUs via "freeocl",
>> I run into a problem (runing FreeBSD 10.0-CURRENT).
>>
>> The port requires devel/libatomic_ops, which installs a static library
>> /usr/lcoal/lib/libatomic_ops.a.
>>
>> Following the instructions in the Porter's Handbook for FreeBSD, I added
>> a line
>>
>> RUN_DEPENDS=
>> ${LOCALBASE}/lib/libatomic_ops.a:${PORTSDIR}/devel/libatomic_ops
>
> It seems strange to me that a port requires a static library at runtime.
> You should use BUILD_DEPENDS if the library is needed to build the port.
> And you shouldn't put if after inclusion of bsd.port.pre.mk.
> RUN_DEPENDS is for things required at runtime and so usually installed
> in the install step.
>
My fault. Obviously I didn't understood exactly what the meaning was -
I'm not an english native speaker.
BUIKD_DEPENDS=
works as expected and it is obviously a fault of mine that a previous
attempt failed.
Regards,
Oliver
signature.asc
Description: OpenPGP digital signature
INDEX build failed for 7.x
INDEX build failed with errors: Generating INDEX-7 - please wait.. Done. make_index: frescobaldi-2.0.7: no entry for /usr/ports/graphics/py-poppler-qt4 Committers on the hook: bdrewery gahr kmoore linimon makc mich nobutaka swills tabthorpe Most recent CVS update was: U databases/pecl-chdb/Makefile U devel/p5-Test-Class-Most/Makefile U graphics/mesa-demos/Makefile U net/p5-Net-Whois-RIPE/Makefile U net/p5-Net-Whois-RIPE/distinfo U print/frescobaldi/Makefile U print/frescobaldi/distinfo U print/frescobaldi/pkg-plist U sysutils/beadm/Makefile U sysutils/beadm/distinfo U sysutils/beadm/pkg-descr U x11/libfm/files/patch-configure U x11/mlterm/Makefile U x11-toolkits/tk84/Makefile ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: RUN_DEPENDS=: not respected? Bug?
O. Hartmann ha scritto:
> Working on a small port for OpenCL support for CPUs via "freeocl",
> I run into a problem (runing FreeBSD 10.0-CURRENT).
>
> The port requires devel/libatomic_ops, which installs a static library
> /usr/lcoal/lib/libatomic_ops.a.
>
> Following the instructions in the Porter's Handbook for FreeBSD, I added
> a line
>
> RUN_DEPENDS=
> ${LOCALBASE}/lib/libatomic_ops.a:${PORTSDIR}/devel/libatomic_ops
It seems strange to me that a port requires a static library at runtime.
You should use BUILD_DEPENDS if the library is needed to build the port.
And you shouldn't put if after inclusion of bsd.port.pre.mk.
RUN_DEPENDS is for things required at runtime and so usually installed
in the install step.
--
Alex Dupre
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Help. Porting "FreeOCL" fails (atomic_ops.h missing, CLANG++ libc++ issues ...)
Hello Dimitry,
thanks for your response and patches.
On 09/06/12 14:51, Dimitry Andric wrote:
> On 2012-09-05 16:45, O. Hartmann wrote:
> ...
>> Well, I tried LLVM/CLANG, but Cmake of the sources fairly fails many
>> checks especuially for OpenMP.
>
> Yes, it is currently not supported. I am not sure if there are serious
> attempts to add it.
>
>
>> Using clang++ requisites the usage of the
>> new libc++ (CXXFLAGS+= -stdlib=libc++). But this fails with this error:
> ...
>> /usr/ports/devel/freeocl/work/FreeOCL-0.3.6-Source/src/parser/parser.h:118:15:
>>
>> error: no viable conversion from 'std::__1::basic_istream' to
>> 'const bool'
>> const bool ok = in.get(c);
>> ^~
>
> This is a bug in FreeOCL. The istream::get() function returns an
> istream reference, which can't be cast directly to bool. However, there
> is a negation operator defined for istream, so the line can be changed
> to:
>
> const bool ok = !!in.get(c);
>
> I have attached a patch for the port as I have built it here with clang.
> I didn't add the dependency on atomic_ops yet, but it should be fairly
> trivial.
I fixed that, I forgot the pkg-plist, also. Will followup the PR I sent.
it is a simple line:
BUILD_DEPENDS= ...
>
> Note I also needed a fix for Mk/bsd.cmake.mk, otherwise the required
> ${CPPFLAGS} would not be passed along to CMake, and then the build would
> still fail to find the atomic_ops headers in /usr/local/include.
Is this going to be fixed with your patch in the ports tree?
I'm amazed by the speed you came up with the patches ...;-)
My port request can be found here:
http://www.freebsd.org/cgi/query-pr.cgi?pr=171376
and one for providing the OpenCL header:
http://www.freebsd.org/cgi/query-pr.cgi?pr=171375
Matthieu Volat also stated that there is another promising OpenCL port
"Portable OpenCL", pocl. It seems to have a better LLVM support by design:
http://sourceforge.net/apps/mediawiki/pocl/index.php?title=Main_Page
Attached you'll find my first naiv attempt to build a port-Makefile, but
I fail to fetch(1), since there is an authentication error while trying
to fetch from a HTTPS:// source.
My abilities in depp-insight-development are limited, so I'm happy if
some experienced developers could also look at those software projects
and help making a port ;-)
it would be nice having FreeOCL and portable OCL for comparison purposes
available on FreeBSD. I still have the hope to "lurd" more developers
and scientists back to FreeBSD. Never mind ...
oh
PORTNAME= pocl
PORTVERSION=0.6
CATEGORIES= devel
MAINTAINER= po...@freebsd.org
COMMENT=Portable OpenCL - an efficient open source
(MIT-licensed) implementation of the OpenCL 1.2 standard.
MASTER_SITES=
https://launchpad.net/pocl/${PORTVERSION}/0.6.0/+download/
#CONFLICTS= freeocl
CXXFLAGS+= -stdlib=libc++
LIB_DEPENDS=ltdl:${PORTSDIR}/devel/libltdl
#USE_GMAKE= yes
GNU_CONFIGURE= yes
USE_LDCONFIG= yes
.include
signature.asc
Description: OpenPGP digital signature
Re: Help. Porting "FreeOCL" fails (atomic_ops.h missing, CLANG++ libc++ issues ...)
On Thu, 2012-09-06 at 13:14 +0200, O. Hartmann wrote:
> I tried to add
>
> RUN_DEPENDS=
> ${LOCALBASE}/lib/libatomic_ops.a:${PORTSDIR}/devel/libatomic_ops
>
> to my provided Makefile, but this doesn't install the port
> devel/libatomic_ops.
> This is weird and inconsistent. I follow exact the steps suggested in
> the Porter's handbook, the _DEPENDS= section. The above RUN_DEPENDS=
> tag
> should ensure a check for the existence of the static library
>
> /usr/local/lib/libatomic_ops.a
>
> and if not existent, then install it. It doesn't work. Unfortunately,
> LIB_DEPENDS is considered for "shared libraries", so it isn't
> suitable.
> But LIB_DEPENDS get recognized, even if it fails, while RUN_DEPENDS
> seems not to be touched by the build process anyway ...
I am SO not a ports expert, but I think maybe for a static lib you need
BUILD_DEPENDS because it has to be available at build-time rather than
run-time.
-- Ian
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Automatic Port
On 9/5/2012 11:57 PM, Cy Schubert wrote: > Hi all, > > I'm considering a -devel port which checks out from our upline's VCS repo, > also generating a dynamic plist. I'm sure this is possible. Are there any > examples of this? > > AFAIK it had only been done with 1 port, and that has been reverted due to not having a known distinfo. The preferred way is to just do snapshot updates. That way the user is alerted to new versions. Otherwise they are sitting on this "" version forever until they *force* reinstall to get an upgrade. -- Regards, Bryan Drewery bdrewery@freenode/EFNet ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Automatic Port
In message , Chris Rees writes: > --000e0cdfc7bc127afc04c9025077 > Content-Type: text/plain; charset=ISO-8859-1 > > On 6 Sep 2012 05:57, "Cy Schubert" wrote: > > > > Hi all, > > > > I'm considering a -devel port which checks out from our upline's VCS repo, > > also generating a dynamic plist. I'm sure this is possible. Are there any > > examples of this? > > It's possible, but you can't then do distinfo checks. > > I don't think it's a good idea for this reason. The distinfo checks are there to verify the integrity of the tarball. Should a VCS become compromised any resulting tarball created by an upline would also be compromised and our distinfo would ensure the integrity of compromised source. In the case of a tarball which is rolled multiple times a week, e.g. ntp-devel, or daily, e.g. fwbuilder's devel branch, it would become a daily chore to maintain the latest devel package, in which case one would need to roll an updated port once every couple of weeks, kind of like a snapshot approach. I think I've seen only one port over the years use a VCS (CVS) to check out its source files. -- Cheers, Cy Schubert FreeBSD UNIX: Web: http://www.FreeBSD.org ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Help. Porting "FreeOCL" fails (atomic_ops.h missing, CLANG++ libc++ issues ...)
On 2012-09-05 16:45, O. Hartmann wrote:
...
Well, I tried LLVM/CLANG, but Cmake of the sources fairly fails many
checks especuially for OpenMP.
Yes, it is currently not supported. I am not sure if there are serious
attempts to add it.
Using clang++ requisites the usage of the
new libc++ (CXXFLAGS+= -stdlib=libc++). But this fails with this error:
...
/usr/ports/devel/freeocl/work/FreeOCL-0.3.6-Source/src/parser/parser.h:118:15:
error: no viable conversion from 'std::__1::basic_istream' to
'const bool'
const bool ok = in.get(c);
^~
This is a bug in FreeOCL. The istream::get() function returns an
istream reference, which can't be cast directly to bool. However, there
is a negation operator defined for istream, so the line can be changed
to:
const bool ok = !!in.get(c);
I have attached a patch for the port as I have built it here with clang.
I didn't add the dependency on atomic_ops yet, but it should be fairly
trivial.
Note I also needed a fix for Mk/bsd.cmake.mk, otherwise the required
${CPPFLAGS} would not be passed along to CMake, and then the build would
still fail to find the atomic_ops headers in /usr/local/include.
Index: Mk/bsd.cmake.mk
===
--- Mk/bsd.cmake.mk (revision 303593)
+++ Mk/bsd.cmake.mk (working copy)
@@ -50,12 +50,12 @@ BUILD_DEPENDS+= ${CMAKE_BIN}:${CMAKE_PORT}
CMAKE_ENV?= ${CONFIGURE_ENV}
CMAKE_ARGS+= -DCMAKE_C_COMPILER:STRING="${CC}" \
-DCMAKE_CXX_COMPILER:STRING="${CXX}" \
--DCMAKE_C_FLAGS:STRING="${CFLAGS}" \
--DCMAKE_C_FLAGS_DEBUG:STRING="${CFLAGS}" \
--DCMAKE_C_FLAGS_RELEASE:STRING="${CFLAGS}" \
--DCMAKE_CXX_FLAGS:STRING="${CXXFLAGS}" \
--DCMAKE_CXX_FLAGS_DEBUG:STRING="${CXXFLAGS}" \
--DCMAKE_CXX_FLAGS_RELEASE:STRING="${CXXFLAGS}" \
+-DCMAKE_C_FLAGS:STRING="${CPPFLAGS} ${CFLAGS}" \
+-DCMAKE_C_FLAGS_DEBUG:STRING="${CPPFLAGS} ${CFLAGS}" \
+-DCMAKE_C_FLAGS_RELEASE:STRING="${CPPFLAGS} ${CFLAGS}" \
+-DCMAKE_CXX_FLAGS:STRING="${CPPFLAGS} ${CXXFLAGS}" \
+-DCMAKE_CXX_FLAGS_DEBUG:STRING="${CPPFLAGS} ${CXXFLAGS}" \
+-DCMAKE_CXX_FLAGS_RELEASE:STRING="${CPPFLAGS} ${CXXFLAGS}" \
-DCMAKE_EXE_LINKER_FLAGS:STRING="${LDFLAGS}" \
-DCMAKE_MODULE_LINKER_FLAGS:STRING="${LDFLAGS}" \
-DCMAKE_SHARED_LINKER_FLAGS:STRING="${LDFLAGS}" \
Index: devel/freeocl/Makefile
===
--- devel/freeocl/Makefile (revision 0)
+++ devel/freeocl/Makefile (working copy)
@@ -0,0 +1,22 @@
+PORTNAME= freeocl
+PORTVERSION= 0.3.6
+CATEGORIES= devel
+
+MAINTAINER= po...@freebsd.org
+COMMENT= FreeOCL - a free OpenCL implementation for CPU
+
+#MASTER_SITES= http://freeocl.googlecode.com/files/FreeOCL-0.3.6-src.tar.gz
+MASTER_SITES= http://freeocl.googlecode.com/files/
+DISTNAME= FreeOCL-${PORTVERSION}-src
+
+WRKSRC= ${WRKDIR}/FreeOCL-${PORTVERSION}-Source
+
+USE_CMAKE= YES
+CMAKE_BUILD_TYPE= Release
+
+#USE_GCC= 4.7+
+
+CPPFLAGS+= -I${LOCALBASE}/include
+CXXFLAGS+= -stdlib=libc++
+
+.include
Index: devel/freeocl/files/patch-src__parser__parser.h
===
--- devel/freeocl/files/patch-src__parser__parser.h (revision 0)
+++ devel/freeocl/files/patch-src__parser__parser.h (working copy)
@@ -0,0 +1,11 @@
+--- src/parser/parser.h.orig 2012-09-02 19:00:41.0 +0200
src/parser/parser.h 2012-09-06 14:14:01.0 +0200
+@@ -115,7 +115,7 @@ namespace FreeOCL
+ inline std::istream &get(char &c)
+ {
+ c = 0;
+- const bool ok = in.get(c);
++ const bool ok = !!in.get(c);
+ if (c == '\n')
+ ++line;
+ if (!current_line.empty() && *current_line.rbegin() == '\n')
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Help. Porting "FreeOCL" fails (atomic_ops.h missing, CLANG++ libc++ issues ...)
On 09/06/12 13:33, Kurt Jaeger wrote:
> Hi!
>
>>> RUN_DEPENDS=
>>> ${LOCALBASE}/lib/libatomic_ops.a:${PORTSDIR}/devel/libatomic_ops
>>
>> Why did you not add it as LIB_DEPENDS or BUILD_DEPENDS ?
>
> Btw, any static library is always linked into the binary and
> therefore can by definition not be a RUN_DEPENDS, but always is
> a BUILD_DEPENDS.
>
Snakepit of logic :-( Sorry. BUILD_DEPENDS does the work as expected.
Thanks.
Oliver
signature.asc
Description: OpenPGP digital signature
RUN_DEPENDS=: not respected? Bug?
Working on a small port for OpenCL support for CPUs via "freeocl",
I run into a problem (runing FreeBSD 10.0-CURRENT).
The port requires devel/libatomic_ops, which installs a static library
/usr/lcoal/lib/libatomic_ops.a.
Following the instructions in the Porter's Handbook for FreeBSD, I added
a line
RUN_DEPENDS=
${LOCALBASE}/lib/libatomic_ops.a:${PORTSDIR}/devel/libatomic_ops
It seems that this line never gets touched! It never take any action as
described in the handbook.
The logic in the handbook is quite clear. Even if the file isn't found,
there should be a installation triggered! But it doens't. I tested my
point with the tag
LIB_DEPENDS=
which is for shared libraries according to the handbook. The build and
installation process always gets involved and triggered, even if it
fails later on, when the requiring port doesn't find the shared library
it would expect.
It seems this is a bug according to the Porter's Handbook.
Oliver
PORTNAME= freeocl
PORTVERSION=0.3.6
CATEGORIES= devel
MAINTAINER= po...@freebsd.org
COMMENT=FreeOCL - a free OpenCL implementation for CPU
#MASTER_SITES=
http://freeocl.googlecode.com/files/FreeOCL-0.3.6-src.tar.gz
MASTER_SITES= http://freeocl.googlecode.com/files/
DISTNAME= FreeOCL-${PORTVERSION}-src
WRKSRC= ${WRKDIR}/FreeOCL-${PORTVERSION}-Source
USE_CMAKE= YES
CMAKE_BUILD_TYPE= Release
USE_GCC=4.6+
#CXXFLAGS+= -stdlib=libc++
.include
RUN_DEPENDS=
${LOCALBASE}/lib/libatomic_ops.a:${PORTSDIR}/devel/libatomic_ops
.include
signature.asc
Description: OpenPGP digital signature
Re: Help. Porting "FreeOCL" fails (atomic_ops.h missing, CLANG++ libc++ issues ...)
On 09/06/12 12:16, Matthieu Volat wrote:
> On Wed, 05 Sep 2012 16:45:49 +0200
> "O. Hartmann" wrote:
>
>> Hello.
>>
>> FreeBSD has fallen back far behind the standards of modern scientific
>> computing and I dsperately look for solutions having OpenCL support on
>> FreeBSD anyway.
>>
>> I stumbled into this project recently:
>>
>> FreeOCL at
>> http://code.google.com/p/freeocl/
>>
>> or the sources located at
>>
>> http://code.google.com/p/freeocl/downloads/detail?name=FreeOCL-0.3.6-src.tar.gz&can=2&q=
>>
>> For your convenience, please find my naive attempt of a port attached to
>> this email.
>>
>> Well, I tried LLVM/CLANG, but Cmake of the sources fairly fails many
>> checks especuially for OpenMP. Using clang++ requisites the usage of the
>> new libc++ (CXXFLAGS+= -stdlib=libc++). But this fails with this error:
>>
>>
>> [...]
>> [ 17%] Building CXX object src/CMakeFiles/FreeOCL.dir/codebuilder.cpp.o
>> In file included from
>> /usr/ports/devel/freeocl/work/FreeOCL-0.3.6-Source/src/codebuilder.cpp:26:
>> /usr/ports/devel/freeocl/work/FreeOCL-0.3.6-Source/src/parser/parser.h:118:15:
>> error: no viable conversion from 'std::__1::basic_istream' to
>> 'const bool'
>> const bool ok = in.get(c);
>>^~
>> /usr/ports/devel/freeocl/work/FreeOCL-0.3.6-Source/src/codebuilder.cpp:444:13:
>> warning: 70 enumeration values not handled in switch: 'VOID', 'BOOL',
>> 'HALF'... [-Wswitch]
>> switch(native->get_type_id())
>>^
>> 1 warning and 1 error generated.
>> *** [src/CMakeFiles/FreeOCL.dir/codebuilder.cpp.o] Error code 1
>> [..]
>>
>>
>> I tried also setting USE_GCC= 4.7+ using gcc-4.7 I installed, but that
>> fails with
>>
>> [...]
>> -- Build files have been written to:
>> /usr/ports/devel/freeocl/work/FreeOCL-0.3.6-Source
>> ===> Building for freeocl-0.3.6
>> Scanning dependencies of target FreeOCL
>> [ 1%] Building CXX object src/CMakeFiles/FreeOCL.dir/freeocl.cpp.o
>> In file included from
>> /usr/ports/devel/freeocl/work/FreeOCL-0.3.6-Source/src/freeocl.cpp:18:0:
>> /usr/ports/devel/freeocl/work/FreeOCL-0.3.6-Source/src/freeocl.h:71:2:
>> error: 'u_int64_t' does not name a type
>> *** [src/CMakeFiles/FreeOCL.dir/freeocl.cpp.o] Error code 1
>> [...]
>>
>> I think patches are required.
>>
>> More disturbing is the use of gcc-4.6 via
>>
>> USE_GCC= 4.6+
>>
>> The error is then a compalin about a missing include file
>>
>> atomic_ops.h
>>
>> which is located in the abandoned KSE facility of the kernel, so the
>> includes seem not to be installed anymore - but since I'm not involved
>> in the development, I can only guess and ask the people here.
>>
>> Maybe some experienced freeBSD developers with the same need for OpenCl
>> is willing to pick up this and help a bit.
>>
>> Well, as far as I see, the FreeOCL project of Roland Borchard is a
>> OpenCL library for CPU usage. As far as I can understand, if we on
>> FreeBSd could have a library "libOpenCL" as this is usually installed by
>> the nVidia BLOB drivers on Linux for the use of OpenCL/GPGPU support
>> with their GPUs, this would fill a still painfull open gap in FreeBSD as
>> a scientific development platform.
>>
>> There is still no suitable compiler for OpenCL out here for freeBSD, but
>> I have still the hope that LLVM can provide such a thing in the near future.
>>
>> I cross post this posting also to "performance" in the hope finding some
>> people attracted and "lurd" into this subject.
>>
>> Regards,
>>
>> O. Hartmann
>
> Hello,
>
> I've taken a quick look in that implementation : it seems to depends on
> devel/libatomic_ops even if the devs did not write any CMake checks for that
> (grrr).
>
> After installing it, I was able to build the port with gcc-46 without
> problems, if I find some time, I will try to test it later.
>
> Btw, did you had a look to poCL too
> (http://sourceforge.net/apps/mediawiki/pocl/index.php?title=Main_Page)? I
> know the Debian people were considering it for a base implementation, but I'm
> a bit clueless about all those foss versions coming. A comparison could be
> helpful ^^
>
I tried to add
RUN_DEPENDS=
${LOCALBASE}/lib/libatomic_ops.a:${PORTSDIR}/devel/libatomic_ops
to my provided Makefile, but this doesn't install the port
devel/libatomic_ops.
This is weird and inconsistent. I follow exact the steps suggested in
the Porter's handbook, the _DEPENDS= section. The above RUN_DEPENDS= tag
should ensure a check for the existence of the static library
/usr/local/lib/libatomic_ops.a
and if not existent, then install it. It doesn't work. Unfortunately,
LIB_DEPENDS is considered for "shared libraries", so it isn't suitable.
But LIB_DEPENDS get recognized, even if it fails, while RUN_DEPENDS
seems not to be touched by the build process anyway ...
signature.asc
Description: OpenPGP digital signature
Re: Help. Porting "FreeOCL" fails (atomic_ops.h missing, CLANG++ libc++ issues ...)
On 09/06/12 12:16, Matthieu Volat wrote: > On Wed, 05 Sep 2012 16:45:49 +0200 > "O. Hartmann" wrote: > >> Hello. >> >> FreeBSD has fallen back far behind the standards of modern scientific >> computing and I dsperately look for solutions having OpenCL support on >> FreeBSD anyway. >> >> I stumbled into this project recently: >> >> FreeOCL at >> http://code.google.com/p/freeocl/ >> >> or the sources located at >> >> http://code.google.com/p/freeocl/downloads/detail?name=FreeOCL-0.3.6-src.tar.gz&can=2&q= >> >> For your convenience, please find my naive attempt of a port attached to >> this email. >> >> Well, I tried LLVM/CLANG, but Cmake of the sources fairly fails many >> checks especuially for OpenMP. Using clang++ requisites the usage of the >> new libc++ (CXXFLAGS+= -stdlib=libc++). But this fails with this error: >> >> >> [...] >> [ 17%] Building CXX object src/CMakeFiles/FreeOCL.dir/codebuilder.cpp.o >> In file included from >> /usr/ports/devel/freeocl/work/FreeOCL-0.3.6-Source/src/codebuilder.cpp:26: >> /usr/ports/devel/freeocl/work/FreeOCL-0.3.6-Source/src/parser/parser.h:118:15: >> error: no viable conversion from 'std::__1::basic_istream' to >> 'const bool' >> const bool ok = in.get(c); >>^~ >> /usr/ports/devel/freeocl/work/FreeOCL-0.3.6-Source/src/codebuilder.cpp:444:13: >> warning: 70 enumeration values not handled in switch: 'VOID', 'BOOL', >> 'HALF'... [-Wswitch] >> switch(native->get_type_id()) >>^ >> 1 warning and 1 error generated. >> *** [src/CMakeFiles/FreeOCL.dir/codebuilder.cpp.o] Error code 1 >> [..] >> >> >> I tried also setting USE_GCC= 4.7+ using gcc-4.7 I installed, but that >> fails with >> >> [...] >> -- Build files have been written to: >> /usr/ports/devel/freeocl/work/FreeOCL-0.3.6-Source >> ===> Building for freeocl-0.3.6 >> Scanning dependencies of target FreeOCL >> [ 1%] Building CXX object src/CMakeFiles/FreeOCL.dir/freeocl.cpp.o >> In file included from >> /usr/ports/devel/freeocl/work/FreeOCL-0.3.6-Source/src/freeocl.cpp:18:0: >> /usr/ports/devel/freeocl/work/FreeOCL-0.3.6-Source/src/freeocl.h:71:2: >> error: 'u_int64_t' does not name a type >> *** [src/CMakeFiles/FreeOCL.dir/freeocl.cpp.o] Error code 1 >> [...] >> >> I think patches are required. >> >> More disturbing is the use of gcc-4.6 via >> >> USE_GCC= 4.6+ >> >> The error is then a compalin about a missing include file >> >> atomic_ops.h >> >> which is located in the abandoned KSE facility of the kernel, so the >> includes seem not to be installed anymore - but since I'm not involved >> in the development, I can only guess and ask the people here. >> >> Maybe some experienced freeBSD developers with the same need for OpenCl >> is willing to pick up this and help a bit. >> >> Well, as far as I see, the FreeOCL project of Roland Borchard is a >> OpenCL library for CPU usage. As far as I can understand, if we on >> FreeBSd could have a library "libOpenCL" as this is usually installed by >> the nVidia BLOB drivers on Linux for the use of OpenCL/GPGPU support >> with their GPUs, this would fill a still painfull open gap in FreeBSD as >> a scientific development platform. >> >> There is still no suitable compiler for OpenCL out here for freeBSD, but >> I have still the hope that LLVM can provide such a thing in the near future. >> >> I cross post this posting also to "performance" in the hope finding some >> people attracted and "lurd" into this subject. >> >> Regards, >> >> O. Hartmann > > Hello, > > I've taken a quick look in that implementation : it seems to depends on > devel/libatomic_ops even if the devs did not write any CMake checks for that > (grrr). > > After installing it, I was able to build the port with gcc-46 without > problems, if I find some time, I will try to test it later. > > Btw, did you had a look to poCL too > (http://sourceforge.net/apps/mediawiki/pocl/index.php?title=Main_Page)? I > know the Debian people were considering it for a base implementation, but I'm > a bit clueless about all those foss versions coming. A comparison could be > helpful ^^ > Hello Matthieu. Thanks for the hint for that port. I will have a look at poCL. Thanks for that hint. I cross post to "current", maybe those aspects have influence of some add ons in CURRENT in the future. Oliver signature.asc Description: OpenPGP digital signature
Re: Help. Porting "FreeOCL" fails (atomic_ops.h missing, CLANG++ libc++ issues ...)
On Wed, 05 Sep 2012 16:45:49 +0200 "O. Hartmann" wrote: > Hello. > > FreeBSD has fallen back far behind the standards of modern scientific > computing and I dsperately look for solutions having OpenCL support on > FreeBSD anyway. > > I stumbled into this project recently: > > FreeOCL at > http://code.google.com/p/freeocl/ > > or the sources located at > > http://code.google.com/p/freeocl/downloads/detail?name=FreeOCL-0.3.6-src.tar.gz&can=2&q= > > For your convenience, please find my naive attempt of a port attached to > this email. > > Well, I tried LLVM/CLANG, but Cmake of the sources fairly fails many > checks especuially for OpenMP. Using clang++ requisites the usage of the > new libc++ (CXXFLAGS+= -stdlib=libc++). But this fails with this error: > > > [...] > [ 17%] Building CXX object src/CMakeFiles/FreeOCL.dir/codebuilder.cpp.o > In file included from > /usr/ports/devel/freeocl/work/FreeOCL-0.3.6-Source/src/codebuilder.cpp:26: > /usr/ports/devel/freeocl/work/FreeOCL-0.3.6-Source/src/parser/parser.h:118:15: > error: no viable conversion from 'std::__1::basic_istream' to > 'const bool' > const bool ok = in.get(c); >^~ > /usr/ports/devel/freeocl/work/FreeOCL-0.3.6-Source/src/codebuilder.cpp:444:13: > warning: 70 enumeration values not handled in switch: 'VOID', 'BOOL', > 'HALF'... [-Wswitch] > switch(native->get_type_id()) >^ > 1 warning and 1 error generated. > *** [src/CMakeFiles/FreeOCL.dir/codebuilder.cpp.o] Error code 1 > [..] > > > I tried also setting USE_GCC= 4.7+ using gcc-4.7 I installed, but that > fails with > > [...] > -- Build files have been written to: > /usr/ports/devel/freeocl/work/FreeOCL-0.3.6-Source > ===> Building for freeocl-0.3.6 > Scanning dependencies of target FreeOCL > [ 1%] Building CXX object src/CMakeFiles/FreeOCL.dir/freeocl.cpp.o > In file included from > /usr/ports/devel/freeocl/work/FreeOCL-0.3.6-Source/src/freeocl.cpp:18:0: > /usr/ports/devel/freeocl/work/FreeOCL-0.3.6-Source/src/freeocl.h:71:2: > error: 'u_int64_t' does not name a type > *** [src/CMakeFiles/FreeOCL.dir/freeocl.cpp.o] Error code 1 > [...] > > I think patches are required. > > More disturbing is the use of gcc-4.6 via > > USE_GCC= 4.6+ > > The error is then a compalin about a missing include file > > atomic_ops.h > > which is located in the abandoned KSE facility of the kernel, so the > includes seem not to be installed anymore - but since I'm not involved > in the development, I can only guess and ask the people here. > > Maybe some experienced freeBSD developers with the same need for OpenCl > is willing to pick up this and help a bit. > > Well, as far as I see, the FreeOCL project of Roland Borchard is a > OpenCL library for CPU usage. As far as I can understand, if we on > FreeBSd could have a library "libOpenCL" as this is usually installed by > the nVidia BLOB drivers on Linux for the use of OpenCL/GPGPU support > with their GPUs, this would fill a still painfull open gap in FreeBSD as > a scientific development platform. > > There is still no suitable compiler for OpenCL out here for freeBSD, but > I have still the hope that LLVM can provide such a thing in the near future. > > I cross post this posting also to "performance" in the hope finding some > people attracted and "lurd" into this subject. > > Regards, > > O. Hartmann Hello, I've taken a quick look in that implementation : it seems to depends on devel/libatomic_ops even if the devs did not write any CMake checks for that (grrr). After installing it, I was able to build the port with gcc-46 without problems, if I find some time, I will try to test it later. Btw, did you had a look to poCL too (http://sourceforge.net/apps/mediawiki/pocl/index.php?title=Main_Page)? I know the Debian people were considering it for a base implementation, but I'm a bit clueless about all those foss versions coming. A comparison could be helpful ^^ -- Matthieu Volat ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Building with WITH_DEBUG (-g) in make.conf
On 2012-Sep-04 23:50:35 +0200, Dimitry Andric wrote: >There's a difference between just using '-g', which should never change >the behaviour of the program at runtime, and adding -DDEBUG or similar >flags on the command line, which may or may not enable extra code, or >even cause totally different code paths. In theory, gcc should generate identical code with and without '-g' but, last time I looked, adding '-g' causes non-trivial changes in the gcc code paths so it's quite possible that different code is emitted. >What is not different, is that both -g and other debugging options will >generally cause compiling and linking to take longer, since these stages >will have to process the additional debug information. As well as being much larger - several times larger is not uncommon. This further slows things down due to the additional I/O and reduced cache effectiveness. -- Peter Jeremy pgphfUYAq2ZgX.pgp Description: PGP signature
