"Spacen Jasset" <spacenjasset@yahoo.co.uk> wrote in message news:ipe1ar$1e1f$1@digitalmars.com...
>
> I don't know about any of that. All I say is software was built on Centos 3 and it runs on the then company I was working for supported platforms.
>
> Which is redhat 3,4,5 + and Suse 9.something + That is 32bit and 64 bit by the way too.
>
> It also runs on ubuntu (since about version 6ish +, upto 10, and I dare say beyond) and fedora, but rekon it hasn't been tried recently on Fedora 14 as it's not a supported platform. This all happens from one binary compiled on Centos 3
>
>
> There was a bug, that I had to fix, and that was a crash on something like Redhat 4, because at the time libc was being statically linked. I can't remember the syscall that caused problem now, I have a feeling it was BSD sockets related.
>
> libc is designed to be forward compatible only, if you dynamically link it. The symbols within are versioned and the correct ones bound at runtime.
>
> I pipe up about all this because I've been though it all, and did not understand at the time what was wrong with static linking, but then you see the difference between Posix type platforms and windows, and what libc *actually is*, then it all makes sense.

I'm having a rediculously hard time trying to find a CentOS 3 installation disc image (or any other version before 5.6). This is the closest I've been able to find:

http://mirrors.cmich.edu/centos/3.1/

But I don't see anything in any of those directories that looks remotely like a disc image. Even though the chart on this page seems to say that mirror should have them:

http://www.centos.org/modules/tinycontent/index.php?id=30

On this page...

http://isoredirect.centos.org/centos/4/isos/i386/

...it *says* that that I can "download the .torrent files provided", but there's no torrent files listed there or at the mirrors, and the only other promising-looking link that page has is here:

http://packages.sw.be/bittorrent/

Which, despite the url, doesn't even have any torrents at all, just a bunch of rpms. How's a torrent client supposed to use an rpm?

I seem to remember having pretty much the same problem about a year ago when I blew a full day trying to get ahold of a copy of Debian. Eventually I gave up trying to find it and just went back to Ubuntu.

I don't have a problem using VirtualBox for this if I need to (Assuming I can actually get ahold of an appropriate OS). I actually quite like VirtualBox; been using it a lot the past year, and I have plenty of disk space. But, if all I need to do is get my app to link againt an older version of libc, shouldn't there be a way to do that right there on my Kubuntu 10.04 system?

I had been shying away from Alexander's suggestion of uClibc because uClibc's website says it sacrifices speed for size, and because it looks like a royal pain to get set up. But if I can't get this CentOS solution to work, I may give it a try anyway.

Also, I've found on Google that the message I got ("linux.so.2: bad ELF interpreter: No such file or directory") is known to sometimes occur when running a 32-bit binary on a 64-bit system that doesn't have the 32-bit libs installed. In case that turns out to be my real problem and my webhosts are unwilling to install the 32-bit libs, can DMD still output 64-bit binaries when building on a 32-bit system? My guess would be "no" since linux seems enjoy crapping out when trying to compile for anything but the local system.

On 29.04.2011 22:02, Nick Sabalausky wrote:

> I had been shying away from Alexander's suggestion of uClibc because uClibc's website says it sacrifices speed for size, and because it looks like a royal pain to get set up.

  I am not sure that you would really notice speed difference - but it depends on your application. If you only use it for file/socket I/O, you will hardly notice anything, everything else is in Phobos, thus, independent on libc.

  Setting it up, in my experience, is quite easy - but, to be honest, I didn't try it recently, my last experience with uClibc was few years ago. Perhaps, I should try it again...

/Alexander

"Alexander" <aldem+dmars@nk7.net> wrote in message news:ipfhnu$194o$1@digitalmars.com...
> On 29.04.2011 22:02, Nick Sabalausky wrote:
>
>> I had been shying away from Alexander's suggestion of uClibc because uClibc's website says it sacrifices speed for size, and because it looks like a royal pain to get set up.
>
>  I am not sure that you would really notice speed difference - but it
> depends on your application. If you only use it for file/socket I/O, you
> will hardly notice anything, everything else is in Phobos, thus,
> independent on libc.
>

Yea, you're probably right.

>  Setting it up, in my experience, is quite easy - but, to be honest, I
> didn't try it recently, my last experience with uClibc was few years ago.
> Perhaps, I should try it again...
>

According to the FAQ, they used to support a way that you could use your existing GCC toolchain to build uClibc apps, but that turned out to have fundamental problems, so now the only way to do it is with a whole separate specially-built-for-uClibc version of GCC. And from what I can tell, linux (and just "the unix way" in general) doesn't seem to be very good at handling multiple forks of the same program installed on the same system (unless you use a heretical portable-installation approach like DMD thankfully uses).

I see... Well, then, perhaps, you may get lucky with this tool: http://statifier.sourceforge.net/

/Alexander

On 29/04/2011 21:02, Nick Sabalausky wrote:
...

> I'm having a rediculously hard time trying to find a CentOS 3 installation
> disc image (or any other version before 5.6). This is the closest I've been
> able to find:
>
...

It seems that the older versions that are no longer supported have generally speaking been removed for download. So I guess you would have to use the latest supported version, or find the version you need somewhere. I have some old .iso images I think.

It would be quite handy to know what the oldest platform you need to support is, then you can "simply" get that distribution.

Anyway for redhat, that appears to be version 4. http://ftp.heanet.ie/pub/centos/4.9/isos/


Since previous versions are no longer supported, then none *should* really be using those versions as there are no security updates any more.

There goes the logic anyway.

I will have a look for an older .iso image that may be useful. What you don't want to do is download something, which is too new a glibc

Alexander wrote:

> On 29.04.2011 11:41, Spacen Jasset wrote:
> 
>> You still *cannot* link statically to kernel32.dll. That's the difference. Linux glibc contains the C library functions *and* the syscalls, which is the bit that causes the problems.
> 
>   But at least I know, that no matter where I am, as long as I am using
>   kernel32 only (no more dependencies), it will work on *any* Windows
>   system (obviously, keeping backward compatibility in mind - something
>   compiled on WinXP will work on all later
> versions) - which is not he case of Linux/glibc, unfortunately.
> 
>> msvcrt.dll and msvcrt.lib don't have any syscalls in them. they call though kernel32.dll dynamically.
> 
>   Actually, they do. Calling kernel32 is like making a syscall, that's the
>   base of Win32 API, which is equivalent of Linux syscall.

A syscall is generally understood to be a call into the kernel for doing something that can't be done with user level privileges. So a call is either a syscall or it isn't, and none of kernel32 are. There are even functions in kernel32 which do not make a syscall.

On 03.05.2011 16:29, Lutger Blijdestijn wrote:

> A syscall is generally understood to be a call into the kernel for doing something that can't be done with user level privileges.

  Not really. syscalls are interface of user space to the OS kernel, and obviously, they can be made with user level privileges, otherwise nothing would be possible :)

  From the Linux syscalls manpage: "The system call is the fundamental interface between an application and the Linux kernel."

> So a call is either a syscall or it isn't, and none of kernel32 are.

  kernel32 provides Win32 API, which is exactly (from application point of view) what syscalls in Linux are. In turn, kernel32 is interfacing to ntdll, which is near direct interface to the kernel.

> There are even functions in kernel32 which do not make a syscall.

  Sure, not all of Win32 API functions require syscalls. But again: "In lots of cases, KERNEL32 APIs are just wrappers to NTDLL APIs."

  Unlike kernel32, though, libc is providing direct interface to syscalls - like open(), socket() etc. - yes, those are not libc functions, those are syscalls (wrapped a bit to follow C calling convention).

  Probably, nowadays libc has wrappers around syscalls, checking arguments etc - but those are not necessary, the difference is only in calling convention.

/Alexander

"Nick Sabalausky" <a@a.a> wrote in message news:ipf5pg$j80$1@digitalmars.com...
> "Spacen Jasset" <spacenjasset@yahoo.co.uk> wrote in message news:ipe1ar$1e1f$1@digitalmars.com...
>>
>> I don't know about any of that. All I say is software was built on Centos 3 and it runs on the then company I was working for supported platforms.
>>
>> Which is redhat 3,4,5 + and Suse 9.something + That is 32bit and 64 bit by the way too.
>>
>> It also runs on ubuntu (since about version 6ish +, upto 10, and I dare say beyond) and fedora, but rekon it hasn't been tried recently on Fedora 14 as it's not a supported platform. This all happens from one binary compiled on Centos 3
>>
>>
>> There was a bug, that I had to fix, and that was a crash on something like Redhat 4, because at the time libc was being statically linked. I can't remember the syscall that caused problem now, I have a feeling it was BSD sockets related.
>>
>> libc is designed to be forward compatible only, if you dynamically link it. The symbols within are versioned and the correct ones bound at runtime.
>>
>> I pipe up about all this because I've been though it all, and did not understand at the time what was wrong with static linking, but then you see the difference between Posix type platforms and windows, and what libc *actually is*, then it all makes sense.
>
> I'm having a rediculously hard time trying to find a CentOS 3 installation disc image (or any other version before 5.6). This is the closest I've been able to find:
>
> http://mirrors.cmich.edu/centos/3.1/
>
> But I don't see anything in any of those directories that looks remotely like a disc image. Even though the chart on this page seems to say that mirror should have them:
>
> http://www.centos.org/modules/tinycontent/index.php?id=30
>
> On this page...
>
> http://isoredirect.centos.org/centos/4/isos/i386/
>
> ...it *says* that that I can "download the .torrent files provided", but there's no torrent files listed there or at the mirrors, and the only other promising-looking link that page has is here:
>
> http://packages.sw.be/bittorrent/
>
> Which, despite the url, doesn't even have any torrents at all, just a bunch of rpms. How's a torrent client supposed to use an rpm?
>
> I seem to remember having pretty much the same problem about a year ago when I blew a full day trying to get ahold of a copy of Debian. Eventually I gave up trying to find it and just went back to Ubuntu.
>
> I don't have a problem using VirtualBox for this if I need to (Assuming I can actually get ahold of an appropriate OS). I actually quite like VirtualBox; been using it a lot the past year, and I have plenty of disk space. But, if all I need to do is get my app to link againt an older version of libc, shouldn't there be a way to do that right there on my Kubuntu 10.04 system?
>
> I had been shying away from Alexander's suggestion of uClibc because uClibc's website says it sacrifices speed for size, and because it looks like a royal pain to get set up. But if I can't get this CentOS solution to work, I may give it a try anyway.
>
> Also, I've found on Google that the message I got ("linux.so.2: bad ELF interpreter: No such file or directory") is known to sometimes occur when running a 32-bit binary on a 64-bit system that doesn't have the 32-bit libs installed. In case that turns out to be my real problem and my webhosts are unwilling to install the 32-bit libs, can DMD still output 64-bit binaries when building on a 32-bit system? My guess would be "no" since linux seems enjoy crapping out when trying to compile for anything but the local system.
>

Aggghhhh!!! God damnnit, I officially fucking hate linux now... (not that I'm a win, mac or bsd fan, but whatever...)

I temporarily gave up trying to actually get ahold of an old distro, so I tried the other angles (not counting just simply *wishing* it was like win and I could just copy the damn binary over to another linux box...nooo, that would be too simple for a unix-style system):

I got my web host to switch me to a server that has 32-bit libs installed (a pain in and of itself because I had to coordinate with a client to find a convenient downtime, and then I ended up needing to change my domain's DNS entires, so now my whole domain's down for a couple days)...And it make no difference. So I guess in my particular case it wasn't a 32-bit/64-bit issue at all (or maybe there still would have been that problem too, I dunno).

So I went to try uClibc:

I started my Linux box...and it decides to hang mid-startup. So I reboot and at least this time the dumb thing finishes booting (I had problems with linux randomly breaking for no apperent reason ten years ago with Mandrake and Red Hat. I can't believe it's still happening now).

Anyway, at the uClibc site, I saw the "simple steps" here: http://uclibc.org/toolchains.html and thought "Uhh, hell no, not if I don't have to" and went to the link for the pre-built verison instead. The link was broken. Then the page says those are really old versions anyway. Great :/

So I go through the steps: I get to the part where I download buildroot. Copy/paste the link over to my linux box...and discover that Synergy+ has suddenly decided it no longer feels like offering the "shared clipboard" feature that always worked before.

Ok, so I type the URL into my linux box manually, download buildroot, unpack it...so far so good...and follow the instruction to run "make menuconfig"...BARF. It fails with some error about ncurses being missing, and that I should get ncurses-devel. "sudo apt-get install ncurses-devel": Can't find package. "sudo apt-get install ncurses": Can't find package. "sudo apt-get install fuck-shit-cock": Can't find package.

Google "ncurses deb package". Actually found it. Download. Run...You ready for this? Here's the message: "Error: A later version is already installed." SERIOUSLY?!

This is the point where I would normally say "fuck this shit", but the thought of continuing to use PHP (even if it is via Haxe) is enough to keep me bashing my head against this wall. Next stop: See if I can get ahold of *some* version of CentOS and see if using that in a VM will manage to work. (And rip Kubuntu off my Linux box and see if I can replace it with Debian+XFCE. How is it possible that GNOME and KDE were both fairly ok ten years ago, at least as far as I can remember, but the latest versions of both are complete shit? And then there's that iOS garbage that Ubuntu is moving to now (The one main thing I've always disliked about Ubuntu is their incompresensible Apple-envy, which only seems to be increasing). And fuck, the latest KDE actually makes the Win7 UI seem good (at least the Win7 UI actually *works* and has some semblance of consistency, even as obnoxious as it is), and I could have sworn that KDE never used to be so completely broken before. Or broken at all, for that matter. Which is too bad, because Dolphin actually shows some promise...at least when it isn't doing the random-horizontal-scrolling-for-no-apparent-reason dance.)

"Nick Sabalausky" <a@a.a> wrote in message news:iq2g72$ngp$1@digitalmars.com...
>
> Aggghhhh!!! God damnnit, I officially fucking hate linux now... (not that I'm a win, mac or bsd fan, but whatever...)
>
> I temporarily gave up trying to actually get ahold of an old distro, so I tried the other angles (not counting just simply *wishing* it was like win and I could just copy the damn binary over to another linux box...nooo, that would be too simple for a unix-style system):
>
> I got my web host to switch me to a server that has 32-bit libs installed (a pain in and of itself because I had to coordinate with a client to find a convenient downtime, and then I ended up needing to change my domain's DNS entires, so now my whole domain's down for a couple days)...And it make no difference. So I guess in my particular case it wasn't a 32-bit/64-bit issue at all (or maybe there still would have been that problem too, I dunno).
>
> So I went to try uClibc:
>
> I started my Linux box...and it decides to hang mid-startup. So I reboot and at least this time the dumb thing finishes booting (I had problems with linux randomly breaking for no apperent reason ten years ago with Mandrake and Red Hat. I can't believe it's still happening now).
>
> Anyway, at the uClibc site, I saw the "simple steps" here: http://uclibc.org/toolchains.html and thought "Uhh, hell no, not if I don't have to" and went to the link for the pre-built verison instead. The link was broken. Then the page says those are really old versions anyway. Great :/
>
> So I go through the steps: I get to the part where I download buildroot. Copy/paste the link over to my linux box...and discover that Synergy+ has suddenly decided it no longer feels like offering the "shared clipboard" feature that always worked before.
>
> Ok, so I type the URL into my linux box manually, download buildroot, unpack it...so far so good...and follow the instruction to run "make menuconfig"...BARF. It fails with some error about ncurses being missing, and that I should get ncurses-devel. "sudo apt-get install ncurses-devel": Can't find package. "sudo apt-get install ncurses": Can't find package. "sudo apt-get install fuck-shit-cock": Can't find package.
>
> Google "ncurses deb package". Actually found it. Download. Run...You ready for this? Here's the message: "Error: A later version is already installed." SERIOUSLY?!
>
> This is the point where I would normally say "fuck this shit", but the thought of continuing to use PHP (even if it is via Haxe) is enough to keep me bashing my head against this wall. Next stop: See if I can get ahold of *some* version of CentOS and see if using that in a VM will manage to work. (And rip Kubuntu off my Linux box and see if I can replace it with Debian+XFCE. How is it possible that GNOME and KDE were both fairly ok ten years ago, at least as far as I can remember, but the latest versions of both are complete shit? And then there's that iOS garbage that Ubuntu is moving to now (The one main thing I've always disliked about Ubuntu is their incompresensible Apple-envy, which only seems to be increasing). And fuck, the latest KDE actually makes the Win7 UI seem good (at least the Win7 UI actually *works* and has some semblance of consistency, even as obnoxious as it is), and I could have sworn that KDE never used to be so completely broken before. Or broken at all, for that matter. Which is too bad, because Dolphin actually shows some promise...at least when it isn't doing the random-horizontal-scrolling-for-no-apparent-reason dance.)
>

Yay! I've just had some success! I managed to find this:

http://vault.centos.org/

Which has all the CentOS ISOs. (You'd think I would have had an easier time finding that URL...)

I downloaded 4.2 (picked pretty much at random), installed it in VirtualBox, compiled a trivial test C program in the included GCC, uploaded that to the server, and it worked! :)

Next step: Install DMD on this CentOS VM and try for a D cgi...

And then later, I may try 4.7, see if that'll work for me too. And I still have another web host I need to get CGI working on (although that one has some pretty bad support, so I'm a little nervous about that). But it's looking good so far. Finegrs crossed...

I'd be nice to not have to use a VM to compile, of course. But as long as I can I have some way to do my server-side web stuff in D, and *completely* sidestep the entire PHP runtime, then it'll certainly still be well worth it.

"Nick Sabalausky" <a@a.a> wrote in message news:iq60qt$pm0$1@digitalmars.com...
>
> I downloaded 4.2 (picked pretty much at random), installed it in VirtualBox, compiled a trivial test C program in the included GCC, uploaded that to the server, and it worked! :)
>

Actually, I did have to remove the HTTP status code output from my little hello world cgi test in forder for Apache to not throw up a 500. That kind of surprised me, actually. But maybe it just means it's been far too long since I've done CGI... *shrug*