![](/i/fill.gif) |
![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
On Thu, 19 Jul 2012 19:39:44 +0100, Orchid Win7 v1 wrote:
> Let me see if I can figure out where I read all this... Ah yes, here we
> go:
>
> http://freegamedev.net/wiki/Portable_binaries
>
> Basically, it seems this stuff is pretty complicated. I suppose package
> managers were invented for a reason, eh? Pity I can't use one to solve
> my problem...
Well, on the flip side, glibc is common to Linux systems, so it shouldn't
be necessary to link to it.
But the simplest solution is to create a VM that has what the hosting
provider has in it - same distro and everything - and use that as the
development base for what you're working on.
Jim
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
>> Let me see if I can figure out where I read all this... Ah yes, here we
>> go:
>>
>> http://freegamedev.net/wiki/Portable_binaries
>>
>> Basically, it seems this stuff is pretty complicated. I suppose package
>> managers were invented for a reason, eh? Pity I can't use one to solve
>> my problem...
>
> Well, on the flip side, glibc is common to Linux systems, so it shouldn't
> be necessary to link to it.
Indeed. It seems you want to /not/ link anything that's ubiquitous to
all Linux systems, and to only link unusual stuff that probably won't be
there.
> But the simplest solution is to create a VM that has what the hosting
> provider has in it - same distro and everything - and use that as the
> development base for what you're working on.
Yep, that would be the simplest.
I mean, if I knew what distro they're using, what packages they've
installed, and so forth...
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
On 17/07/2012 09:03 AM, Invisible wrote:
> - Finding a web hosting company that allows arbitrary CGI /binaries/ is
> seemingly impossible.
The other possibility is to use Amazon's EC2. But it's *really* expensive!
And then I stumble on this:
http://www.heroku.com/
I've never heard of it before, but it sounds interesting. (I rather
suspect it too will end up being far too expensive...)
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
>> System: Linux infong 2.4 #1 SMP Tue Jan 17 02:58:41 UTC 2012 i686
>> GNU/Linux
>
> Strange, a 2.4 serie kernel compiled at the beginning of 2012.
> 2.6 is more mainstream, and kernel has now entered the 3.2 serie
According to some of the stuff I've read, the build system needs to be
running the same kernel as the target system (or older).
What are my chances of finding a Linux distro that still works and
offers the 2.4 kernel?
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Le 20/07/2012 12:14, Invisible a écrit :
>>> System: Linux infong 2.4 #1 SMP Tue Jan 17 02:58:41 UTC 2012 i686
>>> GNU/Linux
>>
>> Strange, a 2.4 serie kernel compiled at the beginning of 2012.
>> 2.6 is more mainstream, and kernel has now entered the 3.2 serie
>
> According to some of the stuff I've read, the build system needs to be
> running the same kernel as the target system (or older).
Not really. As an application (unless you dive into kernel structure
with root access), you practically have to have the same libc major version.
Now the itchy part: they moved from libc-5 to libc-6 during the 2.6
series (and there is a major glitch around 2.6.19 for some aspects I
just cannot remember)
It's just that compatibility of libraries is usually ascending: features
get added, so compiling against version 1.3 allows to still run on
version 1.44
Yet, major revision are allowed to break everything... sort of.
For instance, there is a certain gap between libxerces-c.2.8 and
libxerces-c.3.0 (not sure about the exact name). Some features get
dropped and some functions are gone, for real: the dynamic linker at
runtime will never find them if the new system is only installed with 3.0;
>
> What are my chances of finding a Linux distro that still works and
> offers the 2.4 kernel?
An old CD-set of slackware ?
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
>>>> System: Linux infong 2.4 #1 SMP Tue Jan 17 02:58:41 UTC 2012 i686
>>>> GNU/Linux
>>>
>>> Strange, a 2.4 serie kernel compiled at the beginning of 2012.
>>> 2.6 is more mainstream, and kernel has now entered the 3.2 serie
>>
>> According to some of the stuff I've read, the build system needs to be
>> running the same kernel as the target system (or older).
>
> Not really. As an application (unless you dive into kernel structure
> with root access), you practically have to have the same libc major version.
> Now the itchy part: they moved from libc-5 to libc-6 during the 2.6
> series (and there is a major glitch around 2.6.19 for some aspects I
> just cannot remember)
It's all Greek to me.
> It's just that compatibility of libraries is usually ascending: features
> get added, so compiling against version 1.3 allows to still run on
> version 1.44
Yeah. So basically, if I build my stuff on a system that's /older/ than
the target platform, it ought to work.
>> What are my chances of finding a Linux distro that still works and
>> offers the 2.4 kernel?
>
> An old CD-set of slackware ?
A better question: What are my chances of getting GHC, with it's vast
list of complex dependencies, to work on an ancient copy of Linux?
Yeah, exactly.
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Le 20/07/2012 18:21, Orchid Win7 v1 nous fit lire :
>> It's just that compatibility of libraries is usually ascending: features
>> get added, so compiling against version 1.3 allows to still run on
>> version 1.44
>
> Yeah. So basically, if I build my stuff on a system that's /older/ than
> the target platform, it ought to work.
Maybe... or it can fails too. What are the chance of finding libc4
library on todays system ?
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |