GCC library generation
Ron
at the least encouraging for a 'would be' like myself.
It sounds like I will be able to make an independant
binary for RISC OS, but where there is a normally dependant
library installed (linux), where does it leave me if
the library isn't included in RISC OS !GCC.
I'm guessing, but the source for a library, would have
to be platform independant, and would get tough if there
are hardware references.
Anyone?
Happy New Year.(The novelty has worn off in NZ :-))
Ron M
Peter Naulls
> I haven't started with it yet, but the new release is
> at the least encouraging for a 'would be' like myself.
>
> It sounds like I will be able to make an independant
> binary for RISC OS, but where there is a normally dependant
> library installed (linux), where does it leave me if
> the library isn't included in RISC OS !GCC.
I think you are confusing a whole lot of different things
if by "independent" (note spelling), you mean a static
binary, that doesn't rely on other shared libraries at
run time (which is almost everything on RISC OS to date),
and probably what you want to do, then you need the -static
switch at link time.
If you're after certain libraries to use with the compiler,
well these all exist, but many we haven't yet got around
to releasing in a format sensibly usable for RISC OS native
compilation - in particular, DeskLib and OSLib. You really
need to be specific about what are you doing here.
> I'm guessing, but the source for a library, would have
> to be platform independant, and would get tough if there
> are hardware references.
Yes, but this is another matter entirely, and is what
porting is about addressing. Chances are, any library
that exists on Linux that you are immediately interested
in using already has a RISC OS port.
> Happy New Year.(The novelty has worn off in NZ :-))
> Ron M
Still 2009 here in this lagging time zone.
Ron
Peter Naulls <pe...@chocky.org> wrote:
<snip>
> I think you are confusing a whole lot of different things
> if by "independent" (note spelling), you mean a static
> binary, that doesn't rely on other shared libraries at
> run time (which is almost everything on RISC OS to date),
> and probably what you want to do, then you need the -static
> switch at link time.
>
using an associated library, (dependency) with its binary,
and that on RISC OS we can link a library into a static binary.
> If you're after certain libraries to use with the compiler,
> well these all exist, but many we haven't yet got around
> to releasing in a format sensibly usable for RISC OS native
> compilation - in particular, DeskLib and OSLib. You really
> need to be specific about what are you doing here.
>
flash drive I thought that it might be nice to have on RISC OS.
fdisk and cfdisk failed to complete the formatting process.
The two apps related would be the Iyonix debian installer,
and mkdosfs perhaps. The former needs the old video card to
run, so I havent looked at that for a while and mkdosfs looks
very old, but I haven't tried it. Parted would support more
formats in the long run, for example there are formats
suited for flash memory usage.
Re the existing ports, I check on the ports already done at
riscos.info occasionly.
I aim to try the networking speed testing client sometime.
Thanks, Ron M
Iyonix 5.14 2012 )-:
Peter Naulls
Google groups - please excuse broken formatting.
> In message <hhjgs1$kk...@news.eternal-september.org>
> Peter Naulls <pe...@chocky.org> wrote:
> <snip>> I think you are confusing a whole lot of different things
> > if by "independent" (note spelling), you mean a static
> > binary, that doesn't rely on other shared libraries at
> > run time (which is almost everything on RISC OS to date),
> > and probably what you want to do, then you need the -static
> > switch at link time.
>
> Thanks for the corrections. Yes I am referring to Linux often
> using an associated library, (dependency) with its binary,
> and that on RISC OS we can link a library into a static binary.
Yes, if you say so. Making up your own terminology is only
going to hinder your understanding of the issue, and confuse
everyone else. I think you are conflating runtime (shared
libraries) with link-time static libraries. In either case, the
Linux version is not at all suitable for use with RISC OS.
A "dependency" is way too ambiguous, and in programming
contexts would generally only refer to build targets
(e.g, in Makefiles).
>
> > If you're after certain libraries to use with the compiler,
> > well these all exist, but many we haven't yet got around
> > to releasing in a format sensibly usable for RISC OS native
> > compilation - in particular, DeskLib and OSLib. You really
> > need to be specific about what are you doing here.
>
> Having used the command line 'parted' on Linux to format a
> flash drive I thought that it might be nice to have on RISC OS.
> fdisk and cfdisk failed to complete the formatting process.
> The two apps related would be the Iyonix debian installer,
> and mkdosfs perhaps. The former needs the old video card to
> run, so I havent looked at that for a while and mkdosfs looks
> very old, but I haven't tried it. Parted would support more
> formats in the long run, for example there are formats
> suited for flash memory usage.
Right. This is actually a big hassle, since there isn't
a consistent way to access file systems on RISC OS
(but a lot more manageable if we limit to RO5), but those
programs won't understand any of those, and would need it
added, nor would they understand the ADFS partitioning
schemes. What you really want to be looking at is
'acorn-fdisk', which is the formatter used with Iyonix
Linux (when running in Linux) and also knows about ADFS
partitions, *and* has some support for running natively.
acorn-fdisk is the best basis for a "universal formatting"
that I've been going on about for years.
> I aim to try the networking speed testing client sometime.
If you mean iperf, the latest version doesn't seem to work
very well. It needs someone to take a look at it.