[ANNOUNCE] VDR developer version 1.3.49

  Am Samstag April 29 2006 12:38 schrieb Prakash Punnoor:
> attached patch fixes that vdr (the executable and the static lib libpsi)
> get compiled with fPIC. Only shared libs need PIC, thus add this flag only
> when building plug-ins. Furthermore I added -g and -Wall to CFLAGS, as
> well, because of reasons of symmetry.

Updated patch: I forgot to add -g -Wall to Make.conf.template...
  

Prakash Punnoor wrote:
> Am Samstag April 29 2006 12:38 schrieb Prakash Punnoor:
>> attached patch fixes that vdr (the executable and the static lib libpsi)
>> get compiled with fPIC. Only shared libs need PIC, thus add this flag only
>> when building plug-ins. Furthermore I added -g and -Wall to CFLAGS, as
>> well, because of reasons of symmetry.

Did I miss this posting?

> Updated patch: I forgot to add -g -Wall to Make.conf.template...
> ...

Too late for version 1.4.0 - will look into this later.

Or does this patch fix an actual problem?

Klaus
  

Am Samstag April 29 2006 13:57 schrieb Klaus Schmidinger:
> Prakash Punnoor wrote:
> > Am Samstag April 29 2006 12:38 schrieb Prakash Punnoor:
> >> attached patch fixes that vdr (the executable and the static lib libpsi)
> >> get compiled with fPIC. Only shared libs need PIC, thus add this flag
> >> only when building plug-ins. Furthermore I added -g and -Wall to CFLAGS,
> >> as well, because of reasons of symmetry.
>
> Did I miss this posting?

Don't know. Should be posted to the list.

>
> > Updated patch: I forgot to add -g -Wall to Make.conf.template...
> > ...
>
> Too late for version 1.4.0 - will look into this later.
>
> Or does this patch fix an actual problem?

Well, I don't think compiling too much code as PIC will cause problems (apart 
from (minor) possible performance lost), nevertheless it is unneeded.
  

On Sat, Apr 29, 2006 at 12:46:34PM +0200, Prakash Punnoor wrote:

Hello,

is there a way to set the FLAGS for vdr/libsi/plugins separetly in
Make.config ?

Thank,
  

Prakash Punnoor wrote:
> Am Samstag April 29 2006 13:57 schrieb Klaus Schmidinger:
>> Prakash Punnoor wrote:
>>> Am Samstag April 29 2006 12:38 schrieb Prakash Punnoor:
>>>> attached patch fixes that vdr (the executable and the static lib libpsi)
>>>> get compiled with fPIC. Only shared libs need PIC, thus add this flag
>>>> only when building plug-ins. Furthermore I added -g and -Wall to CFLAGS,
>>>> as well, because of reasons of symmetry.
>> Did I miss this posting?
> 
> Don't know. Should be posted to the list.

Did anybody else receive that posting?
If so, can you please forward a copy to me?

>>> Updated patch: I forgot to add -g -Wall to Make.conf.template...
>>> ...
>> Too late for version 1.4.0 - will look into this later.
>>
>> Or does this patch fix an actual problem?
> 
> Well, I don't think compiling too much code as PIC will cause problems (apart 
> from (minor) possible performance lost), nevertheless it is unneeded.

Is that "compile time" or "runtime" performance?

Apparently PIC is only available on special processors, especially
*not* Intel, so I can't test this myself.

Let's wait with this until after version 1.4.

Klaus
  

On Sat, Apr 29, 2006 at 03:37:17PM +0200, Klaus Schmidinger wrote:
> Prakash Punnoor wrote:
> >Am Samstag April 29 2006 13:57 schrieb Klaus Schmidinger:
> >>Prakash Punnoor wrote:
> >>>Am Samstag April 29 2006 12:38 schrieb Prakash Punnoor:
> >>>>attached patch fixes that vdr (the executable and the static lib libpsi)
> >>>>get compiled with fPIC. Only shared libs need PIC, thus add this flag
> >>>>only when building plug-ins. Furthermore I added -g and -Wall to CFLAGS,
> >>>>as well, because of reasons of symmetry.
> >>Did I miss this posting?
> >
> >Don't know. Should be posted to the list.
> 
> Did anybody else receive that posting?
> If so, can you please forward a copy to me?

I bounced my copy of it to you.  It was only partially archived
(no text content):

http://www.linuxtv.org/pipermail/vdr/2006-April/009133.html

	Marko
  

Am Samstag April 29 2006 15:37 schrieb Klaus Schmidinger:
> Prakash Punnoor wrote:
> > Am Samstag April 29 2006 13:57 schrieb Klaus Schmidinger:
> >> Prakash Punnoor wrote:
> >>> Am Samstag April 29 2006 12:38 schrieb Prakash Punnoor:
> >>>> attached patch fixes that vdr (the executable and the static lib
> >>>> libpsi) get compiled with fPIC. Only shared libs need PIC, thus add
> >>>> this flag only when building plug-ins. Furthermore I added -g and
> >>>> -Wall to CFLAGS, as well, because of reasons of symmetry.
> >>
> >> Did I miss this posting?
> >
> > Don't know. Should be posted to the list.
>
> Did anybody else receive that posting?
> If so, can you please forward a copy to me?

You don't need it. There wasn't anything more written than in the second 
updated post. ;-)

> > Well, I don't think compiling too much code as PIC will cause problems
> > (apart from (minor) possible performance lost), nevertheless it is
> > unneeded.
>
> Is that "compile time" or "runtime" performance?

Runtime - you lose one register. In fact it would perhaps be nice to 
offer "optimizing" flags, as well (perhaps in the template, comented out or 
alike), which don't put in debug symbols (no -g) and also 
pass -fomit-frame-pointer (making one more register available, at least on 
x86).

> Apparently PIC is only available on special processors, especially
> *not* Intel, so I can't test this myself.

??? PIC = position independent code. You already *are* compiling everything 
PIC - which is not needed. Only for shared libs it is [well x86 can live with 
non-PIC, but x86_64 cannot for example], as I pointed out. You could also 
check the gcc manual on fPIC.

So my patch shouldn't break anything *additional*. But your Makefile as such 
is not very portable, as the gcc man states PIC is not everywhere available. 
For more portability one needs to check whether -fPIC is supported on the 
platform/arch and then activate where needed. Therefore eg. things like 
libtool exists...

But of course you can postpone the patch, as it is not critical.
  

Prakash Punnoor wrote:
> Runtime - you lose one register. In fact it would perhaps be nice to 
> offer "optimizing" flags, as well (perhaps in the template, comented out or 
> alike), which don't put in debug symbols (no -g) and also 
> pass -fomit-frame-pointer (making one more register available, at least on 
> x86).

I'm sure there is enough high level stuff you can optimize in vdr
before you need to worry about registers or compiler flags. IMO
thinking about whether -fPIC hurts the vdr executable is waste of
time. The trend goes to position independent exectuables anyways
btw.

> [...]
> So my patch shouldn't break anything *additional*. But your Makefile as such 
> is not very portable, as the gcc man states PIC is not everywhere available. 
> For more portability one needs to check whether -fPIC is supported on the 
> platform/arch and then activate where needed. Therefore eg. things like 

It compiles on all SUSE supported architectures. Whether it works, I
don't know. It doesn't matter anyways, I seriously doubt anyone is
going to plug a dvb card into a s390 to use vdr with it :-)

cu
Ludwig
  

I demand that Klaus Schmidinger may or may not have written...

[snip]
> Apparently PIC is only available on special processors, especially *not*
> Intel, [...]

False. You need -fPIC for libraries on ARM, which means that you need it on
XScale - and that's an Intel processor...
  

Prakash Punnoor wrote:
> Am Samstag April 29 2006 13:57 schrieb Klaus Schmidinger:
>> Prakash Punnoor wrote:
>>> Am Samstag April 29 2006 12:38 schrieb Prakash Punnoor:
>>>> attached patch fixes that vdr (the executable and the static lib libpsi)
>>>> get compiled with fPIC. Only shared libs need PIC, thus add this flag
>>>> only when building plug-ins. Furthermore I added -g and -Wall to CFLAGS,
>>>> as well, because of reasons of symmetry.
>> Did I miss this posting?
> 
> Don't know. Should be posted to the list.

Meanwhile I've received the original mail.
Apparently it was stuck at arcor-online.net:

Received: from mail-in-09.arcor-online.net (mail-in-09.arcor-online.net [151.189.21.49])
	by raven.cadsoft.de (8.13.3/8.13.3) with ESMTP id k3TJx0wh016969
	for <Klaus.Schmidinger@cadsoft.de>; Sat, 29 Apr 2006 21:59:00 +0200
Received: from mail-in-07-z2.arcor-online.net (mail-in-07-z2.arcor-online.net [151.189.8.19])
	by mail-in-09.arcor-online.net (Postfix) with ESMTP id 459B9267B83;
	Sat, 29 Apr 2006 12:38:40 +0200 (CEST)

Presumably the problem was that you CC'd me...

From: Prakash Punnoor <prakash@punnoor.de>
To: vdr@linuxtv.org
Subject: Re: [vdr] [ANNOUNCE] VDR developer version 1.3.49
Date: Sat, 29 Apr 2006 12:38:42 +0200
Cc: Klaus Schmidinger <Klaus.Schmidinger@cadsoft.de>

...so the mailing list software didn't send me a copy.
Please don't CC me - I am subscribed to the list ;-)

Klaus
  

I annunce an update channelscan and sysinfo plugin,

channelscan changelog:

2006-04-30: Version 0.1.0
- Update APIVERSION Makefile
- Minor release change because it's ready for vdr-1.4 (test with vdr-1.4.49)



sysinfo changelog:

2006-04-30: Version 0.1.0
- Update APIVERSION Makefile
- Minor release change because it's ready for vdr-1.4 (test with vdr-1.4.49)


It's a ready from download at: www.kikko77.altervista.org
  

Darren Salt wrote:
> I demand that Klaus Schmidinger may or may not have written...
> 
> [snip]
>> Apparently PIC is only available on special processors, especially *not*
>> Intel, [...]
> 
> False. You need -fPIC for libraries on ARM, which means that you need it on
> XScale - and that's an Intel processor...

I looked up the -fPIC option in "Using and Porting GNU CC",
version 2.95, where it says on page 110:

   "This option makes a difference on the m68k, m88k, and the Sparc."

Well, that manual is a little old, so maybe that information is outdated...

Klaus
  

On Sonntag 30 April 2006 10:50, Klaus Schmidinger wrote:
> Darren Salt wrote:
> > I demand that Klaus Schmidinger may or may not have written...
> >
> > [snip]
> >
> >> Apparently PIC is only available on special processors, especially *not*
> >> Intel, [...]
> >
> > False. You need -fPIC for libraries on ARM, which means that you need it
> > on XScale - and that's an Intel processor...
>
> I looked up the -fPIC option in "Using and Porting GNU CC",
> version 2.95, where it says on page 110:
>
>    "This option makes a difference on the m68k, m88k, and the Sparc."
>
> Well, that manual is a little old, so maybe that information is outdated...
>
> Klaus

the same hint is still included in the manpage of "gcc (GCC) 4.0.2"

       -fPIC
           If supported for the target machine, emit position-independent
           code, suitable for dynamic linking and avoiding any limit on the
          size of the global offset table.  This option makes a difference on
          the m68k, PowerPC and SPARC.
          Position-independent code requires special support, and therefore
          works only on certain machines.

i my idea is likewise that it doesn't care on Intel systems.

Greets 
Jörg Wendel

> _______________________________________________
> vdr mailing list
> vdr@linuxtv.org
> http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
  

Am Sonntag April 30 2006 11:06 schrieb Jörg Wendel:
> On Sonntag 30 April 2006 10:50, Klaus Schmidinger wrote:
> > Darren Salt wrote:
> > > I demand that Klaus Schmidinger may or may not have written...
> > >
> > > [snip]
> > >
> > >> Apparently PIC is only available on special processors, especially
> > >> *not* Intel, [...]
> > >
> > > False. You need -fPIC for libraries on ARM, which means that you need
> > > it on XScale - and that's an Intel processor...
> >
> > I looked up the -fPIC option in "Using and Porting GNU CC",
> > version 2.95, where it says on page 110:
> >
> >    "This option makes a difference on the m68k, m88k, and the Sparc."
> >
> > Well, that manual is a little old, so maybe that information is
> > outdated...
> >
> > Klaus
>
> the same hint is still included in the manpage of "gcc (GCC) 4.0.2"
>
>        -fPIC
>            If supported for the target machine, emit position-independent
>            code, suitable for dynamic linking and avoiding any limit on the
>           size of the global offset table.  This option makes a difference
> on the m68k, PowerPC and SPARC.
>           Position-independent code requires special support, and therefore
>           works only on certain machines.
>
> i my idea is likewise that it doesn't care on Intel systems.

Nope, you must read "This option makes a difference on the m68k, PowerPC and 
SPARC." in contrast to -fpic. -fPIC results to same code as -fpic on x86.
  

On Sunday 30 April 2006 11:06, Jörg Wendel wrote:
> On Sonntag 30 April 2006 10:50, Klaus Schmidinger wrote:
> > Darren Salt wrote:
> > > I demand that Klaus Schmidinger may or may not have written...
> > >
> > > [snip]
> > >
> > >> Apparently PIC is only available on special processors, especially
> > >> *not* Intel, [...]
> > >
> > > False. You need -fPIC for libraries on ARM, which means that you need
> > > it on XScale - and that's an Intel processor...
> >
> > I looked up the -fPIC option in "Using and Porting GNU CC",
> > version 2.95, where it says on page 110:
> >
> >    "This option makes a difference on the m68k, m88k, and the Sparc."
> >
> > Well, that manual is a little old, so maybe that information is
> > outdated...
> >
> > Klaus
>
> the same hint is still included in the manpage of "gcc (GCC) 4.0.2"
>
>        -fPIC
>            If supported for the target machine, emit position-independent
>            code, suitable for dynamic linking and avoiding any limit on the
>           size of the global offset table.  This option makes a difference
> on the m68k, PowerPC and SPARC.
>           Position-independent code requires special support, and therefore
>           works only on certain machines.
>
> i my idea is likewise that it doesn't care on Intel systems.
>

PIC does(!) make a change on Intel systems, too.

PIC = Position Independant Code
That means the compiler will not assamble absolute jumps but create a table 
with addresses to use indirect address lookup.

For a better description have a look at: 
http://www.gentoo.org/proj/en/hardened/pic-guide.xml
and
http://www.gentoo.org/proj/en/hardened/pic-internals.xml

Greetings
Matthias
  

Klaus Schmidinger wrote:

>   "This option makes a difference on the m68k, m88k, and the Sparc."

> Well, that manual is a little old, so maybe that information is
> outdated...


It seems to be a little bit outdated. amd64 and ia64 require -fPIC for
shared libs too. That's why the Debian policy requires all shared libs
to be compiled with -fPIC. There are only a few architectures, that
support shared non-relocatable code. That's i386 and maybe anonther one.
All other architecures require -fPIC.

Tobias
  

> 
> sysinfo changelog:
> 
> 2006-04-30: Version 0.1.0
> - Update APIVERSION Makefile
> - Minor release change because it's ready for vdr-1.4 (test with
> vdr-1.4.49)

References to DVBDIR should also be removed from the plugin Makefiles.

BR.
  

tinconn@virgilio.it wrote:
> I annunce an update channelscan and sysinfo plugin,
> 
> channelscan changelog:
> 
> 2006-04-30: Version 0.1.0
> - Update APIVERSION Makefile
> - Minor release change because it's ready for vdr-1.4 (test with 
> vdr-1.4.49)

WOW! ;-)

Klaus
  

I speak from the future :-)

I meant to say :
"- Minor release change because it's ready for vdr-1.4 (test with 
vdr-1.3.49)"



Klaus Schmidinger ha scritto:
> tinconn@virgilio.it wrote:
>> I annunce an update channelscan and sysinfo plugin,
>>
>> channelscan changelog:
>>
>> 2006-04-30: Version 0.1.0
>> - Update APIVERSION Makefile
>> - Minor release change because it's ready for vdr-1.4 (test with 
>> vdr-1.4.49)
>
> WOW! ;-)
>
> Klaus
>
> _______________________________________________
> vdr mailing list
> vdr@linuxtv.org
> http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
>
  

Prakash Punnoor wrote:
> Am Samstag April 29 2006 12:38 schrieb Prakash Punnoor:
>> attached patch fixes that vdr (the executable and the static lib libpsi)
>> get compiled with fPIC. Only shared libs need PIC, thus add this flag only
>> when building plug-ins. Furthermore I added -g and -Wall to CFLAGS, as
>> well, because of reasons of symmetry.
> 
> Updated patch: I forgot to add -g -Wall to Make.conf.template...
> 
> diff -urd vdr-1.3.49/libsi/Makefile vdr-1.3.49.n/libsi/Makefile
> --- vdr-1.3.49/libsi/Makefile	2005-05-29 13:47:12.000000000 +0200
> +++ vdr-1.3.49.n/libsi/Makefile	2006-04-29 12:13:59.000000000 +0200
> @@ -6,7 +6,7 @@
>  ### The C++ compiler and options:
>  
>  CXX      ?= g++
> -CXXFLAGS ?= -fPIC -O2 -g -Wall -Woverloaded-virtual
> +CXXFLAGS ?= -O2 -g -Wall -Woverloaded-virtual
>  AR = ar
>  ARFLAGS = ru
>  RANLIB = ranlib
> diff -urd vdr-1.3.49/Make.config.template vdr-1.3.49.n/Make.config.template
> --- vdr-1.3.49/Make.config.template	2006-04-15 14:28:03.000000000 +0200
> +++ vdr-1.3.49.n/Make.config.template	2006-04-29 12:41:21.000000000 +0200
> @@ -11,10 +11,10 @@
>  ### The C compiler and options:
>  
>  CC       = gcc
> -CFLAGS   = -O2
> +CFLAGS   = -g -O2 -Wall
>  
>  CXX      = g++
> -CXXFLAGS = -fPIC -g -O2 -Wall -Woverloaded-virtual
> +CXXFLAGS = -g -O2 -Wall -Woverloaded-virtual
>  
>  ### The directory environment:
>  
> diff -urd vdr-1.3.49/Makefile vdr-1.3.49.n/Makefile
> --- vdr-1.3.49/Makefile	2006-04-24 19:18:06.000000000 +0200
> +++ vdr-1.3.49.n/Makefile	2006-04-29 12:33:23.000000000 +0200
> @@ -9,10 +9,10 @@
>  .DELETE_ON_ERROR:
>  
>  CC       ?= gcc
> -CFLAGS   ?= -O2
> +CFLAGS   ?= -g -O2 -Wall
>  
>  CXX      ?= g++
> -CXXFLAGS ?= -fPIC -g -O2 -Wall -Woverloaded-virtual
> +CXXFLAGS ?= -g -O2 -Wall -Woverloaded-virtual
>  
>  LSIDIR   = ./libsi
>  MANDIR   = /usr/local/man

Ok, I'll do this for maintenance patch 1.4.0-2.

> @@ -175,6 +175,8 @@
>  # Plugins:
>  
>  plugins: include-dir
> +	CFLAGS="-fPIC $(CFLAGS)"
> +	CXXFLAGS="-fPIC $(CXXFLAGS)"
>  	@failed="";\
>  	noapiv="";\
>  	for i in `ls $(PLUGINDIR)/src | grep -v '[^a-z0-9]'`; do\

Why would this be necessary? The plugins' Makefiles already contain

CXXFLAGS ?= -fPIC -g -O2 -Wall -Woverloaded-virtual

Klaus
  

Am Freitag Mai 26 2006 12:44 schrieb Klaus Schmidinger:
> Prakash Punnoor wrote:
>
> > @@ -175,6 +175,8 @@
> >  # Plugins:
> >
> >  plugins: include-dir
> > +	CFLAGS="-fPIC $(CFLAGS)"
> > +	CXXFLAGS="-fPIC $(CXXFLAGS)"
> >  	@failed="";\
> >  	noapiv="";\
> >  	for i in `ls $(PLUGINDIR)/src | grep -v '[^a-z0-9]'`; do\
>
> Why would this be necessary? The plugins' Makefiles already contain
>
> CXXFLAGS ?= -fPIC -g -O2 -Wall -Woverloaded-virtual

Ideally you are right. The plugins should add the flag themselves. But if you 
don't want to trust them, this would be a way to make sure. So it's your 
choice. ;-)
  

tinconn@virgilio.it wrote:
> I annunce an update channelscan and sysinfo plugin,

It seems that channelscan does not know how to select
correct diseqc-port.
It only works if diseqc-switch is allready somehow switched
to correct satellite.
Sort of chicken-egg syndrome.