Build failed on latest ELKS

DISCUSSION Marc-F. LUCCA-DANIAU 3 participants 9 messages May 17, 2016 – May 20, 2016

Share & tools

Marc-F. LUCCA-DANIAU

author

2016-05-17 12:37 UTC #0 lore raw

Hello,

I just took the latest version of ELKS from Jody's GIT master branch, and I got an issue while building ELKS. I am using the "build.sh" script for the newbie I am :-)

With default configuration, build fails because the following file is malformed:
/home/mfld/advantech/elks/elks/arch/i86/drivers/char/KeyMaps/keymaps.h:
/* Automatically created - do not edit */

#include "Fichier"        /* binaire    keys-be.h correspondant */
#include "Fichier"        /* binaire    keys-de.h correspondant */
#include "Fichier"        /* binaire    keys-es.h correspondant */
#include "Fichier"        /* binaire    keys-it.h correspondant */
#include "Fichier"        /* binaire    keys-se.h correspondant */
#include "Fichier"        /* binaire    keys-uk.h correspondant */
#include "keys-dv.h"        /* DV    Dvorak       */
#include "keys-us.h"        /* US    American     */

(I am using a Gentoo configured in French, so the french strings)

This file came from the malformed Config.in:
# Automatically created - do not edit.

choice 'XT Keyboard support'            \
    "keys-be.h correspondant    CONFIG_KEYMAP_binaire    \
     keys-de.h correspondant    CONFIG_KEYMAP_binaire    \
     keys-es.h correspondant    CONFIG_KEYMAP_binaire    \
     keys-it.h correspondant    CONFIG_KEYMAP_binaire    \
     keys-se.h correspondant    CONFIG_KEYMAP_binaire    \
     keys-uk.h correspondant    CONFIG_KEYMAP_binaire    \
     Dvorak         CONFIG_KEYMAP_DV    \
     American       CONFIG_KEYMAP_US"        American

# EOF.

Error went away after changing the kernel configuration:
Select console driver: from <Direct> to <BIOS>

I am not at ease with the Config.in generation, any idea here ?

MFLD

Juan Perez-Sanchez

2016-05-17 20:15 UTC #1 lore raw

Hello,

This problem (with possible workaround) was reported in:

http://www.spinics.net/lists/linux-8086/msg00675.html

The problem is that keymap tables use "extended ascii" characters, this is, codes greater than 127, and current "make" don't like it. For example, accented a is written as 'รก' and should be written as'\341'.

This include files are C code and should use plain ascii. However, this is a lot of work.

Juan

Quoted 44 lines · Marc-F. LUCCA-DANIAU

Hello,
I just took the latest version of ELKS from Jody's GIT master branch, and I got an issue while building ELKS.
I am using the "build.sh" script for the newbie I am :-)
With default configuration, build fails because the following file is malformed:
/home/mfld/advantech/elks/elks/arch/i86/drivers/char/KeyMaps/keymaps.h:
/* Automatically created - do not edit */
#include "Fichier"        /* binaire    keys-be.h correspondant */
#include "Fichier"        /* binaire    keys-de.h correspondant */
#include "Fichier"        /* binaire    keys-es.h correspondant */
#include "Fichier"        /* binaire    keys-it.h correspondant */
#include "Fichier"        /* binaire    keys-se.h correspondant */
#include "Fichier"        /* binaire    keys-uk.h correspondant */
#include "keys-dv.h"        /* DV    Dvorak       */
#include "keys-us.h"        /* US    American     */
(I am using a Gentoo configured in French, so the french strings)
This file came from the malformed Config.in:
# Automatically created - do not edit.
choice 'XT Keyboard support'            \
    "keys-be.h correspondant    CONFIG_KEYMAP_binaire    \
     keys-de.h correspondant    CONFIG_KEYMAP_binaire    \
     keys-es.h correspondant    CONFIG_KEYMAP_binaire    \
     keys-it.h correspondant    CONFIG_KEYMAP_binaire    \
     keys-se.h correspondant    CONFIG_KEYMAP_binaire    \
     keys-uk.h correspondant    CONFIG_KEYMAP_binaire    \
     Dvorak         CONFIG_KEYMAP_DV    \
     American       CONFIG_KEYMAP_US"        American
# EOF.
Error went away after changing the kernel configuration:
Select console driver: from <Direct> to <BIOS>

Quoted 8 lines

I am not at ease with the Config.in generation, any idea here ?
MFLD
--
To unsubscribe from this list: send the line "unsubscribe linux-8086" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

--
To unsubscribe from this list: send the line "unsubscribe linux-8086" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

Marc-F. LUCCA-DANIAU

author

2016-05-18 19:37 UTC #2 lore raw

Hello Juan,

Thanks for pointing the previous report.

I guess you meant ""grep" does not like it", and octal as "0xxx" in C files, not "\xxx" as in shell.

Adding option -a to grep gives a correct Config.in, but one thing stills not clear for me:
do you know what is the code page that is supposed to be used to encode the characters in the keys-*.h ?

In the IBM PS/2 BIOS TechRef, I see no clue about this encoding, just a Keycode / ASCII table with US keyboard layout.

MFLD

Quoted 10 lines · Juan Perez-Sanchez

Hello,
This problem (with possible workaround) was reported in:
http://www.spinics.net/lists/linux-8086/msg00675.html
The problem is that keymap tables use "extended ascii" characters, this is, codes greater than 127, and current "make" don't like it. For example, accented a is written as 'á' and should be written as'\341'.

Quoted 59 lines

This include files are C code and should use plain ascii. However, this is a lot of work.
Juan
Quoted 52 lines · Marc-F. LUCCA-DANIAU
Hello,
I just took the latest version of ELKS from Jody's GIT master branch, and I got an issue while building ELKS.
I am using the "build.sh" script for the newbie I am :-)
With default configuration, build fails because the following file is malformed:
/home/mfld/advantech/elks/elks/arch/i86/drivers/char/KeyMaps/keymaps.h:
/* Automatically created - do not edit */
#include "Fichier"        /* binaire    keys-be.h correspondant */
#include "Fichier"        /* binaire    keys-de.h correspondant */
#include "Fichier"        /* binaire    keys-es.h correspondant */
#include "Fichier"        /* binaire    keys-it.h correspondant */
#include "Fichier"        /* binaire    keys-se.h correspondant */
#include "Fichier"        /* binaire    keys-uk.h correspondant */
#include "keys-dv.h"        /* DV    Dvorak       */
#include "keys-us.h"        /* US    American     */
(I am using a Gentoo configured in French, so the french strings)
This file came from the malformed Config.in:
# Automatically created - do not edit.
choice 'XT Keyboard support'            \
     "keys-be.h correspondant    CONFIG_KEYMAP_binaire    \
      keys-de.h correspondant    CONFIG_KEYMAP_binaire    \
      keys-es.h correspondant    CONFIG_KEYMAP_binaire    \
      keys-it.h correspondant    CONFIG_KEYMAP_binaire    \
      keys-se.h correspondant    CONFIG_KEYMAP_binaire    \
      keys-uk.h correspondant    CONFIG_KEYMAP_binaire    \
      Dvorak         CONFIG_KEYMAP_DV    \
      American       CONFIG_KEYMAP_US"        American
# EOF.
Error went away after changing the kernel configuration:
Select console driver: from <Direct> to <BIOS>
I am not at ease with the Config.in generation, any idea here ?
MFLD
--
To unsubscribe from this list: send the line "unsubscribe linux-8086" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

--
To unsubscribe from this list: send the line "unsubscribe linux-8086" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

Juan Perez-Sanchez

2016-05-18 20:27 UTC #3 lore raw

Hello Marc:

You are right. I should say "grep". I guess you will use the "keys-be.h" file. The arrays in the
tables in this file are unsigned char, so you would use 'a', 'b' etc for initializers. For nonprinting chars you would use '\xxx', but 0xxx works equally well.

The encoding should be plain ascii. See

http://www.cdrummond.qc.ca/cegep/informat/Professeurs/Alain/files/ascii.htm

Here, the first table is "plain ascii". The second table is the "extended ascii". The BCC compiler
ignores the extended ascii chars.

For example, in your case, the fourth char in the first table is 'é' and there is a 130 in that position of the file "keys-be.h". Replacing 'é' wilth '\202' you use only plain ascii chars.

Quoted 12 lines · Marc-F. LUCCA-DANIAU

Hello Juan,
Thanks for pointing the previous report.
I guess you meant ""grep" does not like it", and octal as "0xxx" in C files, not "\xxx" as in shell.
Adding option -a to grep gives a correct Config.in, but one thing stills not clear for me:
do you know what is the code page that is supposed to be used to encode the characters in the keys-*.h ?

Quoted 83 lines

In the IBM PS/2 BIOS TechRef, I see no clue about this encoding, just a Keycode / ASCII table with US keyboard layout.
MFLD
Quoted 73 lines · Juan Perez-Sanchez
Hello,
This problem (with possible workaround) was reported in:
http://www.spinics.net/lists/linux-8086/msg00675.html
The problem is that keymap tables use "extended ascii" characters, this is, codes greater than 127, and current "make" don't like it. For example, accented a is written as 'á' and should be written as'\341'.
This include files are C code and should use plain ascii. However, this is a lot of work.
Juan
Quoted 54 lines · Marc-F. LUCCA-DANIAU
Hello,
I just took the latest version of ELKS from Jody's GIT master branch, and I
got an issue while building ELKS.
I am using the "build.sh" script for the newbie I am :-)
With default configuration, build fails because the following file is malformed:
/home/mfld/advantech/elks/elks/arch/i86/drivers/char/KeyMaps/keymaps.h:
/* Automatically created - do not edit */
#include "Fichier"        /* binaire    keys-be.h correspondant */
#include "Fichier"        /* binaire    keys-de.h correspondant */
#include "Fichier"        /* binaire    keys-es.h correspondant */
#include "Fichier"        /* binaire    keys-it.h correspondant */
#include "Fichier"        /* binaire    keys-se.h correspondant */
#include "Fichier"        /* binaire    keys-uk.h correspondant */
#include "keys-dv.h"        /* DV    Dvorak       */
#include "keys-us.h"        /* US    American     */
(I am using a Gentoo configured in French, so the french strings)
This file came from the malformed Config.in:
# Automatically created - do not edit.
choice 'XT Keyboard support'            \
     "keys-be.h correspondant    CONFIG_KEYMAP_binaire    \
      keys-de.h correspondant    CONFIG_KEYMAP_binaire    \
      keys-es.h correspondant    CONFIG_KEYMAP_binaire    \
      keys-it.h correspondant    CONFIG_KEYMAP_binaire    \
      keys-se.h correspondant    CONFIG_KEYMAP_binaire    \
      keys-uk.h correspondant    CONFIG_KEYMAP_binaire    \
      Dvorak         CONFIG_KEYMAP_DV    \
      American       CONFIG_KEYMAP_US"        American
# EOF.
Error went away after changing the kernel configuration:
Select console driver: from <Direct> to <BIOS>
I am not at ease with the Config.in generation, any idea here ?
MFLD
--
To unsubscribe from this list: send the line "unsubscribe linux-8086" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

--
To unsubscribe from this list: send the line "unsubscribe linux-8086" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

Marc-François LUCCA-DANIAU

author

2016-05-19 08:44 UTC #4 lore raw

Hello Juan,

Thanks for your explanation. It is clear that C source files should be only in single-byte ASCII with charcode < 127 to avoid any problem with the build tools.

My previous question is actually not related to character encoding for C source files, but rather for the character encoding in the scancode tables.

When you say " Replacing 'é' wilth '\202'", what exact pagecode with single bytes are you refering to ? The link you provided has no reference to any official pagecodes. Should it be IBM 437 or 850, Windows 1252, IANA 8859-1 ?

This is important to ensure consistency between the character encoding by the keyboard driver and the character rendering in the display driver, because glyph bitmaps are indexed on the character code.

One needs this information to fix the tables in keys-*.h.

MFLD

2016-05-18 22:27 GMT+02:00 Juan Perez-Sanchez <[email protected]>:

Quoted 16 lines

Hello Marc:
You are right. I should say "grep". I guess you will use the "keys-be.h" file. The arrays in the
tables in this file are unsigned char, so you would use 'a', 'b' etc for initializers. For nonprinting chars you would use '\xxx', but 0xxx works equally well.
The encoding should be plain ascii. See
http://www.cdrummond.qc.ca/cegep/informat/Professeurs/Alain/files/ascii.htm
Here, the first table is "plain ascii". The second table is the "extended ascii". The BCC compiler
ignores the extended ascii chars.

Quoted 101 lines

For example, in your case, the fourth char in the first table is 'é' and there is a 130 in that position of the file "keys-be.h". Replacing 'é' wilth '\202' you use only plain ascii chars.
Quoted 95 lines · Marc-F. LUCCA-DANIAU
Hello Juan,
Thanks for pointing the previous report.
I guess you meant ""grep" does not like it", and octal as "0xxx" in C files, not "\xxx" as in shell.
Adding option -a to grep gives a correct Config.in, but one thing stills not clear for me:
do you know what is the code page that is supposed to be used to encode the characters in the keys-*.h ?
In the IBM PS/2 BIOS TechRef, I see no clue about this encoding, just a Keycode / ASCII table with US keyboard layout.
MFLD
Quoted 73 lines · Juan Perez-Sanchez
Hello,
This problem (with possible workaround) was reported in:
http://www.spinics.net/lists/linux-8086/msg00675.html
The problem is that keymap tables use "extended ascii" characters, this is, codes greater than 127, and current "make" don't like it. For example, accented a is written as 'á' and should be written as'\341'.
This include files are C code and should use plain ascii. However, this is a lot of work.
Juan
Quoted 54 lines · Marc-F. LUCCA-DANIAU
Hello,
I just took the latest version of ELKS from Jody's GIT master branch, and I
got an issue while building ELKS.
I am using the "build.sh" script for the newbie I am :-)
With default configuration, build fails because the following file is malformed:
/home/mfld/advantech/elks/elks/arch/i86/drivers/char/KeyMaps/keymaps.h:
/* Automatically created - do not edit */
#include "Fichier"        /* binaire    keys-be.h correspondant */
#include "Fichier"        /* binaire    keys-de.h correspondant */
#include "Fichier"        /* binaire    keys-es.h correspondant */
#include "Fichier"        /* binaire    keys-it.h correspondant */
#include "Fichier"        /* binaire    keys-se.h correspondant */
#include "Fichier"        /* binaire    keys-uk.h correspondant */
#include "keys-dv.h"        /* DV    Dvorak       */
#include "keys-us.h"        /* US    American     */
(I am using a Gentoo configured in French, so the french strings)
This file came from the malformed Config.in:
# Automatically created - do not edit.
choice 'XT Keyboard support'            \
     "keys-be.h correspondant    CONFIG_KEYMAP_binaire    \
      keys-de.h correspondant    CONFIG_KEYMAP_binaire    \
      keys-es.h correspondant    CONFIG_KEYMAP_binaire    \
      keys-it.h correspondant    CONFIG_KEYMAP_binaire    \
      keys-se.h correspondant    CONFIG_KEYMAP_binaire    \
      keys-uk.h correspondant    CONFIG_KEYMAP_binaire    \
      Dvorak         CONFIG_KEYMAP_DV    \
      American       CONFIG_KEYMAP_US"        American
# EOF.
Error went away after changing the kernel configuration:
Select console driver: from <Direct> to <BIOS>
I am not at ease with the Config.in generation, any idea here ?
MFLD
--
To unsubscribe from this list: send the line "unsubscribe linux-8086" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

--
To unsubscribe from this list: send the line "unsubscribe linux-8086" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

Juan Perez-Sanchez

2016-05-20 00:53 UTC #5 lore raw

Hello:

The CGA display adapter for PC (and later models) use IBM CP439. So, for the keyboard driver of this hardware my opinion is to also use CP439.

I examined the keys-es.h file and when there are octal initializers, usually corresponds to CP439. But the file itself seems to be encoded with ISO-8859-1.

Quoted 19 lines · Marc-François LUCCA-DANIAU

Hello Juan,
Thanks for your explanation. It is clear that C source files should be only in single-byte ASCII with charcode < 127 to avoid any problem with the build tools.
My previous question is actually not related to character encoding for C source files, but rather for the character encoding in the scancode tables.
When you say " Replacing 'é' wilth '\202'", what exact pagecode with single bytes are you refering to ? The link you provided has no reference to any official pagecodes. Should it be IBM 437 or 850, Windows 1252, IANA 8859-1 ?
This is important to ensure consistency between the character encoding by the keyboard driver and the character rendering in the display driver, because glyph bitmaps are indexed on the character code.

Quoted 125 lines

One needs this information to fix the tables in keys-*.h.
MFLD
2016-05-18 22:27 GMT+02:00 Juan Perez-Sanchez <[email protected]>:
Quoted 117 lines
Hello Marc:
You are right. I should say "grep". I guess you will use the "keys-be.h" file. The arrays in the
tables in this file are unsigned char, so you would use 'a', 'b' etc for initializers. For nonprinting chars you would use '\xxx', but 0xxx works equally well.
The encoding should be plain ascii. See
http://www.cdrummond.qc.ca/cegep/informat/Professeurs/Alain/files/ascii.htm
Here, the first table is "plain ascii". The second table is the "extended ascii". The BCC compiler
ignores the extended ascii chars.
For example, in your case, the fourth char in the first table is 'é' and there is a 130 in that position of the file "keys-be.h". Replacing 'é' wilth '\202' you use only plain ascii chars.
Quoted 95 lines · Marc-F. LUCCA-DANIAU
Hello Juan,
Thanks for pointing the previous report.
I guess you meant ""grep" does not like it", and octal as "0xxx" in C files, not "\xxx" as in shell.
Adding option -a to grep gives a correct Config.in, but one thing stills not clear for me:
do you know what is the code page that is supposed to be used to encode the characters in the keys-*.h ?
In the IBM PS/2 BIOS TechRef, I see no clue about this encoding, just a Keycode / ASCII table with US keyboard layout.
MFLD
Quoted 73 lines · Juan Perez-Sanchez
Hello,
This problem (with possible workaround) was reported in:
http://www.spinics.net/lists/linux-8086/msg00675.html
The problem is that keymap tables use "extended ascii" characters, this is, codes greater than 127, and current "make" don't like it. For example, accented a is written as 'á' and should be written as'\341'.
This include files are C code and should use plain ascii. However, this is a lot of work.
Juan
Quoted 54 lines · Marc-F. LUCCA-DANIAU
Hello,
I just took the latest version of ELKS from Jody's GIT master branch, and I
got an issue while building ELKS.
I am using the "build.sh" script for the newbie I am :-)
With default configuration, build fails because the following file is malformed:
/home/mfld/advantech/elks/elks/arch/i86/drivers/char/KeyMaps/keymaps.h:
/* Automatically created - do not edit */
#include "Fichier"        /* binaire    keys-be.h correspondant */
#include "Fichier"        /* binaire    keys-de.h correspondant */
#include "Fichier"        /* binaire    keys-es.h correspondant */
#include "Fichier"        /* binaire    keys-it.h correspondant */
#include "Fichier"        /* binaire    keys-se.h correspondant */
#include "Fichier"        /* binaire    keys-uk.h correspondant */
#include "keys-dv.h"        /* DV    Dvorak       */
#include "keys-us.h"        /* US    American     */
(I am using a Gentoo configured in French, so the french strings)
This file came from the malformed Config.in:
# Automatically created - do not edit.
choice 'XT Keyboard support'            \
     "keys-be.h correspondant    CONFIG_KEYMAP_binaire    \
      keys-de.h correspondant    CONFIG_KEYMAP_binaire    \
      keys-es.h correspondant    CONFIG_KEYMAP_binaire    \
      keys-it.h correspondant    CONFIG_KEYMAP_binaire    \
      keys-se.h correspondant    CONFIG_KEYMAP_binaire    \
      keys-uk.h correspondant    CONFIG_KEYMAP_binaire    \
      Dvorak         CONFIG_KEYMAP_DV    \
      American       CONFIG_KEYMAP_US"        American
# EOF.
Error went away after changing the kernel configuration:
Select console driver: from <Direct> to <BIOS>
I am not at ease with the Config.in generation, any idea here ?
MFLD
--
To unsubscribe from this list: send the line "unsubscribe linux-8086" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

--
To unsubscribe from this list: send the line "unsubscribe linux-8086" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

Jody Bruchon

2016-05-20 01:34 UTC #6 lore raw

Quoted 3 lines · Juan Perez-Sanchez

Hello:
The CGA display adapter for PC (and later models) use IBM CP439. So,

Don't you mean code page 437?

Marc-F. LUCCA-DANIAU

author

2016-05-20 12:23 UTC #7 lore raw

I feel the discussion about codepage to use is just starting :-)

Applied the patch from Stefan (proposed in http://www.spinics.net/lists/linux-8086/msg00675.html):
https://github.com/jbruchon/elks/pull/25

Some source files are still badly encoded in 8859-xx,
but at least it fixed the ELKS kernel build, that was the initial issue.

MFLD

Quoted 12 lines · Juan Perez-Sanchez

Quoted 3 lines
Hello:
The CGA display adapter for PC (and later models) use IBM CP439. So,
Don't you mean code page 437?
Signature · 3 lines
To unsubscribe from this list: send the line "unsubscribe linux-8086" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

--
To unsubscribe from this list: send the line "unsubscribe linux-8086" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

Juan Perez-Sanchez

2016-05-20 17:52 UTC #8 lore raw

In reply to Jody Bruchon

Right, IBM CP437

Quoted 14 lines · Jody Bruchon

Quoted 4 lines · Juan Perez-Sanchez
Hello:
The CGA display adapter for PC (and later models) use IBM CP439. So,
Don't you mean code page 437?
--
To unsubscribe from this list: send the line "unsubscribe linux-8086" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html