Re: [Openvpn-devel] [PATCH] On TARGET_LINUX define _GNU_SOURCE if not defined

[David Sommerseth]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 10/03/10 11:49, David Sommerseth wrote:
> From: David Sommerseth 
> 
> This is to include peercred support on hosts where _GNU_SOURCE is not
> defined by default.  This issue has been found on Gentoo with glibc-2.8.
> 
> The solution was discussed on the IRC meeting March 4, 2010
> in #openvpn-discussions.
> 
> 
> Signed-off-by: David Sommerseth 
> ---
>  syshead.h |4 
>  1 files changed, 4 insertions(+), 0 deletions(-)
> 

Applied to bugfix2.1, merged into allmerged.
Commit 081ec9314eaa75769b2351a7b1b05315a4c77560


kind regards,

David Sommerseth
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iEYEARECAAYFAkuf/VYACgkQDC186MBRfroWSwCgrODOR77AeLjg61macOc+dBfa
DosAoLB7szhiMQpqB8MvxNirwkPyzhJQ
=6+5n
-END PGP SIGNATURE-

Re: [Openvpn-devel] [PATCH] On TARGET_LINUX define _GNU_SOURCE if not defined

[Karl O. Pinc]

On 03/13/2010 05:34:19 PM, Matthias Andree wrote:
> Karl O. Pinc wrote on 2010-03-10:

> > But, you _don't_ have to run ./configure every time.  You
> 
> You do.

Yes.  Thanks.  I don't know what I was thinking.  


Karl 
Free Software:  "You don't pay back, you pay forward."
 -- Robert A. Heinlein

Re: [Openvpn-devel] [PATCH] On TARGET_LINUX define _GNU_SOURCE if not defined

[Matthias Andree]

Alon Bar-Lev wrote on 2010-03-10:


If you patch autoconf/automake stuff, you *MUST* add autoconf/automake
dependency to your package, so you can regenerate the files. It is
much simpler to patch also the generated files and avoid this
dependency. But it is packager's call.


For distributions and packaging, hacking the outputs is often simpler  
unless the input had been expanded and/or copied around, because it waives  
and additional build requisites.  It sometimes happens that there are  
distribution-specific changes that aren't fit for upstream inclusion.  The  
FreeBSD ports repository is full of such stuff, and I'd usually patch  
outputs there -- and for the majority of packages, the patches for the  
output files aren't any less stable than those for input files would be,  
but they are so much easier on the end users.



Please understand, in order to build a package you *DO NOT* need
autoconf/automake/libtool installed *AT ALL*.


Careful with the wording here, as "build a package" is ambiguous:
(1) build a tarball distribution package (openvpn-2.1.X.tar.gz)
(2) build a openvpn.rpm or .deb from the tarball.

I'll reword: In order to build the binaries from a tarball generated with  
"make dist" (what the release manager uploads and the end user usually  
downloads from sourceforge or other distribution sites), no  
autoconf/automake/libtool are required.


--
Matthias Andree

Re: [Openvpn-devel] [PATCH] On TARGET_LINUX define _GNU_SOURCE if not defined

[Peter Stuge]

Karl O. Pinc wrote:
> And, to reiterate, applying patches within an rpm
> spec file is normal, expected, and part of the
> rpm design so a certain level of "development" is supported.

Should also not be a problem, since those patches are likely to start
from a known release tarball, so autoconf still isn't needed.


//Peter

Re: [Openvpn-devel] [PATCH] On TARGET_LINUX define _GNU_SOURCE if not defined

[David Sommerseth]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 10/03/10 19:04, Karl O. Pinc wrote:
> On 03/10/2010 11:54:52 AM, David Sommerseth wrote:
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA1
>>
>> On 10/03/10 18:39, Karl O. Pinc wrote:
>>> On 03/10/2010 11:19:13 AM, Alon Bar-Lev wrote:
 I will try to explain again.

 You have two roles of environments:

 1. Developer/packager workstation.

 2. Target environment.

 For example, 1 would be my computer, and 2 would be the old redhat
 computer.

 You go to (1) and do:
 $ autoreconf -ivf
 $ ./configure && make dist

 Now, you transfer the tarball to users, the old redhat computer is 
 one
 of them. The tarball will work WITHOUT ANY
>> AUTOCONF/AUTOMAKE/LIBTOOL
 installed.

 I use older environments as (2) such as solaris-8.
>>>
>>> And you don't generally want to be running ./configure from within
>>> a rpm specfile, so the same is true of using the rpm tools:
>>
>> This is not correct.  In fact, you often use the %configure macro in
>> %build, which does call ./configure.  The only "allowed" exception
>> from
>> not calling %configure is when ./configure is not a native autotools
>> generated configure script.
> 
> Ok.  I'm totally wrong here.
> 
> But how is it then that Alon does not run ./configure
> on machine 2 above?

The fact is that I believe he does run ./configure on all machines.
Autotools just generates a set up files which is not depending on
anything else than basic *nix tools, like shell, grep, sed, etc, etc.

But to be able to make the tarball via 'make dist', you need to run
./configure first to have a Makefile which knows what the 'dist' rule
is.  Then the 'dist' rule wraps it all together into a autotools
independent tarball, including a prepared ./configure script.

>>> On machine 2 you download the tarball, the specfile, (and
>>> any patches the rpm maintainer wants to include in the
>>> packaged version) and run the rpm build tools on the
>>> spec file to build a binary rpm.  
>>>
>>> Note that http://www.rpm.org/max-rpm/s1-rpm-inside-scripts.html
>>> says: 
>>>
>>> "Once the %prep script has gotten everything ready for the build,
>> the %
>>> build script is usually somewhat anti-climactic — normally invoking 
>>> make, maybe a configuration script, and little else. 
>>
>> It's %build which need to do the %configure.  All patching must 
>> happen
>> on %prep.  But you are right, if there are applied patches which
>> updates
>> some of the autotools generated files, I believe autotools need to be
>> run again.  Right, Alon?
> 
> Nothing should patch the autotools generated files, just the autotools
> source files.  Right?

Correct, that was my mistake.  I initially meant autotools source files.
 But I believe autotools can detect if some of the generated files have
been modified and it will then want to run 'autoreconf' automatically
again.  I believe I've seen this behaviour some times.


kind regards,

David Sommerseth
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iEYEARECAAYFAkuX4HMACgkQDC186MBRfrox/wCeIzBmcdNaamPjobF0qXX5+Frs
YJgAn11CqkBVYLTzsUS3ygGP576WzqSl
=4qX5
-END PGP SIGNATURE-

Re: [Openvpn-devel] [PATCH] On TARGET_LINUX define _GNU_SOURCE if not defined

[Karl O. Pinc]

On 03/10/2010 11:54:52 AM, David Sommerseth wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> On 10/03/10 18:39, Karl O. Pinc wrote:
> > On 03/10/2010 11:19:13 AM, Alon Bar-Lev wrote:
> >> I will try to explain again.
> >>
> >> You have two roles of environments:
> >>
> >> 1. Developer/packager workstation.
> >>
> >> 2. Target environment.
> >>
> >> For example, 1 would be my computer, and 2 would be the old redhat
> >> computer.
> >>
> >> You go to (1) and do:
> >> $ autoreconf -ivf
> >> $ ./configure && make dist
> >>
> >> Now, you transfer the tarball to users, the old redhat computer is 
> >> one
> >> of them. The tarball will work WITHOUT ANY
> AUTOCONF/AUTOMAKE/LIBTOOL
> >> installed.
> >>
> >> I use older environments as (2) such as solaris-8.
> > 
> > And you don't generally want to be running ./configure from within
> > a rpm specfile, so the same is true of using the rpm tools:
> 
> This is not correct.  In fact, you often use the %configure macro in
> %build, which does call ./configure.  The only "allowed" exception
> from
> not calling %configure is when ./configure is not a native autotools
> generated configure script.

Ok.  I'm totally wrong here.

But how is it then that Alon does not run ./configure
on machine 2 above?

> 
> > On machine 2 you download the tarball, the specfile, (and
> > any patches the rpm maintainer wants to include in the
> > packaged version) and run the rpm build tools on the
> > spec file to build a binary rpm.  
> > 
> > Note that http://www.rpm.org/max-rpm/s1-rpm-inside-scripts.html
> > says: 
> > 
> > "Once the %prep script has gotten everything ready for the build,
> the %
> > build script is usually somewhat anti-climactic — normally invoking 
> > make, maybe a configuration script, and little else. 
> 
> It's %build which need to do the %configure.  All patching must 
> happen
> on %prep.  But you are right, if there are applied patches which
> updates
> some of the autotools generated files, I believe autotools need to be
> run again.  Right, Alon?

Nothing should patch the autotools generated files, just the autotools
source files.  Right?



Karl 
Free Software:  "You don't pay back, you pay forward."
 -- Robert A. Heinlein

Re: [Openvpn-devel] [PATCH] On TARGET_LINUX define _GNU_SOURCE if not defined

[Karl O. Pinc]

On 03/10/2010 11:41:49 AM, Alon Bar-Lev wrote:
> On Wed, Mar 10, 2010 at 7:39 PM, Karl O. Pinc  wrote:
> > In other words ./configure is not expected to be run under normal
> > circumstances.
> >
> > The whole point of autoconf is to produce something that can
> > be made into a tarball that only requires "make; make install"
> > to compile and install.
> 
> You do not understand the tools. Nor the common use of them.
> 
> You *MUST* run ./configure when compiling from sources.

You are right, on all of the above.  I don't use them every
day. 

But, you _don't_ have to run ./configure every time.  You
yourself wrote that you do the ./configure on the _new_
machine, and then move the tarball to the old machine
and recompile.  This is often the situation, or at least
I found so, when making rpm spec files.

You are quite correct in pointing out that ./configure
should be able to be run on the old machine, which
means that it can be executed within the build portion
of the spec file.

Thanks for the correction and please tell me if I'm
wrong again.

Karl 
Free Software:  "You don't pay back, you pay forward."
 -- Robert A. Heinlein

Re: [Openvpn-devel] [PATCH] On TARGET_LINUX define _GNU_SOURCE if not defined

[David Sommerseth]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 10/03/10 18:39, Karl O. Pinc wrote:
> On 03/10/2010 11:19:13 AM, Alon Bar-Lev wrote:
>> I will try to explain again.
>>
>> You have two roles of environments:
>>
>> 1. Developer/packager workstation.
>>
>> 2. Target environment.
>>
>> For example, 1 would be my computer, and 2 would be the old redhat
>> computer.
>>
>> You go to (1) and do:
>> $ autoreconf -ivf
>> $ ./configure && make dist
>>
>> Now, you transfer the tarball to users, the old redhat computer is 
>> one
>> of them. The tarball will work WITHOUT ANY AUTOCONF/AUTOMAKE/LIBTOOL
>> installed.
>>
>> I use older environments as (2) such as solaris-8.
> 
> And you don't generally want to be running ./configure from within
> a rpm specfile, so the same is true of using the rpm tools:

This is not correct.  In fact, you often use the %configure macro in
%build, which does call ./configure.  The only "allowed" exception from
not calling %configure is when ./configure is not a native autotools
generated configure script.

> On machine 2 you download the tarball, the specfile, (and
> any patches the rpm maintainer wants to include in the
> packaged version) and run the rpm build tools on the
> spec file to build a binary rpm.  
> 
> Note that http://www.rpm.org/max-rpm/s1-rpm-inside-scripts.html
> says: 
> 
> "Once the %prep script has gotten everything ready for the build, the %
> build script is usually somewhat anti-climactic — normally invoking 
> make, maybe a configuration script, and little else. 

It's %build which need to do the %configure.  All patching must happen
on %prep.  But you are right, if there are applied patches which updates
some of the autotools generated files, I believe autotools need to be
run again.  Right, Alon?


kind regards,

David Sommerseth

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iEYEARECAAYFAkuX3OoACgkQDC186MBRfrrMpgCfa6qtBOfumt0Z2AIRP6G7Eaem
TEoAnRVqqeU2mFs8XbmiL9ry3NR6ETDJ
=IY4/
-END PGP SIGNATURE-

Re: [Openvpn-devel] [PATCH] On TARGET_LINUX define _GNU_SOURCE if not defined

[Karl O. Pinc]

On 03/10/2010 11:37:57 AM, David Sommerseth wrote:
> On 10/03/10 18:26, Peter Stuge wrote:

> > The only way autoconf on that RHEL4.6 would be relevant is if those
> > RHEL4.6 systems strictly need to build directly from git source, as
> > opposed to building from a prepared tarball. Is that the case?
> 
> I will get that clarified on the meeting tomorrow, as this might be a
> scenario.  But to be honest, I have troubles seeing that people want
> to
> do active development on RHEL4.6, at least do changes which require
> changing autotools files or pulling down SVN or git trees.

And, to reiterate, applying patches within an rpm
spec file is normal, expected, and part of the
rpm design so a certain level of "development" is supported.




Karl 
Free Software:  "You don't pay back, you pay forward."
 -- Robert A. Heinlein

Re: [Openvpn-devel] [PATCH] On TARGET_LINUX define _GNU_SOURCE if not defined

[Karl O. Pinc]

On 03/10/2010 11:19:13 AM, Alon Bar-Lev wrote:
> I will try to explain again.
> 
> You have two roles of environments:
> 
> 1. Developer/packager workstation.
> 
> 2. Target environment.
> 
> For example, 1 would be my computer, and 2 would be the old redhat
> computer.
> 
> You go to (1) and do:
> $ autoreconf -ivf
> $ ./configure && make dist
> 
> Now, you transfer the tarball to users, the old redhat computer is 
> one
> of them. The tarball will work WITHOUT ANY AUTOCONF/AUTOMAKE/LIBTOOL
> installed.
> 
> I use older environments as (2) such as solaris-8.

And you don't generally want to be running ./configure from within
a rpm specfile, so the same is true of using the rpm tools:

On machine 2 you download the tarball, the specfile, (and
any patches the rpm maintainer wants to include in the
packaged version) and run the rpm build tools on the
spec file to build a binary rpm.  

Note that http://www.rpm.org/max-rpm/s1-rpm-inside-scripts.html
says: 

"Once the %prep script has gotten everything ready for the build, the %
build script is usually somewhat anti-climactic — normally invoking 
make, maybe a configuration script, and little else. 

...

Either the commands required to build the software are simple (such as 
a single make command), or they are so unique that a macro wouldn't 
make it easier to write the script. "

In other words ./configure is not expected to be run under normal
circumstances.

The whole point of autoconf is to produce something that can
be made into a tarball that only requires "make; make install"
to compile and install.




Karl 
Free Software:  "You don't pay back, you pay forward."
 -- Robert A. Heinlein

Re: [Openvpn-devel] [PATCH] On TARGET_LINUX define _GNU_SOURCE if not defined

[David Sommerseth]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 10/03/10 18:26, Peter Stuge wrote:
> David Sommerseth wrote:
>> it's a requirement to be able to build OpenVPN on RHEL4.6.
> 
> As Alon explained, building is not the problem. autotools are used
> when preparing git source for build. This is done for every release,
> so that there is a ready-made configure script included in the
> tarball.
> 
> When building a release (or snapshot, if there are any) from such a
> tarball then autoconf is no longer relevant, it was run only when the
> tarball was created.
> 
> RHEL4.6 can easily build a release that was prepared using the most
> recent autoconf. That RHEL4.6 system doesn't need autoconf installed
> at all.
> 
> The only way autoconf on that RHEL4.6 would be relevant is if those
> RHEL4.6 systems strictly need to build directly from git source, as
> opposed to building from a prepared tarball. Is that the case?

I will get that clarified on the meeting tomorrow, as this might be a
scenario.  But to be honest, I have troubles seeing that people want to
do active development on RHEL4.6, at least do changes which require
changing autotools files or pulling down SVN or git trees.


kind regards,

David Sommerseth
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iEYEARECAAYFAkuX2PUACgkQDC186MBRfrpN2QCgn5/NRRY9Je63J6Lgx1LJVjWg
WC0AoIDf6ZCBo3ulh3K1JakEnL8u+zXa
=adty
-END PGP SIGNATURE-

Re: [Openvpn-devel] [PATCH] On TARGET_LINUX define _GNU_SOURCE if not defined

[Peter Stuge]

Peter Stuge wrote:
> RHEL4.6 can easily build a release that was prepared using the most
> recent autoconf.

In fact, I would suggest that using the newest autotools when
creating the package makes it *more* likely to build effortlessly
on older systems.


//Peter

Re: [Openvpn-devel] [PATCH] On TARGET_LINUX define _GNU_SOURCE if not defined

[Alon Bar-Lev]

I will try to explain again.

You have two roles of environments:

1. Developer/packager workstation.

2. Target environment.

For example, 1 would be my computer, and 2 would be the old redhat computer.

You go to (1) and do:
$ autoreconf -ivf
$ ./configure && make dist

Now, you transfer the tarball to users, the old redhat computer is one
of them. The tarball will work WITHOUT ANY AUTOCONF/AUTOMAKE/LIBTOOL
installed.

I use older environments as (2) such as solaris-8.

If you don't believe me try it out.

Alon.

On Wed, Mar 10, 2010 at 7:14 PM, David Sommerseth
 wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 10/03/10 18:03, Alon Bar-Lev wrote:
>> On Wed, Mar 10, 2010 at 6:50 PM, David Sommerseth
>>  wrote:
>>> I'm willing to accept patches with updates as long as it don't break the
>>> oldest version OpenVPN need to support (autotools/autoconf v2.59).  If
>>> it can be built an old RHEL4.6 installation, it's good enough for James,
>>> according to the last meeting.
>>
>> This is the root cause of the mistake.
>> You don't have any dependency in the versions of
>> autoconf/automake/libtool at target machine.
>> These tools are used at the packager machine in order to generate
>> whatever needed in order to successfully compile on target machine.
>> So there is no need to support old versions of these tools.
>> The decent versions are >=autoconf-2.60 >=automake-1.10 >=libtool-1.5.26
>>
>
> Well, I wish it was as easy as just to update everything to decent
> versions of autotools.  But the fact is that it's a requirement to be
> able to build OpenVPN on RHEL4.6.  I am not in a position to move that
> requirement now.
>
> [root@localhost ~]# cat /etc/redhat-release
> Red Hat Enterprise Linux AS release 4 (Nahant Update 6)
> [root@localhost ~]# rpm -q autoconf automake libtool
> autoconf-2.59-5
> automake-1.9.2-3
> libtool-1.5.6-4.EL4.2
>
> If it really makes sense to support building on a ~2 year old RHEL4 base
> installation, that's a completely different question.  But that's the
> reality I need to work within right now.
>
>
> kind regards,
>
> David Sommerseth
>
>
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.4.10 (GNU/Linux)
> Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/
>
> iEYEARECAAYFAkuX04IACgkQDC186MBRfrockACfai1otkAjPZZ46Pcdfd99a+VT
> Z90An20IVCpEFeHGRTaKq1H5YswtUUm0
> =ukuX
> -END PGP SIGNATURE-
>

Re: [Openvpn-devel] [PATCH] On TARGET_LINUX define _GNU_SOURCE if not defined

[David Sommerseth]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 10/03/10 18:03, Alon Bar-Lev wrote:
> On Wed, Mar 10, 2010 at 6:50 PM, David Sommerseth
>  wrote:
>> I'm willing to accept patches with updates as long as it don't break the
>> oldest version OpenVPN need to support (autotools/autoconf v2.59).  If
>> it can be built an old RHEL4.6 installation, it's good enough for James,
>> according to the last meeting.
> 
> This is the root cause of the mistake.
> You don't have any dependency in the versions of
> autoconf/automake/libtool at target machine.
> These tools are used at the packager machine in order to generate
> whatever needed in order to successfully compile on target machine.
> So there is no need to support old versions of these tools.
> The decent versions are >=autoconf-2.60 >=automake-1.10 >=libtool-1.5.26
> 

Well, I wish it was as easy as just to update everything to decent
versions of autotools.  But the fact is that it's a requirement to be
able to build OpenVPN on RHEL4.6.  I am not in a position to move that
requirement now.

[root@localhost ~]# cat /etc/redhat-release
Red Hat Enterprise Linux AS release 4 (Nahant Update 6)
[root@localhost ~]# rpm -q autoconf automake libtool
autoconf-2.59-5
automake-1.9.2-3
libtool-1.5.6-4.EL4.2

If it really makes sense to support building on a ~2 year old RHEL4 base
installation, that's a completely different question.  But that's the
reality I need to work within right now.


kind regards,

David Sommerseth


-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iEYEARECAAYFAkuX04IACgkQDC186MBRfrockACfai1otkAjPZZ46Pcdfd99a+VT
Z90An20IVCpEFeHGRTaKq1H5YswtUUm0
=ukuX
-END PGP SIGNATURE-

Re: [Openvpn-devel] [PATCH] On TARGET_LINUX define _GNU_SOURCE if not defined

[David Sommerseth]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 10/03/10 17:42, Alon Bar-Lev wrote:
> This is not the way to do it.
> 
> Use AC_USE_SYSTEM_EXTENSIONS in autoconf, which detects libc settings.
> 
> The current autoconf shape is poor, long ago I offered James to
> rewrite it but he refused. I only made it partially work for cross
> compile.
> 
> There are a lot of none standard/best practice stuff there.
> 
> I did fix automake stuff... :)

Thanks a lot for the feedback!  I am interested in getting this sorted
out.  I'm setting up a RHEL4 box which will be used to check the
lower-end of the autoconf version, which is James' concern about
modifying the current autoconf scripts.

Trust me, I want to fix this issue and get it right. but I'm no big
autoconf expert so all helpful advices are most welcome!

I'm willing to accept patches with updates as long as it don't break the
oldest version OpenVPN need to support (autotools/autoconf v2.59).  If
it can be built an old RHEL4.6 installation, it's good enough for James,
according to the last meeting.

We have also this other update hanging around on the mailing list (cross
compile fixes) which I've not had time to look at yet, which also will
do some updates here as well.


kind regards,

David Sommerseth



> On Wed, Mar 10, 2010 at 2:14 PM, David Sommerseth
>  wrote:
>>
> On 10/03/10 11:49, David Sommerseth wrote:
 From: David Sommerseth 

 This is to include peercred support on hosts where _GNU_SOURCE is not
 defined by default.  This issue has been found on Gentoo with glibc-2.8.

 The solution was discussed on the IRC meeting March 4, 2010
 in #openvpn-discussions.
 

 Signed-off-by: David Sommerseth 
 ---
  syshead.h |4 
  1 files changed, 4 insertions(+), 0 deletions(-)

> 
> This is the "Gentoo patch", modified to be more generic.  In the IRC
> meeting I said I would try to make this change only in socket.c, but
> that was not possible.
> 
> TARGET_LINUX is defined in config.h, and not available before syshead.h
> is included, as that is a wrapper which either includes config.h or
> config-win32.h, depending on OS.  Further defining _GNU_SOURCE after
> including syshead.h would not make any difference at all, as it needs to
> be defined before sys/socket.h is loaded.
> 
> Therefore, I'd prefer a second review on this patch.
> 
> 
> kind regards,
> 
> David Sommerseth
> 
>>
-
--
Download Intel Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iEYEARECAAYFAkuXze8ACgkQDC186MBRfrpnMwCgprwvSqOD2aponWxp/Li8/Mg2
kJEAn3T/6k/PNQmbctTuB9ZJ8rO6kFWW
=dMKb
-END PGP SIGNATURE-

Re: [Openvpn-devel] [PATCH] On TARGET_LINUX define _GNU_SOURCE if not defined

[Alon Bar-Lev]

This is not the way to do it.

Use AC_USE_SYSTEM_EXTENSIONS in autoconf, which detects libc settings.

The current autoconf shape is poor, long ago I offered James to
rewrite it but he refused. I only made it partially work for cross
compile.

There are a lot of none standard/best practice stuff there.

I did fix automake stuff... :)

Alon.

On Wed, Mar 10, 2010 at 2:14 PM, David Sommerseth
 wrote:
>
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 10/03/10 11:49, David Sommerseth wrote:
> > From: David Sommerseth 
> >
> > This is to include peercred support on hosts where _GNU_SOURCE is not
> > defined by default.  This issue has been found on Gentoo with glibc-2.8.
> >
> > The solution was discussed on the IRC meeting March 4, 2010
> > in #openvpn-discussions.
> > 
> >
> > Signed-off-by: David Sommerseth 
> > ---
> >  syshead.h |    4 
> >  1 files changed, 4 insertions(+), 0 deletions(-)
> >
>
> This is the "Gentoo patch", modified to be more generic.  In the IRC
> meeting I said I would try to make this change only in socket.c, but
> that was not possible.
>
> TARGET_LINUX is defined in config.h, and not available before syshead.h
> is included, as that is a wrapper which either includes config.h or
> config-win32.h, depending on OS.  Further defining _GNU_SOURCE after
> including syshead.h would not make any difference at all, as it needs to
> be defined before sys/socket.h is loaded.
>
> Therefore, I'd prefer a second review on this patch.
>
>
> kind regards,
>
> David Sommerseth
>
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.4.10 (GNU/Linux)
> Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/
>
> iEYEARECAAYFAkuXjQsACgkQDC186MBRfrorFQCePuxnsCBq3pIcPJ3mG1zZO2Y9
> 4FAAniyfy82e0vJhep0TUvQeI+7nzZsr
> =bTNV
> -END PGP SIGNATURE-
>
> --
> Download Intel Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> ___
> Openvpn-devel mailing list
> Openvpn-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] [PATCH] On TARGET_LINUX define _GNU_SOURCE if not defined

[David Sommerseth]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 10/03/10 11:49, David Sommerseth wrote:
> From: David Sommerseth 
> 
> This is to include peercred support on hosts where _GNU_SOURCE is not
> defined by default.  This issue has been found on Gentoo with glibc-2.8.
> 
> The solution was discussed on the IRC meeting March 4, 2010
> in #openvpn-discussions.
> 
> 
> Signed-off-by: David Sommerseth 
> ---
>  syshead.h |4 
>  1 files changed, 4 insertions(+), 0 deletions(-)
> 

This is the "Gentoo patch", modified to be more generic.  In the IRC
meeting I said I would try to make this change only in socket.c, but
that was not possible.

TARGET_LINUX is defined in config.h, and not available before syshead.h
is included, as that is a wrapper which either includes config.h or
config-win32.h, depending on OS.  Further defining _GNU_SOURCE after
including syshead.h would not make any difference at all, as it needs to
be defined before sys/socket.h is loaded.

Therefore, I'd prefer a second review on this patch.


kind regards,

David Sommerseth

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iEYEARECAAYFAkuXjQsACgkQDC186MBRfrorFQCePuxnsCBq3pIcPJ3mG1zZO2Y9
4FAAniyfy82e0vJhep0TUvQeI+7nzZsr
=bTNV
-END PGP SIGNATURE-