[Liverpool] Liverpool Digest, Vol 247, Issue 2

[Liam Devine]

Thanks for the responses guys.
> 
> 
>  Bob Ham <rah at bash.sh>
> 
>> Currently I am trying to figure out the best and most universal method
>> of detecting the host architecture for Linux distros at runtime
> 
> Use config.guess from GNU autotools.  Eg, on my system I can do the
> following:
> 
> rah at myrtle:~$ /usr/share/automake-1.11/config.guess 
> x86_64-unknown-linux-gnu
> rah at myrtle:~$ /usr/share/automake-1.11/config.guess | cut -f 1 -d -
> x86_64
> 
> Note also that for your purposes, "use" will most likely mean reading
> the source.

> Dave Love
> Do you mean GNU/Linux?  Even if you don't think much of GNU autotools,
> I'm pretty sure you won't do better for platform information than
> config.sub/config.guess, and they're not specific to Linux-based
> systems.  The autotools have a lot of hard experience behind them, and I
> guess such questions are best asked in an autoconf forum.


This has just recently been suggested to me and I am currently in the process of grokking it.


> 
>> for a couple of reasons:  To let users call out to external
>> executables depending on the arch [2]
> 
> I don't understand exactly what's required, but for building you don't
> normally care about the hardware, just what the tools target -- what
> width is a C long, not what's the addressing of the metal.
It has been requested by users and I have seen real world examples of users trying to obtain this information using a number of methods, so it would be a nice feature to add such information and make it available to users. Users can have different settings for different architectures yet the information wanted is for a 'just the host' without a user supplying such information.
I do not understand what you are getting at but as I am sure you are aware the size of a long in C is not defined by the standard yet only in relation to other types or using sizeof(long), minimum sizes LONG_MIN and LONG_MAX or figuring out which arch the system is using  ie. LP64 et al
> 
>> To set the correct location to look for libraries [3]
> 
> I don't know why you want to, but you're on to a loser if you assume
> libraries are necessarily somewhere like /usr/lib64, and especially if
> you consider non-GNU/Linux systems.  While you can, perhaps, locate
> libraries with ldd and a sample binary, ask yourself why.
> 
This is required for users to search for the libraries and if present report there locations. where these are well known locations and the results from the ld cache.  A sample binary is something we would rather not have to have if it was at all possible, the problem is that Linux has no standards for this or that it does yet distros disregard it. lib can be 32, 64 or a semlink, lib32 can be present or lib64 can plus there may also be other 'known locations'

>> My current thinking is the best method is to parse the output of
>> 'uname -m' and this method has been confirmed to me that at least on
>> one distro gives the value of a 32 bit id when a 32 bit distro is
>> installed on a 64 bit system, which is what I am looking for.
> 
> (In the absence of details,) that's not necessarily what's relevant,
> e.g.
> 
>  $ /usr/share/misc/config.guess
>  x86_64-unknown-linux-gnu
>  $ linux32 /usr/share/misc/config.guess
>  i686-pc-linux-gnu
> 

> You can't, in general, determine the target parameters with build-time
> tests; think cross-building a cross-compiler, and you may or may not
> regard `gcc -m...' as cross-compiling.

I do not understand, the first returns information that it is 64 bits and the second 32. Am I missing something here? Cross compiling I currently do not see as a problem for most of the library as the user will have provided the architecture information to the library in a script, yet in the instance of wanting to find a library this information is a help. We can search the known locations and if not found and a 64 bit host try *lib64
> 
>> The current values that I have can be seen in [4]. Are there any
>> others that are known to yourselves
> 
> Look at GCC for a start on architectures of current interest, but it
> probably misses current ones.
> 
> 
Thanks will do.

Liam

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.lug.org.uk/pipermail/liverpool/attachments/20101211/cb5d4bf7/attachment.htm>