From: Gert Doering
Return value of mbuf_len() wrong - it's returning a length value, not
a yes/no value - so when the queue length approached 65 (full!), it
still only returned "1", leading to MBUF overflow later on. Change
from "bool" to "int", misbehaviour g
l
branches" in their own repository, giving access to testers, without
having to have write access to SVN.
OTOH, the VCS used is just a tool to help the process, and not the
primary goal :-) - so I'm definitely not going to be religious abou
TCP/443, and as far as I understood so far, this was not possible)
If this is indeed not possible yet, is anybody working on this? I might
be tempted to tackle it, but would prefer to avoid duplicate work.
gert
--
USENET is *not* the non-clickable part of
Hi,
On Wed, Jan 27, 2010 at 09:32:05PM +1300, Jason Haar wrote:
> On 01/27/2010 09:17 PM, Gert Doering wrote:
> > Is this a single server listening on both ports, or is this two independent
> > servers?
>
> server running openvpn on tcp:1195 and udp:1195
So it's
ot sure or they know that their patch has not
> been included yet in the SVN tree James keeps.
Will do tonight :-)
> Of course, I am only going to do this if the community *and* OpenVPN
> company accept my offer. So unless somebody feel I'm not trustworthy or
> not capable of do
tation which describes this. Anyway, the
> documentation need should be discussed in the meeting today as well.
Yes, this has already been agreed-to on last week's IRC meeting and
is on the "TODO list" - provide a style guide for OpenVPN code.
Looking
existing
for that purpose, format_hex_ex() and setenv_str())
Someone with a better understanding of the crypto stuff should verify
that the ctx->current_cert->sha1_hash is always valid, and points to
a buffer of the necessary length.
gert
On Mon, Feb 15, 2010 at 11:28:13PM +0100, David
and whether something
should be done in a fundamentally different way.
gert
--
USENET is *not* the non-clickable part of WWW!
//www.muc.de/~gert/
Gert Doering - Munich, Germany g...@greenie.muc.de
fax:
would be "leave
the code as it is, merge jjo's code, and then revisit what he already
had to change for IPv6 connection handling". If gethostbyname() is still
there, come back and make this lookup function v4- and v6-capable, and
implement FQDN routes for IPv6 :-)
gert
--
USENET is *no
gt; nb);
> return ips[get_random () % nb];
> }
>
>
> Why on earth do you want to use get_random() in this situation?
That's original OpenVPN code, just moved to a different place.
While I am not saying
;if the argument does
not start with a "/", treat as CN - but as you said, this is just a
sample script anyway).
gert
--
USENET is *not* the non-clickable part of WWW!
//www.muc.de/~gert/
Gert Doering - Munich, Germany
*) (h->h_addr_list[0]);
if (ia.s_addr)
{
if (h->h_addr_list[1]) /* more than one address returned */
snip -
so the if() could be reduced even further, to just print the message.
gert
--
USENET is *not* th
f #ifdef'ing changes that affect so many
different places of the code (JJO's patch has 109 chunks, my patch
has 119 chunks) because it will make the code much harder to read, and
also harder to test ("how many different combinations of compile-time
options need to be ena
27;t break anything in my code, though
(lucky me :-) ) - my use of it in print_in6_addr() is mutex-locked anyway,
due to the use of a static buffer there.
Is getnameinfo() *guaranteed* to be thread-safe?
Do you have a reference that documents that inet_ntop() and inet_pton()
are unsave to be
tie-breaker here :-)
gert
--
USENET is *not* the non-clickable part of WWW!
//www.muc.de/~gert/
Gert Doering - Munich, Germany g...@greenie.muc.de
fax: +49-89-35655025g...@net.informatik.tu-muenchen.de
es not have IPv6.
On Windows, this might indeed be a killer argument to do some #idef'ing
- what's the oldest version of Windows officially supported by OpenVPN?
(XP and up has IPv6, everything before that does not)
gert
--
USENET is *not* the non-
in circumstances)
and it doesn't break current usage.
gert
--
USENET is *not* the non-clickable part of WWW!
//www.muc.de/~gert/
Gert Doering - Munich, Germany g...@greenie.muc.de
fax: +49-89-3565
Hi,
On Fri, Feb 19, 2010 at 05:18:29PM +0100, David Sommerseth wrote:
> I initially meant a more dynamic approach, changing it via the config
> file at runtime - by modifying a global C variable. But I agree, doing
> it via the ./configure script should really be sufficient.
A
he IPv6 stuff will not work, but it will not break
the IPv4 stuff.
If the net effect is "dynamic linking fails because inet_ntop() or
getaddrinfo() are not even available in the library", this would be very
bad - but it would be surprising, since developers have been told to
use the addres
er all, the summary is only my personal interpretation of the discussion.
No objections. It's an open discussion after all.
gert
--
USENET is *not* the non-clickable part of WWW!
//www.muc.de/~gert/
Ger
Hi,
On Fri, Feb 19, 2010 at 08:33:04PM +0100, Gert Doering wrote:
> > [uclibc without UCLIBC_HAS_IPV6]
>
> I have to investigate.
And so I did. The impact of UCLIBC_HAS_IPV6=0 is fairly low:
- getaddrinfo() will not resolve IPv6 addresses (but *will* be available)
- the exte
different combination of
optional compile-time features that what you use).
For uClibc, the answer could be "it should be sufficient to just define
'in6_addr_any' locally in OpenVPN code, if uClibc is detected" - that's
just
Hi,
On Fri, Feb 19, 2010 at 11:57:30PM +0100, David Sommerseth wrote:
> (I'm withdrawing the first version, and suggesting this patch to be used
> instead,
> as this one follows the new feature deprecation process.)
ACK!
gert
--
USENET is *not* the non-clickab
ct applying it over
> allmerged once the latter includes ipv6_transport.
Shouldn't git sort this out, if it's exactly the same change?
gert
--
USENET is *not* the non-clickable part of WWW!
//www.muc.de/~gert/
Gert Doerin
Hi,
On Sun, Feb 21, 2010 at 09:03:11PM +0100, Peter Stuge wrote:
> Gert Doering wrote:
> > I'll try to figure out how to setup a cross-compile environment
> > during next week,
>
> Some Linux distributions have premade mingw packages.
>
> In Gentoo building a
v6-setup using Gert's payload-patch. This
> setup could be tested by our members during daily use.
If you need any help with that, you know where to find me :-)
> Maybe some livebuilds for ubuntu/debian will be available then?
Chances are pretty good, from the rumors I've heard on I
ng start-up and will show all warnings
> after the OpenVPN title string.
>
> Included a deprecated feature warning for the resolv-random feature.
>
> Signed-off-by: David Sommerseth
ACK!
gert
--
USENET is *not*
ge conflict with another patch in this line (like "introduce
version 4" or so), and so I'd avoid changes that are purely cosmetic in
a "feature" patch.
gert
--
USENET is *not* the non-clickable part of WWW!
nyway - so why not
change it to:
static inline int
ifconfig_order(void)
{
#if defined(TARGET_OPENBSD)
return IFCONFIG_BEFORE_TUN_OPEN;
#elif defined(WIN32)
return IFCONFIG_BEFORE_TUN_OPEN;
#else
return IFCONFIG_AFTER_TUN_OPEN;
#endif
}
I'm purpos
It seems to work though, and the code elsewhere
does not seem to make any assumptions about "port != 0" (it is effectively
just passed to bind(), and if bind() doesn't like it, an error exit occurs).
Since it fixes a real-world problem, there is obvio
27;ll send in a patch that drops the
duplicate bits. The tun.c code is still hard enough to read...
gert
--
USENET is *not* the non-clickable part of WWW!
//www.muc.de/~gert/
Gert Doering - Munich, Germany g...
ause the tun0 interface
is auto-destroyed after closing it, so it's just superfluous and broken
code.
What I cannot test is: is it required on 10.4, 10.3, ...? If yes, which
versions of MacOS X need it, and should we add a "configure" test for it?
(I'm afraid this needs going back i
changes that are purely cosmetic in
> > a "feature" patch.
>
> Dang! This one slipped through. I spotted it, fixed it, but for some
> reason I recreated the patch file and forgot I had fixed it. Gert, I
> completely agree with you!
:)
> I'll promise to
the right way
to go forward, but it helps me to work on the IPv6 bits for the time
being. (See below). An alternative way would be to copy %PATH% to "es"
upn startup (on Windows), or add another config variable "win-path" or
whatever.
Feedback requested!
gert
diff --git a/win32.c
de in my branch, of course,
so please pull that to feat_ipv6_payload as well :-) - mostly code cleanups,
and Win32 preparations)
thanks,
gert
--
USENET is *not* the non-clickable part of WWW!
//www.muc.de/~gert/
Gert Doering - Mun
Hi,
to follow up on this...
On Sun, Feb 21, 2010 at 09:14:16PM +0100, Gert Doering wrote:
> On Sun, Feb 21, 2010 at 09:03:11PM +0100, Peter Stuge wrote:
> > Gert Doering wrote:
> > > I'll try to figure out how to setup a cross-compile environment
> > > durin
tem and could test the
OpenVPN IPv6 payload stuff there?)
gert
--
USENET is *not* the non-clickable part of WWW!
//www.muc.de/~gert/
Gert Doering - Munich, Germany g...@greenie.muc.de
fax: +49-89-35655025g...@net.informatik.tu-muenchen.de
f the change would have to be done in parallel on multiple branches,
causing the payload branch then to no longer apply to "base 2.1.1".
For this reason, I would NOT apply this patch right now - wait for the
development tree to stabilize, before applying a mostly-religious change
that af
use issues on some platforms.
(Don't put the tmp_file condition into the surrounding if(), as it
would then skip the call to gc_free() as well).
With that change, and a manpage documentation of the new option, ACK.
gert
--
USENET is *not* the non-clickable part of WWW!
nsions of the peer certificate
> - delta CRL verification
> - ...
ACK.
gert
--
USENET is *not* the non-clickable part of WWW!
//www.muc.de/~gert/
Gert Doering - Munich, Germany g...@greenie.muc
package) are going extremely slowly and others not.
TCP_NODELAY
David has already suggested that you should try setting
"socket-flags TCP_NODELAY"
- did you?
gert
--
USENET is *not* the non-clickable part of WWW!
//www.muc.
nd the data immediately (generating a small packet).
(This is a fundamental problem with TCP - the stacks are optimized for
certain patterns, either "bulk data, make full size packets" or
"interactive traffic, send single bytes of keystrokes, where a few ms
delay don't hurt"
Hi,
On Fri, Mar 05, 2010 at 09:42:23AM +0100, Heiko Hund wrote:
> On Sunday 28 February 2010 15:50:01 Gert Doering wrote:
> > Now, for all operatings systems *except* Win32 and OpenBSD, the sequence
> > of execution is
> >
> > open_tun()
> > do_ifconfig()
g through the socket code of OpenVPN is fairly
far down on my "what to do with OpenVPN in my spare time" list.
gert
--
USENET is *not* the non-clickable part of WWW!
//www.muc.de/~gert/
Gert Doering - Munich, Germa
Hi,
On Fri, Mar 05, 2010 at 11:44:28AM +0100, Heiko Hund wrote:
> On Friday 05 March 2010 10:11:51 Gert Doering wrote:
> > What happened exactly? Could you ask your colleague for a log file?
>
> Well, he couldn't ping any remote host. Nothing special in the log, reall
hing
special).
Maybe this was changed between older OpenBSD versions and the current
versions?
Given this information, I will prepare a patch that will handle OpenBSD
the same way as FreeBSD is done - run open_tun() first, do_ifconfig()
second, and do away with the "ifconfig destroy"
Hi,
On Sun, Feb 28, 2010 at 11:23:26PM +0100, Gert Doering wrote:
> to follow up on this...
Next round of "do things on windows" :-)
> [ TUN / TAP driver on windows ]
>
> Now... is there someone who has worked on this before, and can help
> me a bit with it?
Hi,
On Sun, Mar 07, 2010 at 09:47:17PM +0100, Peter Stuge wrote:
> Gert Doering wrote:
> > -!define PRODUCT_TAP_RELDATE "06/22/2009"
> > +!define PRODUCT_TAP_RELDATE "07/03/2010"
>
> Seems month/date are swapped.
Stupid american
g to the code that does neighbor discovery / neighbor
advertisement spoofing, so it's visible in the logs what happens and
why.
gert
--
USENET is *not* the non-clickable part of WWW!
//www.muc.de/~gert/
Gert Doering - Munich, Germany
tem.
I'm not saying it can't be done :-) - but just that the "simple way"
is not so simple, it's just complex in other places.
gert
--
USENET is *not* the non-clickable part of WWW!
//www.muc.de/~gert/
Gert Doeri
ated a prefix. But this is all "future plans" - first,
get the current IPv6 payload stuff tested well enough that it can get
integrated in the next beta :-)
> Invoking the distribution auto-configuration/ scripts makes more sense.
It doesn't. For the same reaso
> configure OpenVPN.
Seconded.
gert
--
USENET is *not* the non-clickable part of WWW!
//www.muc.de/~gert/
Gert Doering - Munich, Germany g...@greenie.muc.de
fax: +49-89-35655025
VPN wants to be friendly to the users, and give them an option
to do DHCP-on-TAP without(!) having to fiddle with their local network
setup.
gert
--
USENET is *not* the non-clickable part of WWW!
//www.muc.de/~gert/
Gert Doering - Munich,
S X
and Window - and it's not OpenVPN's job to fix the local equivalent of
ifplugd on each of these systems. OpenVPN's aim is to provide an
easy-to-use VPN environment for people that do not want to endlessly
fiddle with operating system settings.
gert
--
USENET is *not* t
Hi,
forwarded with permission from Ben back to the list - another data
point: a successful test of the IPv6-patched windows binaries and
windows tap driver, on Windows XP.
More testers with Vista and Win7 needed :-)
gert
- Forwarded message from Ben Bird -
X-Spam-Status: No, score
t, better include a full description of what you did,
on which platform, and what error message resulted - otherwise we're not
able to give useful advice.
(Out of personal curiousity: why are you trying to build-your-own? The
precompi
ll, this is putting extra work on David Sommerseth's lap. If he is willing
to handle that, I won't object.
As for now, I have been operating under the premises that different branches
in the openvpn-devel tree should avoid to cause merge conflicts (unless
u
n out though :)
Given the amount of religous discussions about OpenSource stuff, this
is a very reasonable point of view ;-)
gert
--
USENET is *not* the non-clickable part of WWW!
//www.muc.de/~gert/
Gert Doering - Munich, Germany
x27;t touch any of the signal handling stuff, I'm fairly sure
that it wasn't one of my changes, but I still want to have a working
Windows bundle to get people to test it)
thanks,
gert
PS: the TAP driver changes have been successfully tested on 3 different
WinXP systems now. Win7 doe
ls.
(If I increase the log verbosity to "verb 9", lots of stuff is going
on, but nothing in there that gives any indication of signals being
received)
gert
--
USENET is *not* the non-clickable part of WWW!
//www.muc.
ges (which is an important bit).
When running openvpn.exe from the "cmd.exe" command line, it does not matter
which binary I am using - "ctrl-c" never does anything, and "F4" always
causes a clean shutdown.
Weird, this.
gert
--
USENET is *not* the non-clickable part o
#x27;t accept the
> http:// prefix, especially if the port number is 443.
As tested: this syntax neither works with Squid nor Apache.
So I'd tend to agree with David: if a single user had a problem with
a T-Home proxy in 2007, I'd tend to blaim the proxy.
gert
--
last key exchange */
> + counter_type n_packets; /* how many packets sent/recvd since last key
> exchange */
ACK, this looks good. The "counter_type" and "counter_format" infrastructure
will give 64-bit counters with portability to whatever syste
ntain the
> complete ./configure line which was used when configuring the package
> for building.
A bit late, but "looks good to me" (and useful, too :) ). ACK.
gert
--
USENET is *not* the non-clickable part of WWW!
//www.m
smissions) on a different VID.
So you can't rely on "VID 1 = untagged".
gert
--
USENET is *not* the non-clickable part of WWW!
//www.muc.de/~gert/
Gert Doering - Munich, Germany g...@greenie
check whether this really takes
place.
Something else I need to check: the "standard" mroute code hashes based
on ethernet address (in tap mode). What happens if the same MAC address
shows up for two different VLAN IDs? (Not very likely for virtual
ethernet devices, though, but this can happe
to
non-existant files (like "-> /etc/nologin").
It *will* protect against symlink attacks to existing files (overwriting
/etc/passwd or something similarily nasty).
gert
--
USENET is *not* the non-clickable part of WWW!
//w
ame is a symbolic link, open() will fail
even if the symbolic link points to a non-existent name.
- so please disregard my comment. Everything is fine.
gert
--
USENET is *not* the non-clickable part of WWW!
//www.muc.de/~gert/
Ger
Hi,
On Sat, Apr 17, 2010 at 09:06:09PM +0200, David Sommerseth wrote:
> If create_temp_file() returns NULL, this strlen() check would cause
> a SEGV.
Looks "obviously correct". ACK.
gert
--
USENET is *not* the non-click
n.
Overall, this looks good to me (with the additional changes by Fabian
and you). So ACK.
gert
--
USENET is *not* the non-clickable part of WWW!
//www.muc.de/~gert/
Gert Doering - Munich, Germany g...@g
tun.c changes
for Solaris? Its own branch, feat_misc branch, feat_ipv6_payload branch?
If we include it in feat_ipv6_payload, it won't have merge conflicts - but
then you only get the TAP-on-Solaris in combination with all the IPv6 stuff,
which people might not want.
David?
gert
--
USENET
--- quote --
>From a first glance, this looks like "whitespace changes only".
For easier review: would you be so kind and re-send your patch with
"diff -uw" (-w = ignore white space changes)?
thanks,
gert
--
USENET is *not* the non-
affect the
Solaris-specific part of tun.c.
gert
--
USENET is *not* the non-clickable part of WWW!
//www.muc.de/~gert/
Gert Doering - Munich, Germany g...@greenie.muc.de
fax: +49-89-35655025
o
"my" tun.c, and commit to the IPv6 payload branch. (Will take a few
days...)
If someone urgently needs TAP support for Solaris later on, but refuses
to use the IPv6 stuff, we can still sort out what to do then.
gert
--
USENET is *not* the non-clickable part of WWW!
yte counts to get "inactivity".
I'd go that route...
Efficiency is a valid concern, of course. Since is_ping_msg() and
buf_string_match() are both (very short) inline functions, and memcmp()
on "normal" architectures is also inlined by gcc, this "should not" add
s code then adding an extra input
validation check
if ((network.s_addr & netmask) != network.s_addr )
{ complain; }
- so: ACK from me.
(Since OpenVPN likes to print warnings, we *could* add code to print a
warning in this case - "warning: subnet address changed to match /%d,
ne
> This seems rather pedantic to me...
Well, it is, but it's in line with the rest of OpenVPN - there are many
places where a (percieved) user error results in a warning, explaining
the situation...
gert
--
USENET is *not*
gt; reference to the same define. It is the defensive way.
I'm a bit late, but I also want to second this :-)
That way, if the definition of "common_name" is ever changed to a
different size, e.g "TLS_USERNAME_LEN+3" or whatever, all(!) references
automatically get the c
rom an 'application
> controlled' adapter .
I'd assume that windows services are not "bound" to "dynamic" interfaces...
gert
--
USENET is *not* the non-clickable part of WWW!
//www.muc.de/~gert/
Ger
ch (which David will have "soonish" :) ) would be great as well.
gert
--
USENET is *not* the non-clickable part of WWW!
//www.muc.de/~gert/
Gert Doering - Munich, Germany g...@greenie.muc.de
f
Hi,
On Wed, Jun 23, 2010 at 10:50:45PM +0300, Henno Täht wrote:
> On Wed, Jun 23, 2010 at 22:48, Gert Doering wrote:
> > On Wed, Jun 23, 2010 at 09:10:10AM +0200, Jan Just Keijser wrote:
> > > assigns a 169.254 address. If this works for you as well then maybe the
> > &g
nt, and some help in fixing the wiki-fu to make it
look more nice :-)
http://secure-computing.net/wiki/index.php/OpenVPN/OpenWRT
- have fun.
(I still don't know how whether one can use the same tree to build
multiple different architectures in parallel - but if one of you knows,
please add to t
Hi,
On Sun, Jun 27, 2010 at 05:13:35PM +0200, Gert Doering wrote:
> as promised a few weeks ago at the IRC meeting, I've sat down and built
> an OpenVPN-devel package (based on ecrist's weekly tar balls, which
> in come from dazo's git tree).
>
> I've
oesn't work for OpenBSD, I need to see the parts from your
config.log relating to
gert
-- snip ----
Signed-off-by: Gert Doering
---
configure.ac |3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/configure.ac b/configure.ac
index 4626e46..
Hi,
On Fri, Jul 09, 2010 at 10:31:02AM +0200, Gert Doering wrote:
> the following patch fixes the IFF_MULTICAST compile-time problems on NetBSD,
> and it should also fix them on OpenBSD (trac entry #17).
This would have been too easy... on NetBSD, can be
include before (which the or
;t answer
right away).
Oh: don't use the tun.c from the whiteboard web page - this is parallel
work, and it won't work with feat_ipv6_payload. Integration of
Kazuyoshi-san's tun.c work into openvpn-testing is on m
w right now, but I'll try to find out.
> (BTW is there any work in progress for a v6 transport?)
Well, there's feat_ipv6_transport by jjo, and of course, the "allmerged"
branch which has both v6 payload and v6 transport. As far as I understand,
the v6 transport stuff works on
the mailing list as well to get review.
Well, here you are :-)
gert
>From e1f41b55a294c4f70a72d02e77aca140ac10a3a3 Mon Sep 17 00:00:00 2001
From: Gert Doering
List-Post: openvpn-devel@lists.sourceforge.net
Date: Sun, 8 Aug 2010 12:34:00 +0200
Subject: [PATCH] implement IPv6 ifconfig +
t_client.rc).
- this is neither finished nor pretty, but it helps me a *lot* in
quickly testing whether I broke anything when fiddling system-dependent
code (tun.c, route.c) across multiple build hosts - so I hope this
is going to be fairly useful to Samuli and the buildbot :-)
enjoy
Hi,
On Sun, Aug 08, 2010 at 09:48:47PM +0200, Gert Doering wrote:
> as discussed in one of the previous the IRC meetings, I've been working
> on a test framework to enable full "fire up openvpn client, establish
> VPN connection, run ping tests, clean up, verify cleanup"
uot;if you don't want to
test this, this must be a mistake!!!") - but since this is not
something everyone will be using, your patch makes more sense.
ACK, and thanks.
gert
--
USENET is *not* the non-clickable part of WWW!
Hi,
On Wed, Aug 18, 2010 at 03:04:03PM +0200, David Sommerseth wrote:
> This is to avoid 'make check' fail if this extra test case is not
> configured.
[..]
> +exit 77
> +fi
> +
ACK again. Better :)
gert
--
USENET is *not* the
that can be successfully
tested "just by extracting the tarball and run make ; make check".
We ship a t_client.rc-sample that explains what goes in there and how
to enable this.
gert
--
USENET is *not* the non-clickable part of WWW!
check
> if there are more (I've not been looking at the source script for lack of
> time).
There are some more.
David, could you patch these as well? Otherwise I need to go cherrypicking
your changes first (and this might take longer).
gert
--
USENET is *not* the non-clickable part of WWW!
//www.muc.de/~gert/
Gert Doering - Munich, Germany g...@greenie.muc.de
fax: +49-89-35655025g...@net.informatik.tu-muenchen.de
Hi,
On Wed, Aug 18, 2010 at 05:06:27PM +0200, David Sommerseth wrote:
> Several places we exited with 0 instead of 77 when we want to indicate
> that we should skip this test.
ACK. Thanks to Matthias for pointing this out.
gert
--
USENET is *not* the non-clickable part
uld be sort of stuck
to the old APIs - which might turn into a problem. Or might not. We
don't know...
> libusb-win32 can already compile their driver using MinGW.
To be able to cross-compile the driver would certainly be nice. Need to
check how libusb-win32 does this...
ge
Hi,
On Fri, Aug 20, 2010 at 10:56:51AM -0500, Karl O. Pinc wrote:
> On 08/20/2010 10:48:17 AM, Gert Doering wrote:
>
> > The app is cross-compileable today - but to make that work requires
> > that
> > all relevant Windows APIs are exported in mingw headers *and
> >
Hi,
On Fri, Aug 20, 2010 at 06:24:06PM +0200, Peter Stuge wrote:
> Gert Doering wrote:
> > The app is cross-compileable today - but to make that work requires that
> > all relevant Windows APIs are exported in mingw headers *and libraries*.
>
> Sure. You emphasize libraries
.crt --key sample-keys/client.key \
> --dev tun --nobind --auth-user-pass
You might want to take a look at t_cltsrv.sh and build a "make check" test
script from there... verifying the expected output in the logfile after
the test run...
gert
--
sting to see if creating a static binary would be
> > trivial. As it was not,
>
> Why wasn't it? Please share details from the testing.
Naively just calling "gcc -static" led to linker failures due to OpenSSL
not being found.
This was a "can we do it that easily?" qui
1 - 100 of 6320 matches
Mail list logo
