2007-08-16, 10:27
FFS.
use the build script. you are obviously in dire need of it
use the build script. you are obviously in dire need of it
2007-08-16, 13:33
Just so people know...
between the time the FC6 patch was built and when it was committed, other changes to configure.in were made that require liblzo to be present during the configure step.
My changes moved to liblzo2 as it was on my system and I could not find a liblzo for FC6.
Anyway, the quick fix is to go into configure.in and comment out the line that looks for liblzo and errors our. Then run autoconf, and then re-run ./configure
It should find liblzo2 and you should be good to make
between the time the FC6 patch was built and when it was committed, other changes to configure.in were made that require liblzo to be present during the configure step.
My changes moved to liblzo2 as it was on my system and I could not find a liblzo for FC6.
Anyway, the quick fix is to go into configure.in and comment out the line that looks for liblzo and errors our. Then run autoconf, and then re-run ./configure
It should find liblzo2 and you should be good to make
2007-08-16, 13:44
oh,
i thought your stuff checked for both and used whichever was avail (i'm rather ignorant on autotools..)
any chance it could be made to work that way ? (i assume so)
i thought your stuff checked for both and used whichever was avail (i'm rather ignorant on autotools..)
any chance it could be made to work that way ? (i assume so)
2007-08-16, 14:15
spiff Wrote:oh,
i thought your stuff checked for both and used whichever was avail (i'm rather ignorant on autotools..)
any chance it could be made to work that way ? (i assume so)
It can, and did, until a check was made to force the existence of liblzo. It's not a big deal, I'll make a quick change later today and supply the patch.
It also look like my change to the libPython/linux/Makefile didn't get it either (libpython2.4-pic doesn't exist on FC6. That is likely my error as I may not have included it in the first patch. I'll try and resolve that as well.
2007-08-16, 14:29
spiff Wrote:i thought it would be obvious from the context that i'm refering to my new anti-ferret firewall code.Which presumably is not required in the state of California?
http://www.geocities.com/Yosemite/7379/2118.html#must
2007-08-16, 17:29
well then, make yourself useful. figure out why, submit a patch.
if you're not capable of that have been wasting all of our time AND broken the freaking forums description / rules.
if you're not capable of that have been wasting all of our time AND broken the freaking forums description / rules.
2007-08-16, 19:46
tssgery Wrote:It can, and did, until a check was made to force the existence of liblzo. It's not a big deal, I'll make a quick change later today and supply the patch.
It also look like my change to the libPython/linux/Makefile didn't get it either (libpython2.4-pic doesn't exist on FC6. That is likely my error as I may not have included it in the first patch. I'll try and resolve that as well.
Patch 1775631 has been submitted for review and [hopeful] inclusion
2007-08-16, 21:33
liblzo2 has complete backwards compatibility with liblzo, so there should be no problems there. Maybe we should just require liblzo2 instead?
The only problem I can see with blindly using libpython2.4.a over libpython2.4-pic.a is the off chance it wasn't built with -fPIC. Being as it is a shared library it *should* be compiled this way, but this isn't to say that someone could build without it or that some binary distribution is built without it. Someone with more experience than me would have to say one way or the other as to what this would affect in XBMC. Other than that I have yet to find a way to determine what cflags libpython2.4.a is built with, it doesn't appear to use pkg-config
The only problem I can see with blindly using libpython2.4.a over libpython2.4-pic.a is the off chance it wasn't built with -fPIC. Being as it is a shared library it *should* be compiled this way, but this isn't to say that someone could build without it or that some binary distribution is built without it. Someone with more experience than me would have to say one way or the other as to what this would affect in XBMC. Other than that I have yet to find a way to determine what cflags libpython2.4.a is built with, it doesn't appear to use pkg-config
2007-08-16, 21:46
althekiller Wrote:liblzo2 has complete backwards compatibility with liblzo, so there should be no problems there. Maybe we should just require liblzo2 instead?
The only problem I can see with blindly using libpython2.4.a over libpython2.4-pic.a is the off chance it wasn't built with -fPIC. Being as it is a shared library it *should* be compiled this way, but this isn't to say that someone could build without it or that some binary distribution is built without it. Someone with more experience than me would have to say one way or the other as to what this would affect in XBMC. Other than that I have yet to find a way to determine what cflags libpython2.4.a is built with, it doesn't appear to use pkg-config
I would definitely prefer to rely upon liblzo2 everywhere, but I'm just a small guy in a big world.
As to libpython2.4-pic.a, my most recent patch (just submitted, but not committed) prefers the pic version but will fall back if necessary. It is also my assumption that -fPIC was used but as you say... you never know.
2007-08-16, 23:09
cheers tss.
i will apply this on sunday if nobody beats me to it. i'm severely drunk atm and dont dare go near svn and i'm going to a festival in the weekend.
i will apply this on sunday if nobody beats me to it. i'm severely drunk atm and dont dare go near svn and i'm going to a festival in the weekend.
