norseman wrote:
Thanks Steve, for the tips.
In a sense, I have dreaded an answer like this, as it is cold comfort
to realise that I will be hassled off my objective to take a side trip
through Linux's complexities, just so that I can play with the hardware
to evaluate if we can use it for what we want to do.
I had fondly hoped that somebody would have blazed the way
before me. But it seems not. Tough.
I will report here what I do and find - It may help some other
poor sod some day...
- Hendrik
>============== =============== =============== ======
>In case all else fails:
>
>This is not a cookbook answer, but:
1) gnu's gcc will compile to 16,32 or 64 bit intel architectures
OK, the 32 bit version compiles to 16 or 32 & the 64 should.
The 64 will run 32 bit programs, including the 32 bit gcc.
chgroot can be (messy but) useful to maintain separation.
2) info gcc and look for compiler directives
then info nasm and look for directives
same for the linker
I'm not specific because I use Slackware and different
distros can use different modules. You may have an assembler
with a different name. Switches can be different and so
forth.
>On Slackware the installpkg (for tarballs already compiled) records the
>locations of where things go in /var/log/packages. I have to assume
>other distros have something similar since these are used to remove
>things later. Can we say 'updates'? If not you will need to wade
>through the .configure and Makefiles to root out what happens to get
>'vanilla' locations.
>
>Like I said, it's not cookbook, but it will get you there and you will
>gain quite an insight into Linux. While the path may not be well marked
>in Linux, there usually is one.
>
>Sorry I don't have a more straight forward approach.
>
>- Steve
>
>In case all else fails:
>
>This is not a cookbook answer, but:
1) gnu's gcc will compile to 16,32 or 64 bit intel architectures
OK, the 32 bit version compiles to 16 or 32 & the 64 should.
The 64 will run 32 bit programs, including the 32 bit gcc.
chgroot can be (messy but) useful to maintain separation.
2) info gcc and look for compiler directives
then info nasm and look for directives
same for the linker
I'm not specific because I use Slackware and different
distros can use different modules. You may have an assembler
with a different name. Switches can be different and so
forth.
>On Slackware the installpkg (for tarballs already compiled) records the
>locations of where things go in /var/log/packages. I have to assume
>other distros have something similar since these are used to remove
>things later. Can we say 'updates'? If not you will need to wade
>through the .configure and Makefiles to root out what happens to get
>'vanilla' locations.
>
>Like I said, it's not cookbook, but it will get you there and you will
>gain quite an insight into Linux. While the path may not be well marked
>in Linux, there usually is one.
>
>Sorry I don't have a more straight forward approach.
>
>- Steve
>
In a sense, I have dreaded an answer like this, as it is cold comfort
to realise that I will be hassled off my objective to take a side trip
through Linux's complexities, just so that I can play with the hardware
to evaluate if we can use it for what we want to do.
I had fondly hoped that somebody would have blazed the way
before me. But it seems not. Tough.
I will report here what I do and find - It may help some other
poor sod some day...
- Hendrik