Re: platforms

[Ryan Schmidt]

On Mar 24, 2018, at 08:14, Mojca Miklavec wrote:

>> I propose that the 'platforms' field be no longer required
>> if it is ignored, and if it stays, let it be a free form text,
>> as opposed to a predefined definitive list of all unixes.
> 
> We'll need it to specify which darwin versions are supported.
> 
> We currently have this ticket high on our priority list:
>https://trac.macports.org/ticket/15712

Sure, it is one suggestion for how we could implement that feature, but it 
could be done in other ways.

Re: LibreSSL 2.7.1 Released

[Ryan Schmidt]

On Mar 24, 2018, at 04:49, Jan Stary wrote:

> what is the plan really with libressl and libressl-devel?
> We have 2.5.5 in security/libressl, 2.6.2 in security/libressl-devel,
> and now 2.7.1 is out.
> 
> I would just prepare an udate of libressl to 2.7.1,
> but I want to as kfirst: why do we have "devel".
> LibreSSL themselves make no such distinction,
> these are just "releases".

I've answered that question before...

https://lists.macports.org/pipermail/macports-dev/2018-January/037191.html

Re: How to resolve libstdc++.6.dylib dependency

[Ryan Schmidt]

On Mar 24, 2018, at 07:35, Andreas Falkenhahn wrote:

> When I compile my C++11 project on a 10.5 PPC system using gcc6 and try to 
> run it on another 10.5 PPC system that doesn't have gcc6 installed, I get an 
> error that a symbol cannot be imported from /usr/lib/libstdc++.6.dylib. I 
> guess this is because the libstdc++.6.dylib that is shipped with 10.5 doesn't 
> contain those new features required by C++11 programs.
> 
> So what is the recommended way of getting the libstdc++.6.dylib required by 
> my program onto a user system? Of course I wouldn't like to bother users to 
> install gcc6 from Mac Ports just to be able to run my program. Is there an 
> easier way? Is the latest libstdc++ available as its own package in Mac Ports 
> maybe or what is the suggested way of dealing with this?


/usr/lib/libstdc++.6.dylib does not support C++11, on any version of macOS. It 
is based on GCC 4.2.1.

MacPorts provides an updated libstdc++.6.dylib which does support C++11. It is 
based on GCC 7.3.0 at present and is updated when newer stable versions of GCC 
are released. It is in the libgcc port.

You must either statically link with a newer libstdc++.6.dylib, such as ours, 
which supports C++11, or you must bundle it and dynamically link with it. 
Dynamic linking is usually preferred on macOS.

If all of your C++ libraries and programs link with a newer C++11 copy of 
libstdc++.6.dylib, then that's fine. If some of your C++ libraries and programs 
link with a newer C++11 copy of libstdc++.6.dylib and other libraries and 
programs link with the non-C++11-supporting OS-provided copy of 
libstdc++.6.dylib, and you want to share information between them, then you 
must use -D_GLIBCXX_USE_CXX11_ABI=0 to build the parts that use the newer 
C++11-capable libstdc++.6.dylib, as Mojca said.

Needless to say, this is an advanced topic. It's simpler to link with 
/usr/lib/libc++.1.dylib, which supports C++11, but is only available on OS X 
10.7 and newer.

Re: How to resolve libstdc++.6.dylib dependency

[Andreas Falkenhahn]

On 24.03.2018 at 17:34 Mojca Miklavec wrote:

> Sorry about the wrong advice about stdlib. 

No worries, I've had another idea. I can just link statically
against libgcc and libstdc++, like so:

-static-libgcc -static-libstdc++

This increases the executable size by about 1 MB but the
resulting executable works like a charm on a naked 10.5
system without any Mac Ports stuff... very nice!

-- 
Best regards,
 Andreas Falkenhahnmailto:andr...@falkenhahn.com

Re: How to resolve libstdc++.6.dylib dependency

[Mojca Miklavec]

On 24 March 2018 at 16:40, Andreas Falkenhahn wrote:
> On 24.03.2018 at 16:07 Ken Cunningham wrote:
>
>> Cameron Kaiser builds and distributes TenFourFox which is a c++11
>> app built with gcc48 against a new libstdc++.
>> He has worked a lot of this out.
>> His instructions are here
>> ,
>> and there's a script in the repo that automates a lot of it.
>
> Yeah, so basically he's just shipping the new link libs with the
> distribution which is of course something I wanted to avoid.
>
> Well, maybe I should just tell my users that they need to
> install gcc6 from Mac Ports if they wish to use the program.
> People who are still on PPC Macs are geeks anyway ;)

In that case, depending on usability, you could probably provide a
MacPorts package as well.

Sorry about the wrong advice about stdlib. Maybe that technique just
ensures the compatibility, so that the libraries linked against each
other won't clash and crash if one is linking against the system lib
and the other against the one from gcc7.

Mojca

Re: How to resolve libstdc++.6.dylib dependency

[Andreas Falkenhahn]

On 24.03.2018 at 14:07 Mojca Miklavec wrote:

> On 24 March 2018 at 13:35, Andreas Falkenhahn wrote:
>> When I compile my C++11 project on a 10.5 PPC system using gcc6 and try to 
>> run it on another 10.5 PPC system that doesn't have gcc6 installed, I get an 
>> error that a symbol cannot be imported from /usr/lib/libstdc++.6.dylib. I 
>> guess this is because the libstdc++.6.dylib that is shipped with 10.5 
>> doesn't contain those new features required by C++11 programs.

>> So what is the recommended way of getting the libstdc++.6.dylib required by 
>> my program onto a user system? Of course I wouldn't like to bother users to 
>> install gcc6 from Mac Ports just to be able to run my program. Is there an 
>> easier way? Is the latest libstdc++ available as its own package in Mac 
>> Ports maybe or what is the suggested way of dealing with this?

> You need to compile with ABI 4 compatibility (add
> "-D_GLIBCXX_USE_CXX11_ABI=0" to CXXFLAGS) and then relink them to
> /usr/lib/libstdc++.6.dylib with install_name_tool.

> The first step might soon no longer be required (see
> https://github.com/macports/macports-ports/pull/1469), but you'll
> probably need to keep running install_name_tool on the resulting
> libraries/binaries, I assume that your binaries link against
> /opt/local/lib/libstdc++.6.dylib rather than
> /usr/lib/libstdc++.*.dylib

Yes, it does. Unfortunately, compiling with -D_GLIBCXX_USE_CXX11_ABI=0 and
then changing /opt/local/lib/libstdc++.6.dylib to /usr/lib/libstdc++.6.dylib
using install_name_tool doesn't work. It still can't find some symbols.
Here's the error I get when trying to dlopen() my project:

dyld: lazy symbol binding failed: Symbol not found: 
__ZSt16__ostream_insertIcSt11char_traitsIcEERSt13basic_ostreamIT_T0_ES6_PKS3_i
  Referenced from: test.dylib
  Expected in: /usr/lib/libstdc++.6.dylib

dyld: Symbol not found: 
__ZSt16__ostream_insertIcSt11char_traitsIcEERSt13basic_ostreamIT_T0_ES6_PKS3_i
  Referenced from: test.dylib
  Expected in: /usr/lib/libstdc++.6.dylib

-- 
Best regards,
 Andreas Falkenhahnmailto:andr...@falkenhahn.com

Re: LibreSSL 2.7.1 Released

[Ken Cunningham]

see 

> On Mar 24, 2018, at 03:49, Jan Stary  wrote:
> 
> Hi Jeremy,
> 
> what is the plan really with libressl and libressl-devel?
> We have 2.5.5 in security/libressl, 2.6.2 in security/libressl-devel,
> and now 2.7.1 is out.
> 
> I would just prepare an udate of libressl to 2.7.1,
> but I want to as kfirst: why do we have "devel".
> LibreSSL themselves make no such distinction,
> these are just "releases".
> 
>Jan
> 
> 
> PS: specific MacOS fixes here
> 
>> On Mar 23 20:17:39, bust...@gmail.com wrote:
>> We have released LibreSSL 2.7.1, which will be arriving in the
>> LibreSSL directory of your local OpenBSD mirror soon. This is the second
>> release from the 2.7 series, which will be part of OpenBSD 6.3.
>> 
>> It includes the following changes from 2.7.0
>> 
>> * Fixed a bug in int_x509_param_set_hosts, calling strlen() if name
>>   length provided is 0 to match the OpenSSL behaviour. Issue noticed
>>   by Christian Heimes 
>> 
>> * Fixed builds macOS 10.11 and older.
>> 
>> LibreSSL 2.7.1 also includes:
>> 
>> * Added support for many OpenSSL 1.0.2 and 1.1 APIs, based on
>>   observations of real-world usage in applications. These are
>>   implemented in parallel with existing OpenSSL 1.0.1 APIs - visibility
>>   changes have not been made to existing structs, allowing code written
>>   for older OpenSSL APIs to continue working.
>> 
>> * Extensive corrections, improvements, and additions to the
>>   API documentation, including new public APIs from OpenSSL that had
>>   no pre-existing documentation.
>> 
>> * Added support for automatic library initialization in libcrypto,
>>   libssl, and libtls. Support for pthread_once or a compatible
>>   equivalent is now required of the target operating system. As a
>>   side-effect, minimum Windows support is Vista or higher.
>> 
>> * Converted more packet handling methods to CBB, which improves
>>   resiliency when generating TLS messages.
>> 
>> * Completed TLS extension handling rewrite, improving consistency of
>>   checks for malformed and duplicate extensions.
>> 
>> * Rewrote ASN1_TYPE_{get,set}_octetstring() using templated ASN.1.
>>   This removes the last remaining use of the old M_ASN1_* macros
>>   (asn1_mac.h) from API that needs to continue to exist.
>> 
>> * Added support for client-side session resumption in libtls.
>>   A libtls client can specify a session file descriptor (a regular
>>   file with appropriate ownership and permissions) and libtls will
>>   manage reading and writing of session data across TLS handshakes.
>> 
>> * Improved support for strict alignment on ARMv7 architectures,
>>   conditionally enabling assembly in those cases.
>> 
>> * Fixed a memory leak in libtls when reusing a tls_config.
>> 
>> * Merged more DTLS support into the regular TLS code path, removing
>>   duplicated code.
>> 
>> * Many improvements to Windows Cmake-based builds and tests,
>>   especially when targeting Visual Studio.
>> 
>> Thanks for all of the testing, suggestions, and updates from the porting
>> community. We look forward to releasing a final stable version in a few
>> weeks.
>> 
>> The LibreSSL project continues improvement of the codebase to reflect modern,
>> safe programming practices. We welcome feedback and improvements from the
>> broader community. Thanks to all of the contributors who helped make this
>> release possible.
>> 

Re: How to resolve libstdc++.6.dylib dependency

[Ken Cunningham]

Cameron Kaiser builds and distributes TenFourFox which is a c++11 app built 
with gcc48 against a new libstdc++. 

He has worked a lot of this out.

His instructions are here 
,
 and there's a script in the repo that automates a lot of it.

Best, Ken

> On Mar 24, 2018, at 06:35, Andreas Falkenhahn  wrote:
> 
> When I compile my C++11 project on a 10.5 PPC system using gcc6 and try to 
> run it on another 10.5 PPC system that doesn't have gcc6 installed, I get an 
> error that a symbol cannot be imported from /usr/lib/libstdc++.6.dylib. I 
> guess this is because the libstdc++.6.dylib that is shipped with 10.5 doesn't 
> contain those new features required by C++11 programs.
> 
> So what is the recommended way of getting the libstdc++.6.dylib required by 
> my program onto a user system? Of course I wouldn't like to bother users to 
> install gcc6 from Mac Ports just to be able to run my program. Is there an 
> easier way? Is the latest libstdc++ available as its own package in Mac Ports 
> maybe or what is the suggested way of dealing with this?
> 
> -- 
> Best regards,
> Andreas Falkenhahn  mailto:andr...@falkenhahn.com
> 

Re: platforms

[Mojca Miklavec]

On 24 March 2018 at 13:54, Jan Starý wrote:
> The 'platforms' field of a Portfile is currently
> both _required_ and _ignored_. By the Guide,
>
> A list of the platforms on which the port has been tested.
> Required, but not interpreted in any way by the software
> at this time; it is purely informational for users.

I don't know anything about this, but it's possible that this could be
interpreted already, or maybe soon in the future.

> Also, it is allowed to say .e.g. "freebsd" but not e.g. "openbsd".

Personally I don't see any reason for not allowing "openbsd" (other
than the fact that only two ports will have that keyword, so it will
probably be useless at the end).

> I propose that the 'platforms' field be no longer required
> if it is ignored, and if it stays, let it be a free form text,
> as opposed to a predefined definitive list of all unixes.

We'll need it to specify which darwin versions are supported.

We currently have this ticket high on our priority list:
https://trac.macports.org/ticket/15712

> Better yet, drop it altogether. The fact that I tested on Solaris
> or Debian means nothing regarding the MP port. I have also tested
> it on darwin of course, but that goes without saying.
>
> (What would be kinda useful is if it pointed to the actual _ports_
> on the other systems - often there are things we can learn, as they
> battle a lot of the same GNUisms etc. For example, the patch for opus
> https://github.com/macports/macports-ports/pull/1217 is basically
> the OpenBSD patch for opus. So if opus 'platforms' pointed to
> http://cvsweb.openbsd.org/cgi-bin/cvsweb/ports/audio/opus/
> it would be usefull. Unlike now.)

You could (should?) provide such pointers in comments.
I always include sources of patches (or links to upstream tickets) if
I get them elsewhere, either in Portfile or in the patch itself.

Mojca

Re: How to resolve libstdc++.6.dylib dependency

[Mojca Miklavec]

On 24 March 2018 at 13:35, Andreas Falkenhahn wrote:
> When I compile my C++11 project on a 10.5 PPC system using gcc6 and try to 
> run it on another 10.5 PPC system that doesn't have gcc6 installed, I get an 
> error that a symbol cannot be imported from /usr/lib/libstdc++.6.dylib. I 
> guess this is because the libstdc++.6.dylib that is shipped with 10.5 doesn't 
> contain those new features required by C++11 programs.
>
> So what is the recommended way of getting the libstdc++.6.dylib required by 
> my program onto a user system? Of course I wouldn't like to bother users to 
> install gcc6 from Mac Ports just to be able to run my program. Is there an 
> easier way? Is the latest libstdc++ available as its own package in Mac Ports 
> maybe or what is the suggested way of dealing with this?

You need to compile with ABI 4 compatibility (add
"-D_GLIBCXX_USE_CXX11_ABI=0" to CXXFLAGS) and then relink them to
/usr/lib/libstdc++.6.dylib with install_name_tool.

The first step might soon no longer be required (see
https://github.com/macports/macports-ports/pull/1469), but you'll
probably need to keep running install_name_tool on the resulting
libraries/binaries, I assume that your binaries link against
/opt/local/lib/libstdc++.6.dylib rather than
/usr/lib/libstdc++.*.dylib

Mojca

Re: How to resolve libstdc++.6.dylib dependency

[pagani laurent via macports-users]

I don’t know much about these libraries but there exists a libstdc++.a library. 
No idea if it is different in content from the .6 one but if not, you could do 
a static link so that you don’t need any library for the users to run your 
program. Not sure it helps. The other solution is to try to find or build the 
libstdc++.6.a library yourself and perform a static link.

Laurent

> Le 24 mars 2018 à 13:35, Andreas Falkenhahn  a écrit :
> 
> When I compile my C++11 project on a 10.5 PPC system using gcc6 and try to 
> run it on another 10.5 PPC system that doesn't have gcc6 installed, I get an 
> error that a symbol cannot be imported from /usr/lib/libstdc++.6.dylib. I 
> guess this is because the libstdc++.6.dylib that is shipped with 10.5 doesn't 
> contain those new features required by C++11 programs.
> 
> So what is the recommended way of getting the libstdc++.6.dylib required by 
> my program onto a user system? Of course I wouldn't like to bother users to 
> install gcc6 from Mac Ports just to be able to run my program. Is there an 
> easier way? Is the latest libstdc++ available as its own package in Mac Ports 
> maybe or what is the suggested way of dealing with this?
> 
> -- 
> Best regards,
> Andreas Falkenhahn  mailto:andr...@falkenhahn.com
> 

"S'il n'y a pas de solution, c'est qu'il n'y a pas de problème" (devise Shadok)

platforms

[Jan Starý]

The 'platforms' field of a Portfile is currently
both _required_ and _ignored_. By the Guide,

A list of the platforms on which the port has been tested.
Required, but not interpreted in any way by the software
at this time; it is purely informational for users.

Also, it is allowed to say .e.g. "freebsd" but not e.g. "openbsd".

I propose that the 'platforms' field be no longer required
if it is ignored, and if it stays, let it be a free form text,
as opposed to a predefined definitive list of all unixes.

Better yet, drop it altogether. The fact that I tested on Solaris
or Debian means nothing regarding the MP port. I have also tested
it on darwin of course, but that goes without saying.

(What would be kinda useful is if it pointed to the actual _ports_
on the other systems - often there are things we can learn, as they
battle a lot of the same GNUisms etc. For example, the patch for opus
https://github.com/macports/macports-ports/pull/1217 is basically
the OpenBSD patch for opus. So if opus 'platforms' pointed to
http://cvsweb.openbsd.org/cgi-bin/cvsweb/ports/audio/opus/
it would be usefull. Unlike now.)

Jan

How to resolve libstdc++.6.dylib dependency

[Andreas Falkenhahn]

When I compile my C++11 project on a 10.5 PPC system using gcc6 and try to run 
it on another 10.5 PPC system that doesn't have gcc6 installed, I get an error 
that a symbol cannot be imported from /usr/lib/libstdc++.6.dylib. I guess this 
is because the libstdc++.6.dylib that is shipped with 10.5 doesn't contain 
those new features required by C++11 programs.

So what is the recommended way of getting the libstdc++.6.dylib required by my 
program onto a user system? Of course I wouldn't like to bother users to 
install gcc6 from Mac Ports just to be able to run my program. Is there an 
easier way? Is the latest libstdc++ available as its own package in Mac Ports 
maybe or what is the suggested way of dealing with this?

-- 
Best regards,
 Andreas Falkenhahn  mailto:andr...@falkenhahn.com

Re: LibreSSL 2.7.1 Released

[Jan Stary]

Hi Jeremy,

what is the plan really with libressl and libressl-devel?
We have 2.5.5 in security/libressl, 2.6.2 in security/libressl-devel,
and now 2.7.1 is out.

I would just prepare an udate of libressl to 2.7.1,
but I want to as kfirst: why do we have "devel".
LibreSSL themselves make no such distinction,
these are just "releases".

Jan


PS: specific MacOS fixes here

On Mar 23 20:17:39, bust...@gmail.com wrote:
> We have released LibreSSL 2.7.1, which will be arriving in the
> LibreSSL directory of your local OpenBSD mirror soon. This is the second
> release from the 2.7 series, which will be part of OpenBSD 6.3.
> 
> It includes the following changes from 2.7.0
> 
>  * Fixed a bug in int_x509_param_set_hosts, calling strlen() if name
>length provided is 0 to match the OpenSSL behaviour. Issue noticed
>by Christian Heimes 
> 
>  * Fixed builds macOS 10.11 and older.
> 
> LibreSSL 2.7.1 also includes:
> 
>  * Added support for many OpenSSL 1.0.2 and 1.1 APIs, based on
>observations of real-world usage in applications. These are
>implemented in parallel with existing OpenSSL 1.0.1 APIs - visibility
>changes have not been made to existing structs, allowing code written
>for older OpenSSL APIs to continue working.
> 
>  * Extensive corrections, improvements, and additions to the
>API documentation, including new public APIs from OpenSSL that had
>no pre-existing documentation.
> 
>  * Added support for automatic library initialization in libcrypto,
>libssl, and libtls. Support for pthread_once or a compatible
>equivalent is now required of the target operating system. As a
>side-effect, minimum Windows support is Vista or higher.
> 
>  * Converted more packet handling methods to CBB, which improves
>resiliency when generating TLS messages.
> 
>  * Completed TLS extension handling rewrite, improving consistency of
>checks for malformed and duplicate extensions.
> 
>  * Rewrote ASN1_TYPE_{get,set}_octetstring() using templated ASN.1.
>This removes the last remaining use of the old M_ASN1_* macros
>(asn1_mac.h) from API that needs to continue to exist.
> 
>  * Added support for client-side session resumption in libtls.
>A libtls client can specify a session file descriptor (a regular
>file with appropriate ownership and permissions) and libtls will
>manage reading and writing of session data across TLS handshakes.
> 
>  * Improved support for strict alignment on ARMv7 architectures,
>conditionally enabling assembly in those cases.
> 
>  * Fixed a memory leak in libtls when reusing a tls_config.
> 
>  * Merged more DTLS support into the regular TLS code path, removing
>duplicated code.
> 
>  * Many improvements to Windows Cmake-based builds and tests,
>especially when targeting Visual Studio.
> 
> Thanks for all of the testing, suggestions, and updates from the porting
> community. We look forward to releasing a final stable version in a few
> weeks.
> 
> The LibreSSL project continues improvement of the codebase to reflect modern,
> safe programming practices. We welcome feedback and improvements from the
> broader community. Thanks to all of the contributors who helped make this
> release possible.
>