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 order.
Hi,
Kent R. Spillner wrote on Wed, Jun 04, 2014 at 10:01:12AM -0500:
config(char *) contains a hand-rolled version of getlist(char *).
Indeed.
The only difference is that the hand-rolled version includes a NULL
check before the strcmp.
You misread the code. There is no NULL check for the
sys.mk automatically gets included by make(1) and sets CXXFLAGS to
CFLAGS. If a Makefile defines additional CFLAGS they will then be
passed to the C++ compiler. Which creates problems with flags
that should only be used by the C compiler in Makefiles that
deal with both C and C++ (like Mesa).
On 2014/07/18 00:10, Jonathan Gray wrote:
sys.mk automatically gets included by make(1) and sets CXXFLAGS to
CFLAGS. If a Makefile defines additional CFLAGS they will then be
passed to the C++ compiler. Which creates problems with flags
that should only be used by the C compiler in Makefiles
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
Thanks for the feedback, Ingo! Sorry for the confusion. I'll spend some more
time with queue(3). :)
On Jul 17, 2014, at 1:21, Ingo Schwarze schwa...@usta.de wrote:
Hi,
Kent R. Spillner wrote on Wed, Jun 04, 2014 at 10:01:12AM -0500:
config(char *) contains a hand-rolled version of
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
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
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 directly
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 make
On Jul 17, 2014, at 1:39 PM, Jan Engelhardt jeng...@inai.de 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
On Tue, Jul 15, 2014 at 12:13:58AM +0200, Maximilian Fillinger wrote:
Something I forgot about during the discussion about the diff for dump:
The manpage doesn't mention yet that we can specify the duid on the
command line now.
fixed, thanks.
jmc
--- sbin/dump/dump.8.orig Mon Jul 14
2014-07-17 16:13 GMT+02:00 Stuart Henderson st...@openbsd.org:
On 2014/07/18 00:10, Jonathan Gray wrote:
sys.mk automatically gets included by make(1) and sets CXXFLAGS to
CFLAGS. If a Makefile defines additional CFLAGS they will then be
passed to the C++ compiler. Which creates problems
Since net.inet6.ip6.accept_rtadv is gone, the installer shouldn't
set it.
It is not obvious to me that enabling rediraccept is more important
for IPv6 than for IPv4, where we keep is disabled by default. Do
we want to kill that whole block?
Index: install.sh
Hm, is there a practical consequence of this? Seems like it would
only affect applications trying to store a reference to lsearch in a
function pointer of type void (*)(const void *, void *, size_t *,
size_t, int (*)(const void *, const void *)); do those exist?
On Thu, Jul 17, 2014 at 5:38 PM,
Hrm. It seems silly to me to change it to require a non-const pointer
argument, but POSIX, Linux, Solaris, FreeBSD, and NetBSD all use void
*base so it doesn't seem like we should have any ports tree issues
from changing it to be compatible either.
On Thu, Jul 17, 2014 at 6:04 PM, enh
Ran into this while running the regression suite for another patch.
The regression test for open_memstream causes a SIGBUS because it closes
the stream too early.
Replaced fclose with fflush since they both update pbuf and psize.
Added a similar check for fclose at the end.
Index:
On 7/17/14, Matthew Dempsky matt...@dempsky.org wrote:
Hrm. It seems silly to me to change it to require a non-const pointer
argument,
Silly even though, the description of lsearch says it will modify
(it shall be added at the end of) the table, for which base
argument points to the first
On Thu, Jul 17, 2014 at 8:05 PM, patrick keshishian pkesh...@gmail.com wrote:
Silly even though, the description of lsearch says it will modify
(it shall be added at the end of) the table, for which base
argument points to the first element?
Ah, I didn't pay close attention to the definition
19 matches
Mail list logo
