On Jul 17, 2014, at 1:39 PM, Jan Engelhardt wrote:
>
> On Thursday 2014-07-17 00:02, Jonas 'Sortie' Termansen wrote:
>>
>> * The build system defaults --program-transform-name to the host triplet
>> when cross-compiling. It shouldn't do that as the library doesn't have
>> a target and is not a
On Thursday 2014-07-17 00:02, Jonas 'Sortie' Termansen wrote:
>
>* The build system defaults --program-transform-name to the host triplet
> when cross-compiling. It shouldn't do that as the library doesn't have
> a target and is not a cross-compiler (as far as I know). It certainly
> doesn't ma
On Thursday 2014-07-17 00:02, Jonas 'Sortie' Termansen wrote:
>
>* ioctl(FIONBIO) is used in a few files to make sockets non-blocking
> rather than using fcntl to set the the standard O_NONBLOCK bit. The
> files apps/s_client.c and apps/s_server.c should use BIO_socket_nbio()
> instead of direc
Thanks for the quick responses and convincing feedback. Mind my goal is
not to become a supported platform - at all - but rather to lower the
portability barrier where reasonable. I can easily patch around any
other concerns locally.
Brent: I'll email you the changes that there's agreement on so y
>On 17/07/14 04:26, Bob Beck wrote:
>> Steve, sorry, but GNU/kFreeBSD is not going to happen right now. We
>> are too busy with other things.
>
>I understand, actually I wasn't asking for that. I think having lots of
>platform-specific implementations would be unclean, I was only hoping
>the exist
On 17/07/14 04:26, Bob Beck wrote:
> Steve, sorry, but GNU/kFreeBSD is not going to happen right now. We
> are too busy with other things.
I understand, actually I wasn't asking for that. I think having lots of
platform-specific implementations would be unclean, I was only hoping
the existing get
On Thursday 2014-07-17 00:02, Jonas 'Sortie' Termansen wrote:
>
>I ported libressl to my custom hobby OS and it has been a pleasant
>experience. Nonetheless, I did run into some minor portability problems
>that I wish to share:
>
>* apps/Makefile.am.tpl links libcrypto and libssl in the wrong orde
Steve, sorry, but GNU/kFreeBSD is not going to happen right now. We
are too busy with other things.
On Wed, Jul 16, 2014 at 6:26 PM, Steven Chamberlain wrote:
> Hi,
>
> On 16/07/14 23:02, Jonas 'Sortie' Termansen wrote:
>> * Consider using _DEFAULT_SOURCE or _ALL_SOURCE as feature macros on
>>
Hi Jonas,
While you make a few good points and they will be considered, but
really, "custom hobby os" is not really on our radar
right now. We have our hands full enough with portable dealing with
the major distros and libc's, and fending off all the haters.
On Wed, Jul 16, 2014 at 4:02 PM, Jonas
On Thu, 17 Jul 2014, Jonas 'Sortie' Termansen wrote:
> I ported libressl to my custom hobby OS and it has been a pleasant
> experience. Nonetheless, I did run into some minor portability problems
> that I wish to share:
To respond to selected items...
> * apps/Makefile.am.tpl links libcrypto and
Wow, this is a lot to go through, but I really do appreciate it.
It may take me a bit to sort through these, Could send them to me as discrete
patches (e.g. like a git send-email patch series)? That would make them easier
to sort through and apply individually?
On Jul 16, 2014, at 5:02 PM, Jona
Hi,
On 16/07/14 23:02, Jonas 'Sortie' Termansen wrote:
> * Consider using _DEFAULT_SOURCE or _ALL_SOURCE as feature macros on
> unknown platforms.
> * crypto/compat/issetugid_linux.c is used on non-Linux platforms. This
> fail on including glibc internal headers which is hardly elegant.
Thos
Hi,
I ported libressl to my custom hobby OS and it has been a pleasant
experience. Nonetheless, I did run into some minor portability problems
that I wish to share:
* apps/Makefile.am.tpl links libcrypto and libssl in the wrong order.
The libssl library depends on libcrypto and libcrypto doesn'
13 matches
Mail list logo
