new misc/open62541

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

new misc/open62541

Alexander Bluhm
Hi,

I would like to import a new library for the industrial network
protocol OPC UA.

ok?

Comment:
library implementation of OPC UA

Description:
open62541 is an open source and free implementation of OPC UA (OPC
Unified Architecture) written in the common subset of the C99 and
C++98 languages.  The library is usable with all major compilers
and provides the necessary tools to implement dedicated OPC UA
clients and servers, or to integrate OPC UA-based communication
into existing applications.

Maintainer: Alexander Bluhm <[hidden email]>

WWW: https://open62541.org/

bluhm

open62541.tgz (4K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: new misc/open62541

Alexander Bluhm
On Wed, Feb 05, 2020 at 12:32:45AM +0100, Alexander Bluhm wrote:
> Hi,
>
> I would like to import a new library for the industrial network
> protocol OPC UA.
>
> ok?

Anyone?

>
> Comment:
> library implementation of OPC UA
>
> Description:
> open62541 is an open source and free implementation of OPC UA (OPC
> Unified Architecture) written in the common subset of the C99 and
> C++98 languages.  The library is usable with all major compilers
> and provides the necessary tools to implement dedicated OPC UA
> clients and servers, or to integrate OPC UA-based communication
> into existing applications.
>
> Maintainer: Alexander Bluhm <[hidden email]>
>
> WWW: https://open62541.org/
>
> bluhm


Reply | Threaded
Open this post in threaded view
|

Re: new misc/open62541

Stuart Henderson
In reply to this post by Alexander Bluhm
On 2020/02/05 00:32, Alexander Bluhm wrote:

> Hi,
>
> I would like to import a new library for the industrial network
> protocol OPC UA.
>
> ok?
>
> Comment:
> library implementation of OPC UA
>
> Description:
> open62541 is an open source and free implementation of OPC UA (OPC
> Unified Architecture) written in the common subset of the C99 and
> C++98 languages.  The library is usable with all major compilers
> and provides the necessary tools to implement dedicated OPC UA
> clients and servers, or to integrate OPC UA-based communication
> into existing applications.
>
> Maintainer: Alexander Bluhm <[hidden email]>
>
> WWW: https://open62541.org/
>
> bluhm


Maybe worth @comment'ing the empty share/doc/open62541/open62541.html/
directory?

Is there a reason to use share/open62541/examples rather than the standard
i.e. share/examples/open62541?

I don't think it's worth bytecode-compiling the tools. The main benefit of
bytecode-compiling is to stop new pyc files from being created at runtime
(iff the tools are run by a user with write access to the directory).
But these are tied to the python version; since there's no executable
in bin/ the user has to choose themselves whether to run them with python2
or python3, and if they pick "the other one" than the port was built with,
it will still create pyc files. And ports isn't setup to allow bytecode-
compiling with both py2+py3.

Reply | Threaded
Open this post in threaded view
|

Re: new misc/open62541

Alexander Bluhm
On Mon, Feb 10, 2020 at 12:58:49PM +0000, Stuart Henderson wrote:
> Maybe worth @comment'ing the empty share/doc/open62541/open62541.html/
> directory?

Yes.  I do not want to build the html documentation as it adds so
many files to the package.  It can be read online anyway.

Having a pdf in the package is useful for offline developent.  For
that I had to add some missing build dependencies to print/texlive/texmf.

I guess splitting a -doc sub package is not worth it.

> Is there a reason to use share/open62541/examples rather than the standard
> i.e. share/examples/open62541?

I was to lazy to patch it :-)  Fixed.

> I don't think it's worth bytecode-compiling the tools.

Makes sense.  portcheck suggested to do it, but your arguments are
better.

I have build the library with debug symbols as I want to do development
on top of it.  Do we have a policy for that?

New port attached.

bluhm

open62541.tgz (4K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: new misc/open62541

Stuart Henderson
On 2020/02/10 17:31, Alexander Bluhm wrote:

> On Mon, Feb 10, 2020 at 12:58:49PM +0000, Stuart Henderson wrote:
> > Maybe worth @comment'ing the empty share/doc/open62541/open62541.html/
> > directory?
>
> Yes.  I do not want to build the html documentation as it adds so
> many files to the package.  It can be read online anyway.
>
> Having a pdf in the package is useful for offline developent.  For
> that I had to add some missing build dependencies to print/texlive/texmf.
>
> I guess splitting a -doc sub package is not worth it.
>
> > Is there a reason to use share/open62541/examples rather than the standard
> > i.e. share/examples/open62541?
>
> I was to lazy to patch it :-)  Fixed.
>
> > I don't think it's worth bytecode-compiling the tools.
>
> Makes sense.  portcheck suggested to do it, but your arguments are
> better.
>
> I have build the library with debug symbols as I want to do development
> on top of it.  Do we have a policy for that?

If you only need symbols on amd64 then I'd prefer just setting
DEBUG_PACKAGES=${BUILD_PACKAGES}, which will automatically split into
open62541 and debug-open62541 packages with detached symbols in the latter.

If you would like them on other arches too then
-DCMAKE_BUILD_TYPE=RelWithDebInfo makes sense.

> New port attached.

OK.

> bluhm


Reply | Threaded
Open this post in threaded view
|

misc/open62541 debug package

Alexander Bluhm
On Mon, Feb 10, 2020 at 08:46:47PM +0000, Stuart Henderson wrote:
> > I have build the library with debug symbols as I want to do development
> > on top of it.  Do we have a policy for that?
>
> If you only need symbols on amd64 then I'd prefer just setting
> DEBUG_PACKAGES=${BUILD_PACKAGES}, which will automatically split into
> open62541 and debug-open62541 packages with detached symbols in the latter.
>
> If you would like them on other arches too then
> -DCMAKE_BUILD_TYPE=RelWithDebInfo makes sense.

The debug feature works.  It helped to track down a double free in
the library.  I think the -DCMAKE_BUILD_TYPE=RelWithDebInfo is still
necessary to build the library, the debug symbols are just stripped
later.

ok?

bluhm

Index: misc/open62541/Makefile
===================================================================
RCS file: /data/mirror/openbsd/cvs/ports/misc/open62541/Makefile,v
retrieving revision 1.1.1.1
diff -u -p -r1.1.1.1 Makefile
--- misc/open62541/Makefile 11 Feb 2020 10:35:25 -0000 1.1.1.1
+++ misc/open62541/Makefile 11 Feb 2020 15:22:05 -0000
@@ -3,6 +3,7 @@
 COMMENT = library implementation of OPC UA

 VERSION = 1.0.1
+REVISION = 0
 PKGNAME = open62541-${VERSION}

 GH_ACCOUNT = open62541
@@ -43,6 +44,8 @@ CONFIGURE_ARGS = -DCMAKE_BUILD_TYPE=RelW
  -DUA_PACK_DEBIAN=ON \
  -DUA_BUILD_TOOLS=ON \
  -DUA_BUILD_UNIT_TESTS=ON
+
+DEBUG_PACKAGES = ${BUILD_PACKAGES}

 WRKDIST = ${WRKDIR}/${GH_PROJECT}-${GH_TAGNAME}

Index: misc/open62541/patches/patch-plugins_ua_accesscontrol_default_c
===================================================================
RCS file: misc/open62541/patches/patch-plugins_ua_accesscontrol_default_c
diff -N misc/open62541/patches/patch-plugins_ua_accesscontrol_default_c
--- /dev/null 1 Jan 1970 00:00:00 -0000
+++ misc/open62541/patches/patch-plugins_ua_accesscontrol_default_c 12 Feb 2020 22:27:18 -0000
@@ -0,0 +1,15 @@
+$OpenBSD$
+
+https://github.com/open62541/open62541/commit/f05bafc25d332d4571b2e42fb42221c2ec3cc98c
+
+Index: plugins/ua_accesscontrol_default.c
+--- plugins/ua_accesscontrol_default.c.orig
++++ plugins/ua_accesscontrol_default.c
+@@ -210,6 +210,7 @@ static void deleteMembers_default(UA_AccessControl *ac
+         if(context->usernamePasswordLoginSize > 0)
+             UA_free(context->usernamePasswordLogin);
+         UA_free(ac->context);
++        ac->context = NULL;
+     }
+ }
+

Reply | Threaded
Open this post in threaded view
|

Re: misc/open62541 debug package

Stuart Henderson
On 2020/02/13 13:01, Alexander Bluhm wrote:

> On Mon, Feb 10, 2020 at 08:46:47PM +0000, Stuart Henderson wrote:
> > > I have build the library with debug symbols as I want to do development
> > > on top of it.  Do we have a policy for that?
> >
> > If you only need symbols on amd64 then I'd prefer just setting
> > DEBUG_PACKAGES=${BUILD_PACKAGES}, which will automatically split into
> > open62541 and debug-open62541 packages with detached symbols in the latter.
> >
> > If you would like them on other arches too then
> > -DCMAKE_BUILD_TYPE=RelWithDebInfo makes sense.
>
> The debug feature works.  It helped to track down a double free in
> the library.  I think the -DCMAKE_BUILD_TYPE=RelWithDebInfo is still
> necessary to build the library, the debug symbols are just stripped
> later.
>
> ok?

OK, though I hope we will be able to remove -DCMAKE_BUILD_TYPE later.
I think this should be fixed in the cmake port and/or cmake.port.mk
somewhere, looks like it strips libraries but not executables.
I don't think we can set RelWithDebInfo in the general case because it
changes the name of installed .cmake files, but that's not a problem
with open62541.

Reply | Threaded
Open this post in threaded view
|

Re: misc/open62541 debug package

Alexander Bluhm
On Thu, Feb 13, 2020 at 12:39:50PM +0000, Stuart Henderson wrote:
> OK, though I hope we will be able to remove -DCMAKE_BUILD_TYPE later.
> I think this should be fixed in the cmake port and/or cmake.port.mk
> somewhere, looks like it strips libraries but not executables.
> I don't think we can set RelWithDebInfo in the general case because it
> changes the name of installed .cmake files, but that's not a problem
> with open62541.

Without -DCMAKE_BUILD_TYPE the PLIST looks nicer.

-lib/cmake/open62541/open62541Targets-relwithdebinfo.cmake
+lib/cmake/open62541/open62541Targets${MODCMAKE_BUILD_SUFFIX}
 lib/cmake/open62541/open62541Targets.cmake

But the debug library is missing the debug symbols.

-rw-r--r--  1 root  bin  546736 Feb 13 14:37 /usr/local/lib/.debug/libopen62541.so.0.0.dbg
-rw-r--r--  1 root  bin  581392 Feb 13 14:37 /usr/local/lib/libopen62541.so.0.0

So egdb stack trace does not work:

#0  0x00001f0b50862e0e in ?? () from /usr/local/lib/libopen62541.so.0.0
#1  0x00001f0b50862dc4 in UA_clear () from /usr/local/lib/libopen62541.so.0.0
#2  0x00001f0b508b6570 in ?? () from /usr/local/lib/libopen62541.so.0.0
#3  0x00001f0b50874240 in UA_ServerConfig_clean ()

When built with -DCMAKE_BUILD_TYPE the debug library is much bigger
and the stack trace contains all relevant information.

-rw-r--r--  1 root  bin  2080333 Feb 12 23:29 /usr/local/lib/.debug/libopen62541.so.0.0.dbg
-rw-r--r--  1 root  bin   594512 Feb 12 23:29 /usr/local/lib/libopen62541.so.0.0

So somebody has to fix something :-)

bluhm