VDR developer version 1.3.49 is now available at
ftp://ftp.cadsoft.de/vdr/Developer/vdr-1.3.49.tar.bz2
A 'diff' against the previous version is available at
ftp://ftp.cadsoft.de/vdr/Developer/vdr-1.3.48-49.diff
Well, it's an unusual time for a new developer version of VDR, but since there have been a few last minute fixes, and I really want to make version 1.4.0 happen this sunday, I'm releasing this hopefully last release candidate today.
Please take a thorough look at the changes - especially the ones to the actual program code files - to help avoid any stupid last minute bugs.
If there are no more serious bugs, this will become the final version 1.4.0 this sunday :-)
The changes since version 1.3.48:
- Fixed initializing 'noapiv' in the Makefile (reported by Ronny Kornexl). - Fixed extracting APIVERSION to work with older versions of 'sed' (reported by Oliver Endriss; thanks also to Udo Richter for a shorter version of the 'sed' expression). - Fixed broken APIVERSION extraction line in 'newplugin' (thanks to Oliver Endriss). - Fixed entering '0' in a cMenuEditIntItem (reported by Mirko Dölle). - Updated the Italian OSD texts (thanks to Nino Gerbino). - Added a note about adding 'INCLUDES += -I$(DVBDIR)/include' to an existing Make.config (problem reported by Markus Ehrnsperger). - Fixed handling the cPluginManager::Active() result when pressing the "Power" key (reported by Werner Färber). - Added a hint about commenting out the line '#define USE_FADVISE' in tools.c in case of problems with replaying in fast forward mode if the video directory is mounted via a Samba share (reported by Andy Grobb). - Changed the "Really restart?" prompt in the call to cPluginManager::Active() in menu.c to "restart anyway?" (suggested by Rolf Ahrenberg). - Removed the obsolete "'1' for encrypted radio channels" part from the description of the VPID in vdr.5 (reported by Alexander Hans). - Fixed tuning to the channel of a VPS timer if the device is the actual device.
Have fun!
Klaus
Am 28.04.2006 um 15:50 schrieb Klaus Schmidinger:
The changes since version 1.3.48:
I have the following problem: If a timer is running and i press power off on the remote, VDR shows "eine Aufzeichnung läuft, trotzdem ausschalten?". VDR Shuts down no matter if i press a key or not... Can you verify this?
Ciao, Dominique
Dominique Simon wrote:
I have the following problem: If a timer is running and i press power off on the remote, VDR shows "eine Aufzeichnung läuft, trotzdem ausschalten?". VDR Shuts down no matter if i press a key or not... Can you verify this?
Yes, there's still a logical bug in it...
The 1.3.49 code shuts down if the recording shut down is confirmed *OR* if the plugin shut down is confirmed. Unfortunately, if no plugin has activity, this counts as confirmed, so VDR will shut down no matter if recording shut down was confirmed or not.
The attached patch reverses the logic a bit, and shuts down if recordings *AND* plugins confirm. UserShutdown is set up first, so that any non-confirm can leave with 'break'. If all tests pass, ForceShutdown is set too.
I've tested all variants I can think of, and it seems to work. More testing is of course welcome, so we can mark this one fixed before Sunday.
Btw: There's a slight change in behavior since 1.3.46: Before, a simple shut down without confirms did not set ForceShutdown=true, since then, ForceShutdown is set true even if no confirmation was necessary. cPluginManager::Active does not differentiate between confirmed, denied and 'no activity'. The new way is slightly more aggressive, but seems more consistent and I don't think that it has bigger negative side effects.
(1.3.49 can shut down while cutting, 1.3.46 can shut down while cutting only if also a recording is running, and shutdown is confirmed.)
Cheers,
Udo
--- vdr-1.3.49-orig/vdr.c 2006-04-28 15:23:55.000000000 +0200 +++ vdr-1.3.49/vdr.c 2006-04-29 03:20:25.876919696 +0200 @@ -976,14 +971,15 @@ Skins.Message(mtError, tr("Can't shutdown - option '-s' not given!")); break; } - if (cRecordControls::Active()) { - if (Interface->Confirm(tr("Recording - shut down anyway?"))) - ForceShutdown = true; - } - if (!cPluginManager::Active(tr("shut down anyway?"))) - ForceShutdown = true; LastActivity = 1; // not 0, see below! UserShutdown = true; + if (cRecordControls::Active()) { + if (!Interface->Confirm(tr("Recording - shut down anyway?"))) + break; + } + if (cPluginManager::Active(tr("shut down anyway?"))) + break; + ForceShutdown = true; break; default: break; }
Am 29.04.2006 um 04:14 schrieb Udo Richter:
The 1.3.49 code shuts down if the recording shut down is confirmed *OR* if the plugin shut down is confirmed. Unfortunately, if no plugin has activity, this counts as confirmed, so VDR will shut down no matter if recording shut down was confirmed or not.
Thanks, your patch brings back the usul behavior. I used to hit the poweroff key when a recording is running and i leave the house for example, VDR used to shut down then when the timer stopped. This does not work anymore, even with your patch. Any idea how to bring this back?
Ciao, Dominique
Am 29.04.2006 um 10:40 schrieb Dominique Simon:
Thanks, your patch brings back the usul behavior. I used to hit the poweroff key when a recording is running and i leave the house for example, VDR used to shut down then when the timer stopped. This does not work anymore, even with your patch. Any idea how to bring this back?
Sorry, VDR DOES shut down when the timer stopped and you pressed the poweroff key before. So your patch works flawlessly. I entered a wrong timer stop time in my first test ;)
Ciao, Dominique
Udo Richter wrote:
Dominique Simon wrote:
I have the following problem: If a timer is running and i press power off on the remote, VDR shows "eine Aufzeichnung läuft, trotzdem ausschalten?". VDR Shuts down no matter if i press a key or not... Can you verify this?
Yes, there's still a logical bug in it...
The 1.3.49 code shuts down if the recording shut down is confirmed *OR* if the plugin shut down is confirmed. Unfortunately, if no plugin has activity, this counts as confirmed, so VDR will shut down no matter if recording shut down was confirmed or not.
The attached patch reverses the logic a bit, and shuts down if recordings *AND* plugins confirm. UserShutdown is set up first, so that any non-confirm can leave with 'break'. If all tests pass, ForceShutdown is set too.
I've tested all variants I can think of, and it seems to work. More testing is of course welcome, so we can mark this one fixed before Sunday.
Btw: There's a slight change in behavior since 1.3.46: Before, a simple shut down without confirms did not set ForceShutdown=true, since then, ForceShutdown is set true even if no confirmation was necessary. cPluginManager::Active does not differentiate between confirmed, denied and 'no activity'. The new way is slightly more aggressive, but seems more consistent and I don't think that it has bigger negative side effects.
(1.3.49 can shut down while cutting, 1.3.46 can shut down while cutting only if also a recording is running, and shutdown is confirmed.)
Thanks, looks good to me.
Since I personally don't use the shutdown feature, it's all the more important that you folks test this extensively.
While adding your patch I realized that the code formatting of the 'case kPower:' was somewhat off, too, so I shifted it to the left. The final patch now looks as attached.
I guess it's ok if I don't release another new version, it should be easy enough to apply this patch and test it thoroughly.
So we still have a GO for version 1.4.0 on Sunday :-)
Klaus
Small update to the Polish translation.
-- Jaroslaw Swierczynski swiergot@gmail.com www.archlinux.org | www.juvepoland.com
Klaus Schmidinger wrote:
VDR developer version 1.3.49 is now available at
If there are no more serious bugs, this will become the final version 1.4.0 this sunday :-)
looking through local changes, i think this is the only one obviously-correct enough -- i got +/- wrong when calculating the size; should be mostly harmless anyway (was just calling fadvise with too large area).
diff -urNp vdr-1.3.49.org/tools.c vdr-1.3.49.min/tools.c --- vdr-1.3.49.org/tools.c 2006-04-21 15:12:47.000000000 +0000 +++ vdr-1.3.49.min/tools.c 2006-04-29 09:10:26.000000000 +0000 @@ -1179,7 +1179,7 @@ ssize_t cUnbufferedFile::Read(void *Data } else if (cachedend > ahead && cachedend - curpos > READCHUNK * 2) { // current position has moved back enough, shrink head window. - FadviseDrop(curpos + READCHUNK, cachedend - curpos + READCHUNK); + FadviseDrop(curpos + READCHUNK, cachedend - (curpos + READCHUNK)); cachedend = curpos + READCHUNK; } }
Artur Skawina wrote:
Klaus Schmidinger wrote:
VDR developer version 1.3.49 is now available at
If there are no more serious bugs, this will become the final version 1.4.0 this sunday :-)
looking through local changes, i think this is the only one obviously-correct enough -- i got +/- wrong when calculating the size; should be mostly harmless anyway (was just calling fadvise with too large area).
diff -urNp vdr-1.3.49.org/tools.c vdr-1.3.49.min/tools.c --- vdr-1.3.49.org/tools.c 2006-04-21 15:12:47.000000000 +0000 +++ vdr-1.3.49.min/tools.c 2006-04-29 09:10:26.000000000 +0000 @@ -1179,7 +1179,7 @@ ssize_t cUnbufferedFile::Read(void *Data } else if (cachedend > ahead && cachedend - curpos > READCHUNK * 2) { // current position has moved back enough, shrink head window.
FadviseDrop(curpos + READCHUNK, cachedend - curpos + READCHUNK);
FadviseDrop(curpos + READCHUNK, cachedend - (curpos + READCHUNK)); cachedend = curpos + READCHUNK; } }
Can anybody else confirm that this doesn't cause any new problems? I'm afraid I can't make this change for the final 1.4.0 without extensive testing. So unless at least three others give me a GO on this one, it will have to stay out of 1.4.0.
Klaus
FadviseDrop(curpos + READCHUNK, cachedend - curpos + READCHUNK);
FadviseDrop(curpos + READCHUNK, cachedend - (curpos + READCHUNK)); cachedend = curpos + READCHUNK;Can anybody else confirm that this doesn't cause any new problems? I'm afraid I can't make this change for the final 1.4.0 without extensive testing. So unless at least three others give me a GO on this one, it will have to stay out of 1.4.0.
i don't think this really fixes any real problems, just a correctness issue :) Basically the code was trying to free a bit too much data, when playing or jumping backwards -- i doubt it matters in RL. It probably doesn't even matter when replaying an ongoing recording near the end (the only case i can think of where it actually could make noticeable difference, by forcing the new data to disk). As i said it's mostly harmless, just wanted to mention it once i got a current vdr running and before i forget about it. Certainly it doesn't deserve to hold up 1.4.0 by itself.
artur
Hi,
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.
Please apply.
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:32:33.000000000 +0200 @@ -14,7 +14,7 @@ CFLAGS = -O2
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 @@ -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\
Cheers,
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 @@ -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\
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.
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
Hi,
On Sat, 29 Apr 2006 15:37:17 +0200 Klaus Schmidinger Klaus.Schmidinger@cadsoft.de wrote:
Did anybody else receive that posting? If so, can you please forward a copy to me?
I've attached it as it's smaller than other peoples' signatures :-)
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?
Should be kind of "execution time", not exactly "runtime". It just adds a few memory remappings on application startup by updating an address lookup table. This may cause some additional memory lookups at runtime, too. Albeit I'm interested in real numbers, I'm pretty sure it won't affect performance too much.
Apparently PIC is only available on special processors, especially *not* Intel, so I can't test this myself.
Hm, it should be available on intel.
Let's wait with this until after version 1.4.
There are good reasons for doing it this way, yes.
-hwh
Am Samstag April 29 2006 15:50 schrieb Hans-Werner Hilse:
Hi,
On Sat, 29 Apr 2006 15:37:17 +0200 Klaus Schmidinger
Klaus.Schmidinger@cadsoft.de wrote:
Did anybody else receive that posting? If so, can you please forward a copy to me?
I've attached it as it's smaller than other peoples' signatures :-)
Well that patch - as I stated in the updated post - missing one minor thing. Sorry for the confusion...
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?
Should be kind of "execution time", not exactly "runtime". It just adds a few memory remappings on application startup by updating an address lookup table. This may cause some additional memory lookups at runtime, too. Albeit I'm interested in real numbers, I'm pretty sure it won't affect performance too much.
Not exactly. You have to distinguish: If you have the choice to load non-PIC or PIC shared libs (eg on x86):
PIC generally loads faster, as you don't need text relocations performed AFAIK. But PIC is generally slower on execution due to losing the ebx register (on x86) and gcc being pedantically dumb to not free it up when it could be used even in PIC mode. (There could also be security risks with non-PIC shared libs, IIRC.)
On x86-64 for example you have no choice: *shared* libs need to be PIC.
On the other hand *executables* and *static libs* (well it is a wrong term actually, they are just a little bit more than a conglomeration of object files) generally *don't* need to be PIC. But this is what current VDR Makefile does - thus (possibly) wasting performance.
I hope this clears it up. :-)
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...
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 differenceon 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 differenceon 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
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
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
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.
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 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. ;-)
Klaus Schmidinger wrote:
Please take a thorough look at the changes - especially the ones to the actual program code files - to help avoid any stupid last minute bugs.
When checking VDR with valgrind, I found a small memory leak. The attached patch should fix it.
Regards,
Tobias
--- vdr-1.3.49.orig/eit.c +++ vdr-1.3.49/eit.c @@ -104,7 +104,10 @@ cComponents *Components = NULL; for (SI::Loop::Iterator it2; (d = SiEitEvent.eventDescriptors.getNext(it2)); ) { if (ExternalData && d->getDescriptorTag() != SI::ComponentDescriptorTag) + { + delete d; continue; + } switch (d->getDescriptorTag()) { case SI::ExtendedEventDescriptorTag: { SI::ExtendedEventDescriptor *eed = (SI::ExtendedEventDescriptor *)d;
Tobias Grimm wrote:
Klaus Schmidinger wrote:
Please take a thorough look at the changes - especially the ones to the actual program code files - to help avoid any stupid last minute bugs.
When checking VDR with valgrind, I found a small memory leak. The attached patch should fix it.
Thanks - applied for version 1.4.0.
Klaus
Klaus Schmidinger wrote:
Thanks - applied for version 1.4.0.
I'm afraid I've found another minor memory leak. Valgrind would really be worth it's money, if it wouldn't be free :-)
When playing back a recording, the file handle gets closed, but not the cUnbufferedFile object. I'm not sure why a distinction is made between recording and not recording when closing the file, so I just use CloseVideoFile() in both cases, which correctly frees the object. Hope this is correct. See attached patch.
Regards,
Tobias
--- vdr-1.3.49.orig/recording.c +++ vdr-1.3.49/recording.c @@ -1436,7 +1436,7 @@ void cFileName::Close(void) { if (file) { - if ((record && CloseVideoFile(file) < 0) || (!record && file->Close() < 0)) + if (CloseVideoFile(file)) LOG_ERROR_STR(fileName); file = NULL; }
Tobias Grimm wrote:
Klaus Schmidinger wrote:
Thanks - applied for version 1.4.0.
I'm afraid I've found another minor memory leak. Valgrind would really be worth it's money, if it wouldn't be free :-)
When playing back a recording, the file handle gets closed, but not the cUnbufferedFile object. I'm not sure why a distinction is made between recording and not recording when closing the file, so I just use CloseVideoFile() in both cases, which correctly frees the object. Hope this is correct. See attached patch.
Regards,
Tobias
--- vdr-1.3.49.orig/recording.c +++ vdr-1.3.49/recording.c @@ -1436,7 +1436,7 @@ void cFileName::Close(void) { if (file) {
if ((record && CloseVideoFile(file) < 0) || (!record && file->Close() < 0))
if (CloseVideoFile(file)) LOG_ERROR_STR(fileName); file = NULL; }
The CloseVideoFile() function is the counterpart to the OpenVideoFile() function, which takes care of handling distributed video directories etc. Before the introduction of cUnbufferedFile the code in cFileName::Close() was ok, but now it would appear that your change is actually the right thing to do.
Applied for version 1.4.0.
Klaus
-
Artur Skawina -
C.Y.M -
Darren Salt -
Dominique Simon -
Gregoire Favre -
Hans-Werner Hilse -
Jaroslaw Swierczynski -
Jörg Wendel -
Klaus Schmidinger -
Lauri Tischler -
Ludwig Nussel -
Marko Mäkelä -
Matthias Schwarzott -
Prakash Punnoor -
tinconn＠virgilio.it -
Tobias Grimm -
Udo Richter