Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > alt.os.linux.slackware > #25377 > unrolled thread

newbie installation question

Back to article view | Back to alt.os.linux.slackware

Contents

  newbie installation question  "Michael Blanc" <mblanc@sonic.net> - 2015-08-17 20:01 -0700
    Re: newbie installation question Henrik Carlqvist <Henrik.Carlqvist@deadspam.com> - 2015-08-18 05:27 +0000
      Re: newbie installation question "Michael Blanc" <mblanc@sonic.net> - 2015-08-18 04:54 -0700
        Re: newbie installation question Henrik Carlqvist <Henrik.Carlqvist@deadspam.com> - 2015-08-25 06:17 +0000
          Re: newbie installation question Ralph Spitzner <rasp@spitzner.org> - 2015-08-26 09:40 +0200
          Re: newbie installation question "Michael Blanc" <mblanc@sonic.net> - 2015-08-26 04:51 -0700
            Re: newbie installation question Henrik Carlqvist <Henrik.Carlqvist@deadspam.com> - 2015-08-26 18:18 +0000
          Re: Newsserver (was: newbie installation question) Chick Tower <c.tower@deadspam.com> - 2015-08-26 18:03 +0000
            Re: Newsserver (was: newbie installation question) Henrik Carlqvist <Henrik.Carlqvist@deadspam.com> - 2015-08-26 18:08 +0000
              Re: Newsserver (was: newbie installation question) Chick Tower <c.tower@deadspam.com> - 2015-08-28 02:23 +0000
                Re: Newsserver (was: newbie installation question) Henrik Carlqvist <Henrik.Carlqvist@deadspam.com> - 2015-08-28 05:34 +0000
    Re: newbie installation question JohnF <john@please.see.sig.for.email.com> - 2015-08-19 02:16 +0000
      Re: newbie installation question Rich <rich@example.invalid> - 2015-08-19 10:16 +0000
      Re: newbie installation question Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2015-08-19 10:40 -0400
        Re: newbie installation question JohnF <john@please.see.sig.for.email.com> - 2015-08-20 05:35 +0000

#25377 — newbie installation question

Actually, two questions.

I have the latest DVD distribution, v 14.1. The target machine is a somewhat
older dell laptop model D630. Now its processor is a dual core Intel model
T7100, which should appear to support 64-bit operation. But the installation
procedure from the 64-bit side of the DVD would not work. No messages, no
diagnostics. The install menu would just return to the main level as if
nothing had happened, which nothing had.

First question: how and where are the criteria explained to determine if
a machine will aupport a 32-bit vrs a 64-bit installation? Is there a
diagnostic on the DVD which will plumb a machine's internals and tell you?
Where do you look up these particulars?

The 32-bit installation did go through without a flaw. Windoze (XP-Pro, the
least
bad version ever) had already been installed. Linux was allowed a sufficient
partition
which became the bootable one. LILO is there.  The default kernel reports
its version
as 3.10.17, via the uname command.

I wouldn't even be making an inquiry here except for this

Second question: if my machine will in fact support 64-bit operation, then I
want the gcc compiler to utilize a native integer of that size. Otherwise I
am fine with the present installation.

Advice?

[toc] | [next] | [standalone]

#25378

On Mon, 17 Aug 2015 20:01:44 -0700, Michael Blanc wrote:
> The target machine is a somewhat older dell laptop model D630. Now its
> processor is a dual core Intel model T7100, which should appear to
> support 64-bit operation. But the installation procedure from the 64-
> bit side of the DVD would not work. No messages, no diagnostics. The
> install menu would just return to the main level as if nothing had
> happened, which nothing had.

If I remember right, when trying to install 64 bit Slackware on a machine 
which lacks 64 bit support you will get an error in the beginning when 
the kernel tries to load. If you have seen the login prompt and the blue 
Slackware setup menu the problem is probably not lack of 64 bit support 
in the CPU.

What does the output from lscpu say? Do you get a line looking like this:

CPU op-mode(s):        32-bit, 64-bit

?

If the avobe commands says you have a 64 bit CPU I would guess that your 
installation media is broken. Do you see any scratches on the DVD?

On the other hand, unless your laptop have more than 4 GB of RAM you 
probably won't have any benefit from running a 64 bit kernel.
 
> Second question: if my machine will in fact support 64-bit operation,
> then I want the gcc compiler to utilize a native integer of that size.
> Otherwise I am fine with the present installation.

Why a 64 bit native int? If your code wan't or need some 64 bit integers, 
declare them as long long int.

regards Henrik
-- 
The address in the header is only to prevent spam. My real address is:
hc351(at)poolhem.se Examples of addresses which go to spammers:
root@localhost postmaster@localhost

[toc] | [prev] | [next] | [standalone]

#25379

"Henrik Carlqvist" <Henrik.Carlqvist@deadspam.com> wrote in message 
news:55d2c258$0$302$14726298@news.sunsite.dk...

> What does the output from lscpu say? Do you get a line looking like this:
>
> CPU op-mode(s):        32-bit, 64-bit
>
> ?

lscpu indeed gives exactly that line in its reply. I had been (sheepishly) 
unaware of that command.

>
> If the avobe commands says you have a 64 bit CPU I would guess that your
> installation media is broken. Do you see any scratches on the DVD?
>

Nothing I noticed. The 64-bit side of the DVD did boot and run the system. 
It is readable.

> On the other hand, unless your laptop have more than 4 GB of RAM you
> probably won't have any benefit from running a 64 bit kernel.
>

Good point. I have no need for 64 lines of address.

>
> Why a 64 bit native int? If your code wan't or need some 64 bit integers,
> declare them as long long int.
>

But what does long long do with a 64-bit int? I was hoping for 128.

> regards Henrik
> -- 

and many thanks!

- mb

[toc] | [prev] | [next] | [standalone]

#25410

Sorry for my late reply, my news server has been down for a long time, I 
have not switched to another news server.

On Tue, 18 Aug 2015 04:54:02 -0700, Michael Blanc wrote:
> But what does long long do with a 64-bit int? I was hoping for 128.

I did a quick test on my 64 bit Slackware 13.1 installation:

-8<-----------------------------------
minotaur:/tmp> cat long_long.c
#include <stdio.h>

int main(int argc, char **argv)
{
   long long l;
   printf("A long long is %d bytes\n", sizeof(l));
   return 0;
}
minotaur:/tmp> gcc -o long_long long_long.c
minotaur:/tmp> file long_long
long_long: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), 
dynamically linked (uses shared libs), not stripped
minotaur:/tmp> ./long_long
A long long is 8 bytes
-8<-----------------------------------

So, no, 8 bytes means that a long long is only 64 bits also on 64 bit 
Linux. The C99 standard says that a long long should be at least 64 bits.

regards Henrik
-- 
The address in the header is only to prevent spam. My real address is:
hc351(at)poolhem.se Examples of addresses which go to spammers:
root@localhost postmaster@localhost

[toc] | [prev] | [next] | [standalone]

#25415

Henrik Carlqvist wrote:

> So, no, 8 bytes means that a long long is only 64 bits also on 64 bit
> Linux. The C99 standard says that a long long should be at least 64 bits.
>
> regards Henrik
>

C99 is 64 bits, however:
http://stackoverflow.com/questions/16088282/is-there-a-128-bit-integer-in-gcc


     -rasp




-- 
Mostly harmless...
        -Douglas Adams

[toc] | [prev] | [next] | [standalone]

#25416

Thanks for looking into this. Now just out of curiosity, what would be 
sizeof(int) and sizeof(long)? If this is a 64-bit system, then don't you 
suppose that at least one of those should be eight bytes? Shouldn't the 
native integer be that size, perhaps with an appropriate compiler switch?

-mb

"Henrik Carlqvist" <Henrik.Carlqvist@deadspam.com> wrote in message 
news:mrh19t$qcg$1@dont-email.me...
> Sorry for my late reply, my news server has been down for a long time, I
> have not switched to another news server.
>
> On Tue, 18 Aug 2015 04:54:02 -0700, Michael Blanc wrote:
>> But what does long long do with a 64-bit int? I was hoping for 128.
>
> I did a quick test on my 64 bit Slackware 13.1 installation:
>
> -8<-----------------------------------
> minotaur:/tmp> cat long_long.c
> #include <stdio.h>
>
> int main(int argc, char **argv)
> {
>   long long l;
>   printf("A long long is %d bytes\n", sizeof(l));
>   return 0;
> }
> minotaur:/tmp> gcc -o long_long long_long.c
> minotaur:/tmp> file long_long
> long_long: ELF 64-bit LSB executable, x86-64, version 1 (SYSV),
> dynamically linked (uses shared libs), not stripped
> minotaur:/tmp> ./long_long
> A long long is 8 bytes
> -8<-----------------------------------
>
> So, no, 8 bytes means that a long long is only 64 bits also on 64 bit
> Linux. The C99 standard says that a long long should be at least 64 bits.
>
> regards Henrik
> -- 
> The address in the header is only to prevent spam. My real address is:
> hc351(at)poolhem.se Examples of addresses which go to spammers:
> root@localhost postmaster@localhost
> 

[toc] | [prev] | [next] | [standalone]

#25419

On Wed, 26 Aug 2015 04:51:00 -0700, Michael Blanc wrote:
> Now just out of curiosity, what would be sizeof(int) and sizeof(long)?'
> If this is a 64-bit system, then don't you suppose that at least one of
> those should be eight bytes? Shouldn't the native integer be that size,
> perhaps with an appropriate compiler switch?

Yet another quick test:

-8<-----------------------------------
minotaur:/tmp> cat sizes.c
#include <stdio.h>

int main(int argc, char **argv)
{
   printf("A long long is %d bytes\n", sizeof(long long));
   printf("A long is %d bytes\n", sizeof(long));
   printf("An int is %d bytes\n", sizeof(int));
   printf("A short is %d bytes\n", sizeof(short));
   printf("A char is %d bytes\n", sizeof(char));
   return 0;
}
minotaur:/tmp> gcc -o sizes sizes.c
minotaur:/tmp> file sizes
sizes: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically 
linked (uses shared libs), not stripped
minotaur:/tmp> ./sizes
A long long is 8 bytes
A long is 8 bytes
An int is 4 bytes
A short is 2 bytes
A char is 1 bytes
-8<-----------------------------------

I am not aware of any switches which changes this behaviour, but google 
is your friend...

regards Henrik
-- 
The address in the header is only to prevent spam. My real address is:
hc351(at)poolhem.se Examples of addresses which go to spammers:
root@localhost postmaster@localhost

[toc] | [prev] | [next] | [standalone]

#25417 — Re: Newsserver (was: newbie installation question)

On 2015-08-25, Henrik Carlqvist <Henrik.Carlqvist@deadspam.com> wrote:
> Sorry for my late reply, my news server has been down for a long time, I 
> have not switched to another news server.

Was that news.sunsite.dk?  I get nothing from it now.
-- 
                                 Chick Tower

For e-mail:  aols2 DOT sent DOT towerboy AT xoxy DOT net

[toc] | [prev] | [next] | [standalone]

#25418 — Re: Newsserver (was: newbie installation question)

On Wed, 26 Aug 2015 18:03:37 +0000, Chick Tower wrote:

> On 2015-08-25, Henrik Carlqvist <Henrik.Carlqvist@deadspam.com> wrote:
>> Sorry for my late reply, my news server has been down for a long time,
>> I have not switched to another news server.
> 
> Was that news.sunsite.dk?  I get nothing from it now.

Yes it was, also www.dotsrc.org seems down (if I understand things right 
dotsrc.org hosted news.sunsite.dk). I have now switched to eternal-
september.org

regards Henrik
-- 
The address in the header is only to prevent spam. My real address is:
hc351(at)poolhem.se Examples of addresses which go to spammers:
root@localhost postmaster@localhost

[toc] | [prev] | [next] | [standalone]

#25432 — Re: Newsserver (was: newbie installation question)

On 2015-08-26, Henrik Carlqvist <Henrik.Carlqvist@deadspam.com> wrote:
> On Wed, 26 Aug 2015 18:03:37 +0000, Chick Tower wrote:
>
>> On 2015-08-25, Henrik Carlqvist <Henrik.Carlqvist@deadspam.com> wrote:
>>> Sorry for my late reply, my news server has been down for a long time,
>>> I have not switched to another news server.
>> 
>> Was that news.sunsite.dk?  I get nothing from it now.
>
> Yes it was, also www.dotsrc.org seems down (if I understand things right 
> dotsrc.org hosted news.sunsite.dk).

It seems to have been back up today (27Aug15), Henrik.
-- 
                                 Chick Tower

For e-mail:  aols2 DOT sent DOT towerboy AT xoxy DOT net

[toc] | [prev] | [next] | [standalone]

#25434 — Re: Newsserver (was: newbie installation question)

On Fri, 28 Aug 2015 02:23:53 +0000, Chick Tower wrote:
> It seems to have been back up today (27Aug15), Henrik.

When trying a webbrowser to www.dotsrc.org it now seems to be down again.
However, so far for me eternal-september.org seems to work fine as a 
usenet news provider. Even if sunsite.dk/dotsrc.org comes back I really 
see no reason to switch back.

Thanks for the info anyway!

regards Henrik
-- 
The address in the header is only to prevent spam. My real address is:
hc351(at)poolhem.se Examples of addresses which go to spammers:
root@localhost postmaster@localhost

[toc] | [prev] | [next] | [standalone]

#25380

Michael Blanc <mblanc@sonic.net> wrote:
> Actually, two questions.
> <snipped first question>
> I wouldn't even be making an inquiry here except for this
> Second question: if my machine will in fact support 64-bit operation, then I
> want the gcc compiler to utilize a native integer of that size. Otherwise I
> am fine with the present installation.
> Advice?

The posters in comp.lang.c may be able to answer better.
Try one of the gcc -switches like -m64, although that won't
quite do exactly what you're asking. Maybe one of the -mtune=CPU
switches (maybe not). If you're writing your own code, I'd try
explicitly using int64_t, or introduce your own typedef (or #define).
Or you could edit /usr/include/stdint.h which already has 32-bit
typedef's for int and unsigned int, and change them to 64-bit. 
But that last idea's probably not recommended.
-- 
John Forkosh  ( mailto:  j@f.com  where j=john and f=forkosh )

[toc] | [prev] | [next] | [standalone]

#25381

JohnF <john@please.see.sig.for.email.com> wrote:
> Michael Blanc <mblanc@sonic.net> wrote:
> > Actually, two questions.
> > <snipped first question>
> > I wouldn't even be making an inquiry here except for this
> > Second question: if my machine will in fact support 64-bit
> > operation, then I want the gcc compiler to utilize a native integer
> > of that size. Otherwise I am fine with the present installation.
> > Advice?

> The posters in comp.lang.c may be able to answer better. Try one of
> the gcc -switches like -m64, although that won't quite do exactly
> what you're asking. Maybe one of the -mtune=CPU switches (maybe not).
> If you're writing your own code, I'd try explicitly using int64_t, or
> introduce your own typedef (or #define). Or you could edit
> /usr/include/stdint.h which already has 32-bit typedef's for int and
> unsigned int, and change them to 64-bit.  But that last idea's
> probably not recommended.

That last one is definitely not recommended if you want portable code.

If you really want your ints to be a specific size, then compile in C99
mode, include stdint.h, and use one of the standard, fixed size
typedefs provided by stdint.h.

https://en.wikibooks.org/wiki/C_Programming/C_Reference/stdint.h#Integer_types

Then you get 64bit ints, and portable code (at least to another C99
compiler) at the same time.

[toc] | [prev] | [next] | [standalone]

#25382

On Tuesday August 18 2015 22:16, in alt.os.linux.slackware, "JohnF"
<john@please.see.sig.for.email.com> wrote:

> Michael Blanc <mblanc@sonic.net> wrote:
>> Actually, two questions.
>> <snipped first question>
>> I wouldn't even be making an inquiry here except for this
>> Second question: if my machine will in fact support 64-bit operation, then
>> I want the gcc compiler to utilize a native integer of that size. Otherwise
>> I am fine with the present installation.
>> Advice?
> 
> The posters in comp.lang.c may be able to answer better.

Typically, comp.lang.c tries to stay away from compiler-specific questions.
Mostly, they concentrate on the proper use of the C /language/, and direct
questions about specific compilers to their proper support groups.

In other words, be prepared to be flamed if you ask about GCC compiler
switches or options in comp.lang.c

> Try one of the gcc -switches like -m64, although that won't
> quite do exactly what you're asking. Maybe one of the -mtune=CPU
> switches (maybe not). If you're writing your own code, I'd try
> explicitly using int64_t, or introduce your own typedef (or #define).
> Or you could edit /usr/include/stdint.h which already has 32-bit
> typedef's for int and unsigned int, and change them to 64-bit.

Nope. That's not going to help.

> But that last idea's probably not recommended.

Not recommended, because it won't help at all.

The contents of system include files are not "switches that can be tweaked".
Instead, they are "system constants". Changing the definition of <<uint32_t>
in <stdint.h> won't change the compiler's understanding of the size of such
an integer, but /will/ cause your program to incorrectly allocate the
requisite space for such integers.

-- 
Lew Pitcher
"In Skills, We Trust"
PGP public key available upon request

[toc] | [prev] | [next] | [standalone]

#25383

Lew Pitcher <lew.pitcher@digitalfreehold.ca> wrote:
> On Tuesday August 18 2015 22:16, in alt.os.linux.slackware, "JohnF"
> <john@please.see.sig.for.email.com> wrote:
>> Michael Blanc <mblanc@sonic.net> wrote:
>>> Actually, two questions.
>>> <snipped first question>
>>> I wouldn't even be making an inquiry here except for this
>>> Second question: if my machine will in fact support 64-bit operation, then
>>> I want the gcc compiler to utilize a native integer of that size. Otherwise
>>> I am fine with the present installation.
>>> Advice?
> 
>> Try one of the gcc -switches like -m64, although that won't
>> quite do exactly what you're asking. Maybe one of the -mtune=CPU
>> switches (maybe not). If you're writing your own code, I'd try
>> explicitly using int64_t, or introduce your own typedef (or #define).
>> Or you could edit /usr/include/stdint.h which already has 32-bit
>> typedef's for int and unsigned int, and change them to 64-bit.
> 
> Nope. That's not going to help.
> 
>> But that last idea's probably not recommended.
> 
> Not recommended, because it won't help at all.
(and probably not recommended even if it would've helped)
> 
> The contents of system include files are not "switches that can be tweaked".
> Instead, they are "system constants". Changing the definition of <<uint32_t>
> in <stdint.h> won't change the compiler's understanding of the size of such
> an integer, but /will/ cause your program to incorrectly allocate the
> requisite space for such integers.

Thanks for the info; I hadn't realized that (probably mostly because
I'd never try such a thing myself, or I'd have already learned that
the hard way long ago).
-- 
John Forkosh  ( mailto:  j@f.com  where j=john and f=forkosh )

[toc] | [prev] | [standalone]

Back to top | Article view | alt.os.linux.slackware

csiph-web