Re: aide au débogage : logged-gcc

2023-03-11 Thread Ken-Patrick

On 11/03/2023 13:44, Basile Starynkevitch wrote:


Non. Pour des tas de raisons (y compris que j'ai personnellement 
contribué à GCC mais pas à Clang, que j'en connais donc assez bien les 
internes, et aussi pour des raisons de licence -je préfère la GPL à BSD) 
je souhaite explicitement utiliser GCC (dans mon esprit, GCC 12 en début 
2023, sur Debian ou autre Linux)


  Cordialement



Hum, je n'ai peut-être pas été assez explicite.
La compilation database, c'est juste un json contenant les commandes 
utilisées pour compiler chaque fichier d'un projet.
bear peut te générer une compilation database quel que soit le 
compilateur ou le système de build utilisé (à noter que cmake sait le 
faire tout seul).
Le format des compilations database est décrit dans la doc de clang, 
parce que c'est utilisé dans la plupart de leur outils, mais c'est tout.


En plus, bear est en GPL ;-).

++
Ken-Patrick



Re: [April technique] aide au débogage : logged-gcc

2023-03-11 Thread Laurent Lyaudet
Bonjour Basile :)

ça a l'air sympa de pouvoir garder une trace de toutes les
compilations sans erreur.
Je n'ai pas le temps de vous aider, mais merci d'avoir fait la
promotion de votre outil :)

Amicalement,
Laurent Lyaudet

Le ven. 10 mars 2023 à 19:57, Basile Starynkevitch
 a écrit :
>
> Bonsoir,
>
>
> Il est naturel, quand on est fan de logiciel libre et de Debian (ou
> similaire), de compiler du logiciel libre (notamment en C ou C++) à
> partir de son code source, en utilisant (probablement) GCC (voir
> https://gcc.gnu.org/ ...)
>
> Il est alors utile de pouvoir conserver la trace de toutes les
> compilations par GCC.
>
> Aussi ai-je plus ou moins codé, en
> https://github.com/bstarynk/misc-basile/blob/master/logged-gcc.cc un
> utilitaire qui stocke dans une base sqlite les commandes de compilation
> avec leur détail. Ça se compile avec le script
> https://github.com/bstarynk/misc-basile/blob/master/compile-logged-gcc.sh
>
>
> L'utilisation serait de mettre un lien symbolique $HOME/bin/gcc ->
> $HOME/bin/logged-gcc et de même pour $HOME/bin/g++ et d'avoir $HOME/bin/
> dans son $PATH avant /usr/bin/
>
>
> Ensuite il faut initialiser la base SQLite (une seule fois) avec
> $HOME/bin/logged-gcc --sqlite=logged-gcc-db.sqlite
>
>
> Mais il me reste des bogues? Il y a-t-il une bonne âme pour m'aider?
>
>
> (les commentaires sont en anglais)
>
>
> librement
>
> --
> Basile Starynkevitch  
> (only mine opinions / les opinions sont miennes uniquement)
> 92340 Bourg-la-Reine, France
> web page: starynkevitch.net/Basile/ & refpersys.org
>
> --
> Pour connaître la configuration de la liste, gérer votre abonnement à la 
> liste technique et vos informations personnelles :
> https://listes.april.org/wws/info/technique



Re: aide au débogage : logged-gcc

2023-03-11 Thread Basile Starynkevitch



On 3/11/23 13:20, Ken-Patrick wrote:

Hello Basile,

On 10/03/2023 19:57, Basile Starynkevitch wrote:

Bonsoir,


[...]


Il est alors utile de pouvoir conserver la trace de toutes les 
compilations par GCC.



[...]

Est-ce que https://clang.llvm.org/docs/JSONCompilationDatabase.html et 
potentiellement https://github.com/rizsotto/Bear ne répondraient pas à 
ton besoin ? C'est à peu près standard il me semble.




Non. Pour des tas de raisons (y compris que j'ai personnellement 
contribué à GCC mais pas à Clang, que j'en connais donc assez bien les 
internes, et aussi pour des raisons de licence -je préfère la GPL à BSD) 
je souhaite explicitement utiliser GCC (dans mon esprit, GCC 12 en début 
2023, sur Debian ou autre Linux)


 Cordialement

--
Basile Starynkevitch 
92340 Bourg-la-Reine, France
http://starynkevitch.net/Basile/ and http://refpersys.org/



Re: aide au débogage : logged-gcc

2023-03-11 Thread Ken-Patrick

Hello Basile,

On 10/03/2023 19:57, Basile Starynkevitch wrote:

Bonsoir,


[...]


Il est alors utile de pouvoir conserver la trace de toutes les 
compilations par GCC.



[...]

Est-ce que https://clang.llvm.org/docs/JSONCompilationDatabase.html et 
potentiellement https://github.com/rizsotto/Bear ne répondraient pas à 
ton besoin ? C'est à peu près standard il me semble.


++
Ken-Patrick



aide au débogage : logged-gcc

2023-03-10 Thread Basile Starynkevitch

Bonsoir,


Il est naturel, quand on est fan de logiciel libre et de Debian (ou 
similaire), de compiler du logiciel libre (notamment en C ou C++) à 
partir de son code source, en utilisant (probablement) GCC (voir 
https://gcc.gnu.org/ ...)


Il est alors utile de pouvoir conserver la trace de toutes les 
compilations par GCC.


Aussi ai-je plus ou moins codé, en 
https://github.com/bstarynk/misc-basile/blob/master/logged-gcc.cc un 
utilitaire qui stocke dans une base sqlite les commandes de compilation 
avec leur détail. Ça se compile avec le script 
https://github.com/bstarynk/misc-basile/blob/master/compile-logged-gcc.sh



L'utilisation serait de mettre un lien symbolique $HOME/bin/gcc -> 
$HOME/bin/logged-gcc et de même pour $HOME/bin/g++ et d'avoir $HOME/bin/ 
dans son $PATH avant /usr/bin/



Ensuite il faut initialiser la base SQLite (une seule fois) avec 
$HOME/bin/logged-gcc --sqlite=logged-gcc-db.sqlite



Mais il me reste des bogues? Il y a-t-il une bonne âme pour m'aider?


(les commentaires sont en anglais)


librement

--
Basile Starynkevitch  
(only mine opinions / les opinions sont miennes uniquement)
92340 Bourg-la-Reine, France
web page: starynkevitch.net/Basile/ & refpersys.org



Re: how to install gcc-6 in debian bullseye

2022-05-02 Thread tomas
On Mon, May 02, 2022 at 11:51:02PM +0300, Georgi Naplatanov wrote:
> On 5/2/22 23:25, michaelmorgan...@gmail.com wrote:
> > Can anyone kindly instruct me how to install gcc-6 in Debian 11? I need
> > compile a software and was hinted gcc version (10) is too high. I have
> > old machine with gcc 6 and was able to compile it there.
> > 
> 
> It seems that Debian 9 has gcc-6 so you can use Docker image with Debian 9.

Alternatively, build in a chroot, using archives.debian.org as
source (that's what I do; for convenience I use schroot, but
am not really sure whether to keep it). The Debian Wiki [1]
has a good starting point.

Cheers

[1] https://wiki.debian.org/chroot
-- 
t


signature.asc
Description: PGP signature


Re: how to install gcc-6 in debian bullseye

2022-05-02 Thread Georgi Naplatanov
On 5/2/22 23:25, michaelmorgan...@gmail.com wrote:
> Can anyone kindly instruct me how to install gcc-6 in Debian 11? I need
> compile a software and was hinted gcc version (10) is too high. I have
> old machine with gcc 6 and was able to compile it there.
> 

It seems that Debian 9 has gcc-6 so you can use Docker image with Debian 9.

HTH

Kind regards
Georgi



Re: how to install gcc-6 in debian bullseye

2022-05-02 Thread Greg Wooledge
On Mon, May 02, 2022 at 03:25:20PM -0500, michaelmorgan...@gmail.com wrote:
> Can anyone kindly instruct me how to install gcc-6 in Debian 11? I need
> compile a software and was hinted gcc version (10) is too high. I have
> old machine with gcc 6 and was able to compile it there. 

Stop looking at packages.  Download the source code for gcc 6, and build
it as if it were a foreign program.  Install it in /usr/local or
/opt/something as if it were a foreign program.

Or, fix the program you're trying to compile, because it's clearly full
of bugs that older gcc simply wasn't catching.



how to install gcc-6 in debian bullseye

2022-05-02 Thread michaelmorgan937
Can anyone kindly instruct me how to install gcc-6 in Debian 11? I need
compile a software and was hinted gcc version (10) is too high. I have
old machine with gcc 6 and was able to compile it there. 

 

Thank you very much.

Michael

 

 



Re: No man page for gcc

2022-03-12 Thread Roberto C . Sánchez
On Sat, Mar 12, 2022 at 10:36:57PM +0100, Steve Keller wrote:
> On debian bullseye I have installed GCC but don't find any manual page.
> What am I missing?
> 
You'll need to add 'contrib' and 'non-free' to your sources and then
install the gcc-doc package [0].

Regards,

-Roberto

[0] https://packages.debian.org/gcc-doc

-- 
Roberto C. Sánchez



No man page for gcc

2022-03-12 Thread Steve Keller
On debian bullseye I have installed GCC but don't find any manual page.
What am I missing?

Steve



Re: Debian and FSF docs (was: Man pages for gcc)

2021-12-10 Thread Andrei POPESCU
On Vi, 10 dec 21, 17:17:24, Andrew M.A. Cater wrote:
> On Fri, Dec 10, 2021 at 12:41:01PM +0100, Andrei POPESCU wrote:
> 
> > At the very least Debian could split non-free into sections or add more 
> > areas (non-free firmware being another obvious candidate for splitting 
> > out).
> > 
> 
> Do wait a little while and there may well ba e GR to that effect.

I guessed something like this might happen based on Steve's mail to 
-vote ;)

As much as I hate to admit it, the free installer is at the moment a 
major hurdle to new Debian users, but I'm also not convinced a general 
exception for all (distributable) firmware is necessarily the right 
answer either.

Let's see what the Project decides.

Kind regards,
Andrei
-- 
http://wiki.debian.org/FAQsFromDebianUser


signature.asc
Description: PGP signature


Re: Debian and FSF docs (was: Man pages for gcc)

2021-12-10 Thread Andrew M.A. Cater
On Fri, Dec 10, 2021 at 12:41:01PM +0100, Andrei POPESCU wrote:
> On Du, 31 oct 21, 17:37:10, Stefan Monnier wrote:
> > > This is because GNU releases their documentation under a different license
> > > than their source code.  And Debian considers the GNU documentation
> > > license to be non-free (rightly so, because it prohibits distributing
> > > modified versions).
> > 
> > FWIW, it's not nearly as clear cut as you make it sound, because it does
> > not prevent distribution of all modified versions.
> > 
> > It does require one particular section to be kept unmodified (IIRC it's
> > the section that promotes the FSF philosophy), but the bulk is Free in
> > the usual sense of allowing redistribution of modified versions.
> 
> As far as I understand[1] further modifications can add other invariant 
> sections as well and humans have demonstrated a remarkable capacity of 
> abusing such loopholes.
>  
> > I find this state of affair rather sad and am disappointed by both
> > Debian and the FSF for not finding a compromise.  It ends up promoting
> > the use of the non-free repository, which I think neither project wants.
> 

It's _not_ a Debian problem in one sense: it's the FSF's licence. Or we 
could say "it's in non-free - not part of Debian - so we really don't care
and if it breaks, well so what"

> At the very least Debian could split non-free into sections or add more 
> areas (non-free firmware being another obvious candidate for splitting 
> out).
> 

Do wait a little while and there may well ba e GR to that effect.

All the very best, as ever,

Andy CAter


> [1] https://wiki.debian.org/GFDLPositionStatement
> 
> Kind regards,
> Andrei
> -- 
> http://wiki.debian.org/FAQsFromDebianUser




Re: Debian and FSF docs (was: Man pages for gcc)

2021-12-10 Thread Andrei POPESCU
On Du, 31 oct 21, 17:37:10, Stefan Monnier wrote:
> > This is because GNU releases their documentation under a different license
> > than their source code.  And Debian considers the GNU documentation
> > license to be non-free (rightly so, because it prohibits distributing
> > modified versions).
> 
> FWIW, it's not nearly as clear cut as you make it sound, because it does
> not prevent distribution of all modified versions.
> 
> It does require one particular section to be kept unmodified (IIRC it's
> the section that promotes the FSF philosophy), but the bulk is Free in
> the usual sense of allowing redistribution of modified versions.

As far as I understand[1] further modifications can add other invariant 
sections as well and humans have demonstrated a remarkable capacity of 
abusing such loopholes.
 
> I find this state of affair rather sad and am disappointed by both
> Debian and the FSF for not finding a compromise.  It ends up promoting
> the use of the non-free repository, which I think neither project wants.

At the very least Debian could split non-free into sections or add more 
areas (non-free firmware being another obvious candidate for splitting 
out).

[1] https://wiki.debian.org/GFDLPositionStatement

Kind regards,
Andrei
-- 
http://wiki.debian.org/FAQsFromDebianUser


signature.asc
Description: PGP signature


Re: Man pages for gcc

2021-12-10 Thread Andrei POPESCU
On Du, 07 nov 21, 08:08:51, Emanuel Berg wrote:
> Paul M. Foster wrote:
> 
> > Folks:
> >
> > I'm sure everyone but me knows this, but I can't find a man
> > page for gcc.
> 
> Everyone knows it ... but this question has still been asked
> one zillion times. I personally do not mind one bit you asking
> it here, but Google is faster if you care about such things :)

It probably belongs in an FAQ somewhere, if only there was something 
like that for debian-user... ;)

Kind regards,
Andrei
-- 
http://wiki.debian.org/FAQsFromDebianUser


signature.asc
Description: PGP signature


Re: Man pages for gcc

2021-11-01 Thread Nicholas Geovanis
On Sun, Oct 31, 2021, 5:05 PM Nate Bargmann  wrote:

> * On 2021 31 Oct 16:27 -0500, Nicholas Geovanis wrote:
>
> > The info command is what you want for gcc. You may need to install the
> > package for gcc info files. Another set of commands you might need info
> > files for are coreutils. Try "info coreutils".
>
> While info is probably installed, a much better user experience is the
> 'pinfo' package since it uses Lynx like motion and color highlighting
> for hyperlinks.
>

Never used pinfo, thanks. I'll try it. You see, over time my browsers get
more primitive. I'm in the last trench now, it's curl and wget now :-)

Which reminds me, when using windowed character mode tools like these, it's
important to set the terminal type correctly in the Linux sessions
environment variables. But also make sure it lines up with the terminal
type in the terminal emulation software you may be using. Otherwise the
screen is soup.

- Nate
>
> --
> "The optimist proclaims that we live in the best of all
> possible worlds.  The pessimist fears this is true."
> Web: https://www.n0nb.us
> Projects: https://github.com/N0NB
> GPG fingerprint: 82D6 4F6B 0E67 CD41 F689 BBA6 FB2C 5130 D55A 8819
>
>


Re: Man pages for gcc

2021-10-31 Thread Nate Bargmann
* On 2021 31 Oct 16:27 -0500, Nicholas Geovanis wrote:
 
> The info command is what you want for gcc. You may need to install the
> package for gcc info files. Another set of commands you might need info
> files for are coreutils. Try "info coreutils".

While info is probably installed, a much better user experience is the
'pinfo' package since it uses Lynx like motion and color highlighting
for hyperlinks.

- Nate

-- 
"The optimist proclaims that we live in the best of all
possible worlds.  The pessimist fears this is true."
Web: https://www.n0nb.us
Projects: https://github.com/N0NB
GPG fingerprint: 82D6 4F6B 0E67 CD41 F689 BBA6 FB2C 5130 D55A 8819



signature.asc
Description: PGP signature


Re: Man pages for gcc

2021-10-31 Thread Dan Ritter
Paul M. Foster wrote: 
> Folks:
> 
> I'm sure everyone but me knows this, but I can't find a man page for gcc.
> There must be some docs somewhere. First question: why isn't there a man
> page? Second question: what docs are available (or what package provides
> them)? Running Debian 11.

gcc-doc has the man pages; they are in non-free.

Yes, it's ironic.

-dsr-



Re: Man pages for gcc

2021-10-31 Thread Nicholas Geovanis
On Sun, Oct 31, 2021, 4:07 PM Paul M. Foster 
wrote:

> Folks:
>
> I'm sure everyone but me knows this, but I can't find a man page for
> gcc. There must be some docs somewhere. First question: why isn't there
> a man page? Second question: what docs are available (or what package
> provides them)? Running Debian 11.
>

The info command is what you want for gcc. You may need to install the
package for gcc info files. Another set of commands you might need info
files for are coreutils. Try "info coreutils".

These are Gnu/FSF projects and handled a bit differently. I think you'll
also want the gcc book available at the Gnu gcc site.

Paul
>
>
>


Re: Man pages for gcc

2021-10-31 Thread Greg Wooledge
On Sun, Oct 31, 2021 at 04:58:34PM -0400, Paul M. Foster wrote:
> I'm sure everyone but me knows this, but I can't find a man page for gcc.
> There must be some docs somewhere. First question: why isn't there a man
> page? Second question: what docs are available (or what package provides
> them)? Running Debian 11.

The documentation for gcc is in a separate package, in the non-free
section.

unicorn:~$ apt-cache show gcc-doc
Package: gcc-doc
Source: gcc-doc-defaults (5:21)
Version: 5:10.1.0-1
[...]
Depends: gcc-10-doc (>= 10.1.0-1~)
[...]
Section: contrib/doc

unicorn:~$ apt-cache show gcc-10-doc
[...]
Section: non-free/doc


This is because GNU releases their documentation under a different license
than their source code.  And Debian considers the GNU documentation
license to be non-free (rightly so, because it prohibits distributing
modified versions).



Man pages for gcc

2021-10-31 Thread Paul M. Foster

Folks:

I'm sure everyone but me knows this, but I can't find a man page for 
gcc. There must be some docs somewhere. First question: why isn't there 
a man page? Second question: what docs are available (or what package 
provides them)? Running Debian 11.


Paul




Re: gcc-10: options order important?

2021-09-03 Thread Sven Joachim
On 2021-09-03 12:24 +0200, Piotr A. Dybczyński wrote:

> Hi,
>
> in contrary to previous versions, now in Debian 11 with gcc-10:
>
> gcc aa.c -lm -o aa   works, but
>
> gcc -lm aa.c -o aa   does not work, saying: 
>
> /usr/bin/ld: /tmp/ccWyhudO.o: in function `main':
> aa.c:(.text+0x1f): undefined reference to `sqrt'
> collect2: error: ld returned 1 exit status
>
> It seems that an option -lm cannot be placed in an arbitrary place which I 
> used to
> do. Is this intentional ?

Yes, gcc now invokes ld with the --as-needed option.  This reduces
unnecessary linking and thereby Debian package dependencies, but it also
has the effect you are seeing, as mentioned in the binutils
documentation:

,
| Object files or libraries appearing on the command line _after_ the
| library in question do not affect whether the library is seen as needed.
| This is similar to the rules for extraction of object files from
| archives.  '--no-as-needed' restores the default behaviour.
`

Cheers,
   Sven



Re: gcc-10: options order important?

2021-09-03 Thread tomas
On Fri, Sep 03, 2021 at 12:59:27PM -0400, Greg Wooledge wrote:
> On Fri, Sep 03, 2021 at 02:12:46PM +0100, Tixy wrote:
> > > A man page a found online [1] says linking happens as Greg described, 
> > > and this is true looking at a 6 year old copy of that page on
> > > archive.org. So seems strange that for many years my Makefiles have
> > > worked with Libraries specified before inputs that use them.
> > 
> > Correction... 'for many years my Makefiles have worked with Libraries
> > specified _after_ inputs that use them'
> 
> You had it right the first time.  It's strange that it worked (in the
> past) with the library argument in front.  It's supposed to be behind.
> 
> The linker's argument processing must have been changed a few times.
> GNU utilities in general have a tendency to be overly lenient with
> command-line options.  Commands that *should* fail according to POSIX
> sometimes work in the GNU variants.

[...]

It /might/ be related to weak linking and the default for
the --as-needed option in the linker. Caveat: I haven't found
the time to research this more thoroughly.

But OP could try to pass --no-as-needed and see what happens :)

Cheers
 - t


signature.asc
Description: Digital signature


Re: gcc-10: options order important?

2021-09-03 Thread Greg Wooledge
On Fri, Sep 03, 2021 at 02:12:46PM +0100, Tixy wrote:
> > A man page a found online [1] says linking happens as Greg described, 
> > and this is true looking at a 6 year old copy of that page on
> > archive.org. So seems strange that for many years my Makefiles have
> > worked with Libraries specified before inputs that use them.
> 
> Correction... 'for many years my Makefiles have worked with Libraries
> specified _after_ inputs that use them'

You had it right the first time.  It's strange that it worked (in the
past) with the library argument in front.  It's supposed to be behind.

The linker's argument processing must have been changed a few times.
GNU utilities in general have a tendency to be overly lenient with
command-line options.  Commands that *should* fail according to POSIX
sometimes work in the GNU variants.

For example:

unicorn:~$ ls .bashrc -l
-rwxr-xr-x 1 greg greg 2741 Sep  1 22:32 .bashrc*

That should *not* have worked, but GNU permits the option (-l) to be
handled even when it's in the wrong place.  (In standard POSIX ls,
that command should have tried to list a file named "-l", because
the non-option ".bashrc" terminates option processing.  All remaining
arguments are to be treated as files or directories.)

All I can speculate is that GNU ld (the linker that gcc uses) must have
had some tweaks done to it over the years, and now has settled back into
its original behavior.  An expert in GNU binutils (or even a changelog)
might have more details.

The way a gcc (or cc) command is supposed to be written is:

gcc [options] source/object files [-libraries]

The up-front [options] can include things like "-o foo" to specify an
output file other than a.out to the linker.  So, for example, the OP's
command should have been something like:

gcc -o foo foo.c -lm

That's the standard format, and is what you should be using in Makefiles
and similar files which call gcc.



Re: gcc-10: options order important?

2021-09-03 Thread Tixy
On Fri, 2021-09-03 at 14:10 +0100, Tixy wrote:
> On Fri, 2021-09-03 at 12:24 +0200, Piotr A. Dybczyński wrote:
> > Hi,
> > 
> > in contrary to previous versions, now in Debian 11 with gcc-10:
> > 
> > gcc aa.c -lm -o aa   works, but
> > 
> > gcc -lm aa.c -o aa   does not work, saying: 
> 
> [...]
> 
> > It seems that an option -lm cannot be placed in an arbitrary place which I 
> > used to
> > do. Is this intentional ?
> 
> I found this too, I just modified my Makefiles to have libraries after
> input files.
> 
> A man page a found online [1] says linking happens as Greg described, 
> and this is true looking at a 6 year old copy of that page on
> archive.org. So seems strange that for many years my Makefiles have
> worked with Libraries specified before inputs that use them.

Correction... 'for many years my Makefiles have worked with Libraries
specified _after_ inputs that use them'

-- 
Tixy



Re: gcc-10: options order important?

2021-09-03 Thread Tixy
On Fri, 2021-09-03 at 12:24 +0200, Piotr A. Dybczyński wrote:
> Hi,
> 
> in contrary to previous versions, now in Debian 11 with gcc-10:
> 
> gcc aa.c -lm -o aa   works, but
> 
> gcc -lm aa.c -o aa   does not work, saying: 

[...]

> It seems that an option -lm cannot be placed in an arbitrary place which I 
> used to
> do. Is this intentional ?

I found this too, I just modified my Makefiles to have libraries after
input files.

A man page a found online [1] says linking happens as Greg described, 
and this is true looking at a 6 year old copy of that page on
archive.org. So seems strange that for many years my Makefiles have
worked with Libraries specified before inputs that use them.

-- 
Tixy



Re: gcc-10: options order important?

2021-09-03 Thread Greg Wooledge
On Fri, Sep 03, 2021 at 12:24:39PM +0200, Piotr A. Dybczyński wrote:
> Hi,
> 
> in contrary to previous versions, now in Debian 11 with gcc-10:
> 
> gcc aa.c -lm -o aa   works, but
> 
> gcc -lm aa.c -o aa   does not work, saying: 
> 
> /usr/bin/ld: /tmp/ccWyhudO.o: in function `main':
> aa.c:(.text+0x1f): undefined reference to `sqrt'
> collect2: error: ld returned 1 exit status

If this *ever* worked in the past, it was dumb luck.  Libraries need
to be given after the objects that use them.  That's how the linker
operates.

You can think of it this way: the linker scans through the list of object
files and libraries in a single pass, left to right.  In your non-working
command, the first thing it encounters is -lm (math library).  So it
checks for any unresolved symbols that it currently has, and tries to
match them against the math library.  There aren't any unresolved symbols
at this point (because no object files have been linked in yet), so it
doesn't pull anything out of the math library.

Next it encounters aa.o (implicitly compiled from aa.c), and it links in
that object file, which may have some unresolved symbols.  If there are
any, the linker expects that it'll be given a library afterward, to look
them up.

But... there is no library given after that.  It doesn't go *back* to
look at the math library a second time.



gcc-10: options order important?

2021-09-03 Thread Piotr A. Dybczyński
Hi,

in contrary to previous versions, now in Debian 11 with gcc-10:

gcc aa.c -lm -o aa   works, but

gcc -lm aa.c -o aa   does not work, saying: 

/usr/bin/ld: /tmp/ccWyhudO.o: in function `main':
aa.c:(.text+0x1f): undefined reference to `sqrt'
collect2: error: ld returned 1 exit status

My aa.c content:

---
#include
#include

int main(void)
{
  double x=4;

  printf("sqrt(4)=%f\n",sqrt(x));

  return 0;
}
---

It seems that an option -lm cannot be placed in an arbitrary place which I used 
to
do. Is this intentional ?

Regards,

Piotr A. Dybczyński
-- 
/**
  dr Piotr A. Dybczyński 
 homepage: https://www.dybczynski.pl/Piotr e-mail: pi...@dybczynski.pl
PAD***/



Re: fallo extraño en gcc

2020-11-27 Thread juan carlos rebate rodriguez
El vie, 27-11-2020 a las 09:19 +0100, Camaleón escribió:
> El 2020-11-27 a las 01:33 +0100, juan carlos rebate rodriguez
> escribió:
> 
> > El jue, 26-11-2020 a las 19:01 +0100, Camaleón escribió:
> > > El 2020-11-26 a las 18:51 +0100, Juan carlos Rebate escribió:
> > > 
> > > > hola, buenas acabo de actualizar a 10.6 y me encontré un fallo
> > > > al
> > > > intentar compilar ffmpeg, en lugar de crearse binarios se
> > > > quedan
> > > > como
> > > > archivos de texto, osea si el binario ffmpeg debería
> > > > reconocerse
> > > > como
> > > > ejecutable, ahora se reconoce como archivo de texto, lo curioso
> > > > es
> > > > que
> > > > se comporta como ejecutable, 
> > > 
> > > ¿Qué te dice «file /usr/bin/ffmpeg»
> 
> (...)
> 
> > > ¿Y el registro que genera el compilador no te dice nada relevante
> > > del 
> > > archivo resultante? :-?
> > > hola, no encuentro el log de gcc en /var/log pero si intento
> > > compilarun tipico programa que imprima texto y añado -v puedes vr
> > > todo lo que el compilador usam en este caso es g++ pero gcc da el
> > > mismo error
> > 
> > jc@debian:~$ g++ -v source.cpp -o ejecutable
> 
> (...)
> 
> En principio no veo nada raro en el registro, ningún error que pueda
> ser
> relevante para el caso :-?
> 
> (...)
>  
> > pero luego se reconoce como text/x-application
> 
> ¿Qué te devuelve «file ejecutable»?
> 
> Saludos,
> buenas, haciendo pruebas con vm creo que es un bug del enlazador y
> del entorno grafico, en cinamon lo reconoce como text/x-application,
> en gnome al compilar se reconoce como biblioteca compartida, pero si
> uso alguna distro que no venga con gcc 8 sino una version anterior
> silo reconoce como ejecutable, sin enbargo al ejecutar file sobre el
> archivo si lo reconoce como archivo elf


>  jc@debian:~$ file ejecutable
> ejecutable: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV),
> dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for
> GNU/Linux 3.2.0,
> BuildID[sha1]=a8fd2b3e522f2853060262b60045276841313af7, not stripped
> 



Re: fallo extraño en gcc

2020-11-27 Thread Camaleón
El 2020-11-27 a las 01:33 +0100, juan carlos rebate rodriguez escribió:

> El jue, 26-11-2020 a las 19:01 +0100, Camaleón escribió:
> > El 2020-11-26 a las 18:51 +0100, Juan carlos Rebate escribió:
> > 
> > > hola, buenas acabo de actualizar a 10.6 y me encontré un fallo al
> > > intentar compilar ffmpeg, en lugar de crearse binarios se quedan
> > > como
> > > archivos de texto, osea si el binario ffmpeg debería reconocerse
> > > como
> > > ejecutable, ahora se reconoce como archivo de texto, lo curioso es
> > > que
> > > se comporta como ejecutable, 
> > 
> > ¿Qué te dice «file /usr/bin/ffmpeg»

(...)

> > ¿Y el registro que genera el compilador no te dice nada relevante
> > del 
> > archivo resultante? :-?
> 
> > hola, no encuentro el log de gcc en /var/log pero si intento
> > compilarun tipico programa que imprima texto y añado -v puedes vr
> > todo lo que el compilador usam en este caso es g++ pero gcc da el
> > mismo error
> 
> jc@debian:~$ g++ -v source.cpp -o ejecutable

(...)

En principio no veo nada raro en el registro, ningún error que pueda ser
relevante para el caso :-?

(...)
 
> pero luego se reconoce como text/x-application

¿Qué te devuelve «file ejecutable»?

Saludos,

-- 
Camaleón 



Re: fallo extraño en gcc

2020-11-26 Thread juan carlos rebate rodriguez
El jue, 26-11-2020 a las 19:01 +0100, Camaleón escribió:
> El 2020-11-26 a las 18:51 +0100, Juan carlos Rebate escribió:
> 
> > hola, buenas acabo de actualizar a 10.6 y me encontré un fallo al
> > intentar compilar ffmpeg, en lugar de crearse binarios se quedan
> > como
> > archivos de texto, osea si el binario ffmpeg debería reconocerse
> > como
> > ejecutable, ahora se reconoce como archivo de texto, lo curioso es
> > que
> > se comporta como ejecutable, 
> 
> ¿Qué te dice «file /usr/bin/ffmpeg»
> 
> > lo he probado con otros sistemas como
> > devuan y pasa exactamente lo mismo, pense que seria algun fallo del
> > makefile pero no, intente compilar un simple código con codeblocks
> > y
> > pasa igual, no se trata de un fallo del programa sino del
> > compilador,
> > todas las dependencias fueron instaladas con build-esential
> > (dependencias del compilador), alguna idea?
> 
> ¿Y el registro que genera el compilador no te dice nada relevante
> del 
> archivo resultante? :-?
> 
> Saludos, 
> 

> hola, no encuentro el log de gcc en /var/log pero si intento
> compilarun tipico programa que imprima texto y añado -v puedes vr
> todo lo que el compilador usam en este caso es g++ pero gcc da el
> mismo error

jc@debian:~$ g++ -v source.cpp -o ejecutable
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/8/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 8.3.0-6' 
--with-bugurl=file:///usr/share/doc/gcc-8/README.Bugs --enable-
languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++ --prefix=/usr --
with-gcc-major-version-only --program-suffix=-8 --program-
prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id --
libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--libdir=/usr/lib --enable-nls --enable-bootstrap --enable-clocale=gnu
--enable-libstdcxx-debug --enable-libstdcxx-time=yes --with-default-
libstdcxx-abi=new --enable-gnu-unique-object --disable-vtable-verify --
enable-libmpx --enable-plugin --enable-default-pie --with-system-zlib
--with-target-system-zlib --enable-objc-gc=auto --enable-multiarch --
disable-werror --with-arch-32=i686 --with-abi=m64 --with-multilib-
list=m32,m64,mx32 --enable-multilib --with-tune=generic --enable-
offload-targets=nvptx-none --without-cuda-driver --enable-
checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --
target=x86_64-linux-gnu
Thread model: posix
gcc version 8.3.0 (Debian 8.3.0-6) 
COLLECT_GCC_OPTIONS='-v' '-o' 'ejecutable' '-shared-libgcc' '-
mtune=generic' '-march=x86-64'
 /usr/lib/gcc/x86_64-linux-gnu/8/cc1plus -quiet -v -imultiarch x86_64-
linux-gnu -D_GNU_SOURCE source.cpp -quiet -dumpbase source.cpp
-mtune=generic -march=x86-64 -auxbase source -version -o
/tmp/ccIKSgnI.s
GNU C++14 (Debian 8.3.0-6) version 8.3.0 (x86_64-linux-gnu)
compiled by GNU C version 8.3.0, GMP version 6.1.2, MPFR
version 4.0.2, MPC version 1.1.0, isl version isl-0.20-GMP

GGC heuristics: --param ggc-min-expand=100 --param ggc-min-
heapsize=131072
ignoring duplicate directory "/usr/include/x86_64-linux-gnu/c++/8"
ignoring nonexistent directory "/usr/local/include/x86_64-linux-gnu"
ignoring nonexistent directory "/usr/lib/gcc/x86_64-linux-
gnu/8/../../../../x86_64-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:
 /usr/include/c++/8
 /usr/include/x86_64-linux-gnu/c++/8
 /usr/include/c++/8/backward
 /usr/lib/gcc/x86_64-linux-gnu/8/include
 /usr/local/include
 /usr/lib/gcc/x86_64-linux-gnu/8/include-fixed
 /usr/include/x86_64-linux-gnu
 /usr/include
End of search list.
GNU C++14 (Debian 8.3.0-6) version 8.3.0 (x86_64-linux-gnu)
compiled by GNU C version 8.3.0, GMP version 6.1.2, MPFR
version 4.0.2, MPC version 1.1.0, isl version isl-0.20-GMP

GGC heuristics: --param ggc-min-expand=100 --param ggc-min-
heapsize=131072
Compiler executable checksum: 3c854693d01dc9a844a56a0b1ab1c0f4
COLLECT_GCC_OPTIONS='-v' '-o' 'ejecutable' '-shared-libgcc' '-
mtune=generic' '-march=x86-64'
 as -v --64 -o /tmp/ccqsfftG.o /tmp/ccIKSgnI.s
GNU ensamblador versión 2.31.1 (x86_64-linux-gnu) utilizando BFD
versión (GNU Binutils for Debian) 2.31.1
COMPILER_PATH=/usr/lib/gcc/x86_64-linux-gnu/8/:/usr/lib/gcc/x86_64-
linux-gnu/8/:/usr/lib/gcc/x86_64-linux-gnu/:/usr/lib/gcc/x86_64-linux-
gnu/8/:/usr/lib/gcc/x86_64-linux-gnu/
LIBRARY_PATH=/usr/lib/gcc/x86_64-linux-gnu/8/:/usr/lib/gcc/x86_64-
linux-gnu/8/../../../x86_64-linux-gnu/:/usr/lib/gcc/x86_64-linux-
gnu/8/../../../../lib/:/lib/x86_64-linux-
gnu/:/lib/../lib/:/usr/lib/x86_64-linux-
gnu/:/usr/lib/../lib/:/usr/lib/gcc/x86_64-linux-
gnu/8/../../../:/lib/:/usr/lib/
COLLECT_GCC_OPTIONS='-v' '-o' 'ejecutable' '-shared-libgcc' '-
mtune=gen

Re: fallo extraño en gcc

2020-11-26 Thread Camaleón
El 2020-11-26 a las 18:51 +0100, Juan carlos Rebate escribió:

> hola, buenas acabo de actualizar a 10.6 y me encontré un fallo al
> intentar compilar ffmpeg, en lugar de crearse binarios se quedan como
> archivos de texto, osea si el binario ffmpeg debería reconocerse como
> ejecutable, ahora se reconoce como archivo de texto, lo curioso es que
> se comporta como ejecutable, 

¿Qué te dice «file /usr/bin/ffmpeg»

> lo he probado con otros sistemas como
> devuan y pasa exactamente lo mismo, pense que seria algun fallo del
> makefile pero no, intente compilar un simple código con codeblocks y
> pasa igual, no se trata de un fallo del programa sino del compilador,
> todas las dependencias fueron instaladas con build-esential
> (dependencias del compilador), alguna idea?

¿Y el registro que genera el compilador no te dice nada relevante del 
archivo resultante? :-?

Saludos, 

-- 
Camaleón 



fallo extraño en gcc

2020-11-26 Thread Juan carlos Rebate
hola, buenas acabo de actualizar a 10.6 y me encontré un fallo al
intentar compilar ffmpeg, en lugar de crearse binarios se quedan como
archivos de texto, osea si el binario ffmpeg debería reconocerse como
ejecutable, ahora se reconoce como archivo de texto, lo curioso es que
se comporta como ejecutable, lo he probado con otros sistemas como
devuan y pasa exactamente lo mismo, pense que seria algun fallo del
makefile pero no, intente compilar un simple código con codeblocks y
pasa igual, no se trata de un fallo del programa sino del compilador,
todas las dependencias fueron instaladas con build-esential
(dependencias del compilador), alguna idea?



Re: testing: upgrade de gcc, plus de 800Mo supplémentaire

2020-11-06 Thread Jérémy Prego



Le 06/11/2020 à 11:08, Étienne Mollier a écrit :
> Bonjour Jérémy,
>
> Jérémy Prego, on 2020-11-06 01:59:33 +0100:
>> 877 Mo pour une simple mise à jour mineur de gcc, ça me parait beaucoup ...
> Par curiosité, j'ai jeté un œil dans le changelog de gcc-10.
> Matthias Klose   Thu, 29 Oct 2020 16:36:48 +0100:
>>  * Also enable the extra checking on amd64, arm64, ppc64el, s390x, and don't
>>strip the executables.  This will be reverted within a few weeks, please
>>don't send bug reports about that.
> Apparemment, Matthias Klose a ajouté des routines de
> vérification supplémentaires dans cette version mineure, et
> laissé les symboles de débugage à l'intérieur des exécutables.
> Je crois que c'est ce qui participe à l'inflation de ces
> paquets.  Ce changement devrait être temporaire.
un grand merci ! je pensais bien a quelque chose comme ça mais je
voulais m'en assurer
> Bonne journée,

De même !



Re: testing: upgrade de gcc, plus de 800Mo supplémentaire

2020-11-06 Thread Étienne Mollier
Bonjour Jérémy,

Jérémy Prego, on 2020-11-06 01:59:33 +0100:
> 877 Mo pour une simple mise à jour mineur de gcc, ça me parait beaucoup ...

Par curiosité, j'ai jeté un œil dans le changelog de gcc-10.
Matthias Klose   Thu, 29 Oct 2020 16:36:48 +0100:
>  * Also enable the extra checking on amd64, arm64, ppc64el, s390x, and don't
>strip the executables.  This will be reverted within a few weeks, please
>don't send bug reports about that.

Apparemment, Matthias Klose a ajouté des routines de
vérification supplémentaires dans cette version mineure, et
laissé les symboles de débugage à l'intérieur des exécutables.
Je crois que c'est ce qui participe à l'inflation de ces
paquets.  Ce changement devrait être temporaire.

Bonne journée,
-- 
Étienne Mollier 
Fingerprint:  8f91 b227 c7d6 f2b1 948c  8236 793c f67e 8f0d 11da
Sent from /dev/pts/1, please excuse my verbosity.


signature.asc
Description: PGP signature


testing: upgrade de gcc, plus de 800Mo supplémentaire

2020-11-05 Thread Jérémy Prego
bonjour,

il y a deux / trois jours de ça, est arrivé dans testing la mise à jour
de gcc de la version 10.2.0-15 vers 10.2.0-16 sauf que quand je fais un
petit aptitude safe-upgrade il me donne ça:
Les paquets suivants seront mis à jour :   
  cpp-10 g++-10 gcc-10 gcc-10-base libasan6 libatomic1 libcc1-0
  libgcc-10-dev libgcc-s1 libgfortran5 libgomp1 libitm1 liblsan0
  libquadmath0 libstdc++-10-dev libstdc++6 libtsan0 libubsan1
18 paquets mis à jour, 0 nouvellement installés, 0 à enlever et 0 non
mis à jour.
Il est nécessaire de télécharger 210 Mo d'archives. Après dépaquetage,
877 Mo seront utilisés.

877 Mo pour une simple mise à jour mineur de gcc, ça me parait beaucoup ...

merci pour tout avis

Jerem



comment logger les compilations par GCC...

2020-08-19 Thread Basile Starynkevitch

Bonsoir


Il y a des cas où il est utile de logger les compilations faites par GCC.


Si vous lisez l'anglais, j'explique en 
https://opensource.stackexchange.com/q/10319/910 les cas où ça pourrait 
être utile. Autrement, on peut songer à faire des statistiques 
(peut-être en vue d'apprentissage machine) en relation avec les 
commandes de compilations.



Sinon, connaissez vous des scripts ou programmes libres ou autres qui 
loguent (avec syslog(3)...) les compilations par GCC.



J'ai codé sur https://github.com/bstarynk/misc-basile/ un programme C++ 
logged-gcc.cc qui le fait.



Merci

--
Basile STARYNKEVITCH   == http://starynkevitch.net/Basile
opinions are mine only - les opinions sont seulement miennes
Bourg La Reine, France; 
(mobile phone: cf my web page / voir ma page web...)



Re: How to build GCC for a specific machine using pbuilder?

2020-06-19 Thread deloptes
Mikhail Morfikov wrote:

> I know, but have you ever seen the debian/ dir in the gcc sources? Take a
> look here[1].
> 

Until now I have not, but what is exactly the problem?

You have what you need in the beginning

include debian/rules.defs
include debian/rules.unpack
include debian/rules.patch

control: $(control_dependencies)
-mkdir -p $(stampdir)
$(MAKE) -f debian/rules.conf $@

configure: control $(unpack_stamp) $(patch_stamp)
$(MAKE) -f debian/rules2 $@

all the rest is supplementary

so now you want to change the configuration and have a look at debian/rules2

It is more complicated, but I still don't understand what you expect here. 

If you know what you want to do with configure, then you can trash this and
create your own simple version.





Re: How to build GCC for a specific machine using pbuilder?

2020-06-19 Thread Mikhail Morfikov
On 19/06/2020 18:36, deloptes wrote:
> Mikhail Morfikov wrote:
> 
>> I've read something about setting flags like: --enable-languages= or
>> --disable-multilib , which I think would speed the whole process up, but
>> unfortunately I have no idea which file in the debian/ dir I should change
>> to build the GCC for my machine only. Any suggestions? Also how to
>> include/exclude patches so they were applied to the source -- there's no
>> "debian/patches/series" file.
> 
> usually it is in debian/rules (this is the debians make file)
> 
> read the docs first - the thing with the patches is explained on the debian
> wiki like
> https://wiki.debian.org/debian/patches
> https://www.debian.org/doc/manuals/maint-guide/modify.en.html
> https://wiki.debian.org/debian/patches
> 
> be patient it works
> 
> 

I know, but have you ever seen the debian/ dir in the gcc sources? Take a look 
here[1]. 

[1]: https://salsa.debian.org/toolchain-team/gcc



signature.asc
Description: OpenPGP digital signature


Re: How to build GCC for a specific machine using pbuilder?

2020-06-19 Thread deloptes
Mikhail Morfikov wrote:

> I've read something about setting flags like: --enable-languages= or
> --disable-multilib , which I think would speed the whole process up, but
> unfortunately I have no idea which file in the debian/ dir I should change
> to build the GCC for my machine only. Any suggestions? Also how to
> include/exclude patches so they were applied to the source -- there's no
> "debian/patches/series" file.

usually it is in debian/rules (this is the debians make file)

read the docs first - the thing with the patches is explained on the debian
wiki like
https://wiki.debian.org/debian/patches
https://www.debian.org/doc/manuals/maint-guide/modify.en.html
https://wiki.debian.org/debian/patches

be patient it works




How to build GCC for a specific machine using pbuilder?

2020-06-19 Thread Mikhail Morfikov
I wanted to change the GCC source a little bit by adding some patches that 
aren't available in Debian. I downloaded the Debian GCC source via "apt-get 
source" . I tried to build the source in the Debian way (using pbuilder) just 
to test how much time would it take. I gave up after 2h because probably it 
builds everything for everyone, and it's not really what I wanted it to do. 

I've read something about setting flags like: --enable-languages= or 
--disable-multilib , which I think would speed the whole process up, but 
unfortunately I have no idea which file in the debian/ dir I should change to 
build the GCC for my machine only. Any suggestions? Also how to include/exclude
patches so they were applied to the source -- there's no 
"debian/patches/series" 
file.



signature.asc
Description: OpenPGP digital signature


Re: Problème de compilation avec gcc 9.2 (debian/testing)

2019-10-31 Thread BERTRAND Joël
Je me réponds à moi-même. Le problème provient à la fois de binutils et
d'automake.

Binutils parce que le linker est beaucoup plus tatillons sur l'ordre
des bibliothèques quand elles sont réentrantes. Et automake, parce que
celui-ci gère l'ordre des bibliothèques un peu comme il le décide
(l'ordre des bibliothèques sur la ligne de commande change entre
debian/stable et debian/testing, je n'ai pas encore compris pourquoi).

JKB



Problème de compilation avec gcc 9.2 (debian/testing)

2019-10-27 Thread BERTRAND Joël

Bonjour à tous,

	Depuis la mise à jour de mon poste de travail (debian/testing), j'ai un 
problème de compilation assez surprenant que je n'arrive à résoudre.


Sources :
http://www.rpl2.fr/download/rpl-4.1.31-daily-20191027.tar.bz2

Procédure de compilation :
./autogen.sh
cd ..
mkdir build
cd build
../rpl/configure --enable-native --enable-rplcas

Et attendre l'erreur :
 g++ -g -O2 -mtune=native -march=native -O2 -malign-double -Wall 
-funsigned-char -fpermissive -fno-strict-aliasing 
-DGIAC_GENERIC_CONSTANTS -pthread -o icas icas.o 
/export/home/bertrand/gopher/rpl2/build-amd64/rplcas/giac-1.5.0/src/.libs/libgiac.a 
/import/home/bertrand/gopher/rpl2/build-amd64/rplcas/lib/libpari.a 
/import/home/bertrand/gopher/rpl2/build-amd64/rplcas/lib/ntl.a 
/import/home/bertrand/gopher/rpl2/build-amd64/rplcas/lib/libcocoa.a 
/import/home/bertrand/gopher/rpl2/build-amd64/tools/gsl-2.6/.libs/libgsl.a 
/import/home/bertrand/gopher/rpl2/build-amd64/rplcas/lib/libgmp.a 
/import/home/bertrand/gopher/rpl2/build-amd64/rplcas/lib/libmpfr.a 
/import/home/bertrand/gopher/rpl2/build-amd64/rplcas/lib/libmpfi.a 
./.libs/libxcas.a 
/export/home/bertrand/gopher/rpl2/build-amd64/rplcas/giac-1.5.0/src/.libs/libgiac.a 
-lrt -lpthread /usr/lib/x86_64-linux-gnu/libcurl-gnutls.so -lsamplerate 
-llapack -lblas -lgfortran -ldl -lpng16 -lm -pthread
/usr/bin/ld: 
/import/home/bertrand/gopher/rpl2/build-amd64/rplcas/lib/libmpfr.a(get_z_exp.o): 
référence au symbole non défini « __gmpz_realloc2 »
/usr/bin/ld : /usr/lib/x86_64-linux-gnu/libgmp.so.10 : erreur lors de 
l'ajout de symboles : DSO manquant dans la ligne de commande

collect2: error: ld returned 1 exit status

	Pour un certain nombre de raisons, les bibliothèques sont compilées 
statiquement (ça permet de ne pas segfaulter lorsque l'on charge des 
modules externes).


	L'erreur varie en fonction de l'ordre des bibliothèques. Avec gcc 8, ça 
compile sans problème.


mpfr est configuré comme suit :
../../../rpl/rplcas/mpfr-4.0.2/configure 
--with-gmp=/import/home/bertrand/gopher/rpl2/build-amd64/rplcas 
--disable-shared --enable-static 
--prefix=/import/home/bertrand/gopher/rpl2/build-amd64/rplcas
et le script configure trouve bien les en-têtes et la version statique 
de libgmp.


	Naturellement, le symbole non trouvé est bien présent dans la 
bibliothèque libgmp.a :
rayleigh:[~/gopher/rpl2/build-amd64/rplcas/lib] > nm -a libgmp.a | grep 
__gmpz_realloc2

 T __gmpz_realloc2

J'avoue que je ne sais plus où chercher. Toute idée est la bienvenue.

Bien cordialement,

JKB



Re: Compiling Linux with "bdver2" gcc optimization option

2019-08-21 Thread Étienne Mollier
Franco Martelli, on 2019-08-20:
> mm/memory.o: warning: objtool: remap_pfn_range()+0xd5: unsupported 
> intra-function call
>
> that it's part of linux-kbuild-4.19 package maybe I should submit a bug
> report to this package or is another one a better choice?

Hi Franco,

Should you submit a bug report, it might be a good target.  The
end result would be something like a bug against the kernel,
although it has more to do with the toolbox around its building
procedure.  Please make sure to include the context of your
build, the optimization with -march=bdver2, if you proceed.

But before doing that, may I suggest to have a look at the
"Compile-time stack metadata validation", available in
tools/objtool/Documentation/stack-validation.txt?  It is very
interesting, I only stumbled upon it recently, it describes the
purpose of objtool.  You can read it from Linux source code, or
online here:


https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/tools/objtool/Documentation/stack-validation.txt

Furthermore, it answers accurately to your original question
from the 13th of August:
> compiling the kernel up to Debian 9.x stretch all worked fine but with
> Debian 10 buster I get a lot of warning messages:
>
> 
> mm/memory.o: warning: objtool: remap_pfn_range()+0xd5: unsupported 
> intra-function call
[...]
> arch/x86/kernel/tsc.o: warning: objtool: tsc_refine_calibration_work()+0xd8: 
> stack state mismatch: cfa1=7+48 cfa2=7+40
> 
>
> what does it means?

Short answer, it means that the -march=bdver2 optimization flag
is interfering with the static stack frame analyser at kernel
build time, probably by adjunction of unrecognised CPU
instructions, at least unrecognised by objtool, inside the
object code.

Kind regards,
-- 
Étienne Mollier 
  5ab1 4edf 63bb ccff 8b54  2fa9 59da 56fe fff3 882d
Note to myself: RTWM, Reread The Warning Message




signature.asc
Description: OpenPGP digital signature


Re: Compiling Linux with "bdver2" gcc optimization option

2019-08-20 Thread Franco Martelli
On 19/08/19 at 21:18, Étienne Mollier wrote:
> Franco Martelli, on 2019-08-19:
>> I was thinking to submit a bug report against gcc-8 package. Now that I
>> have a work around, "bdver1" compiles without warnings, I can say
>> enough, what do you think about?
> 
> I don't know, to me it sounds more like little bugs on kernel
> side,
[ ... ]
> Gcc-8 on its side is just trying its best to help one to develop
> better code.  Its heuristics may not apply very well on kernel
> object code however.  If you can reproduce this issue and
> identify it as a false positive with a sample code, that is
> another story of course.

you're right, I compiled tar and hello program with -march=bdver2 option
without problem so gcc-8 is sure. I saw that all warnings that they
appear during kernel compilation process concern "objtool"

mm/memory.o: warning: objtool: remap_pfn_range()+0xd5: unsupported
intra-function call

that it's part of linux-kbuild-4.19 package maybe I should submit a bug
report to this package or is another one a better choice?

Best regards

-- 
Franco Martelli



Re: Compiling Linux with "bdver2" gcc optimization option

2019-08-19 Thread Étienne Mollier
Franco Martelli, on 2019-08-19:
> I was thinking to submit a bug report against gcc-8 package. Now that I
> have a work around, "bdver1" compiles without warnings, I can say
> enough, what do you think about?

I don't know, to me it sounds more like little bugs on kernel
side, patches silencing warnings from Gcc, one way or another,
happen quite often on that side.  See Linux 5.2.9 changelog,
there are a few ones there:

https://cdn.kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.2.9

Since there is no official support for x86 architecture specific
build targets (other than the ones listed in Kconfig), chances
are the bug report would end up in "wontfix" state.  But you can
always give it a try; perhaps an actual break is lurking there,
waiting to happen in production.

Gcc-8 on its side is just trying its best to help one to develop
better code.  Its heuristics may not apply very well on kernel
object code however.  If you can reproduce this issue and
identify it as a false positive with a sample code, that is
another story of course.

Cheers,
-- 
Étienne Mollier 
  5ab1 4edf 63bb ccff 8b54  2fa9 59da 56fe fff3 882d




signature.asc
Description: OpenPGP digital signature


Re: Compiling Linux with "bdver2" gcc optimization option

2019-08-19 Thread Franco Martelli
I was thinking to submit a bug report against gcc-8 package. Now that I
have a work around, "bdver1" compiles without warnings, I can say
enough, what do you think about?
Best regards

-- 
Franco Martelli



Re: Compiling Linux with "bdver2" gcc optimization option

2019-08-16 Thread Étienne Mollier
Franco Martelli, on 2019-08-16:
> On 16/08/19 at 17:22, Étienne Mollier wrote:
[...]
> > Compilers may have good optimization routines to boost the speed
> > of the code in several situations, but in other ones there are
> > trade-offs to take between size and performance of the code.  I
> > personally prefer smaller sized executables (-Os): they fit in
> > less pages, so uses less CPU cache, and leave more room for my
> > programs to get more of their own data in cache (or I might
> > simply have spent too much time on suckless.org.  ;)
>
> Do you remember which kernel CONFIG switch lets to do this optimization?

You can set these values as following if you want to optimize
for size, or the other way around for performance:

# CONFIG_CC_OPTIMIZE_FOR_PERFORMANCE is not set
CONFIG_CC_OPTIMIZE_FOR_SIZE=y

Then "make oldconfig" to validate your changes.  And same as
before, do your own measures.  ;)

> > Activating CPU specific options is interesting on some
> > particular use cases, but newer instruction often require
> > setting up various bits in the CPU before use, which tends to
> > inflate the resulting executable.  This may be interesting for
> > scientific applications, or programs dealing with big data
> > arrays in general.  In kernel mode however, the only case I can
> > think of where CPU specific accelerators would be beneficial are
> > disk ciphering and RAID arrays, for which I believe there is
> > already some runtime detection of available instructions, even
> > with the generic compiler options.
>
> I have four disks in a RAID 5 software array configuration on my system,
> they are managed by mdadm this is my /proc/mdstat file:
>
> $ cat /proc/mdstat
> Personalities : [raid0] [raid1] [raid10] [raid6] [raid5] [raid4]
> md0 : active raid5 sda1[0] sdb1[1] sdd1[3](S) sdc1[2]
>   1953258496 blocks super 1.2 level 5, 512k chunk, algorithm 2 [3/3]
> [UUU]
>
> unused devices: 

If you have a look at "sudo dmesg" output, near the beginning,
the kernel outputs a series of performance testing out of
various RAID topologies, and keeps the best for runtime.  I'm
speaking from memory, as I have no RAID array at hand to check
this.

[...]
> > Or just see how perform your usual programs, if there are
> > visible improvements.
> >
> > Have fun,  :)
>
> Yes I agree the optimization won't impact on performance in a way that
> is perceptively by an human there are tweak more important in the kernel
> such as CONFIG_HZ_1000=y
> I always take measurement of the time employee by kernel compilation out
> of curiosity.
> Thanks again for the tips, best regards

You're welcome,  :)
-- 
Étienne Mollier 
  5ab1 4edf 63bb ccff 8b54  2fa9 59da 56fe fff3 882d




signature.asc
Description: OpenPGP digital signature


Re: Compiling Linux with "bdver2" gcc optimization option

2019-08-16 Thread Franco Martelli
On 16/08/19 at 17:22, Étienne Mollier wrote:
> Bonjour,
> 
> Woops, this sounds a bit like I might not have used a very clear
> wording.  If I were at your place, I would proceed so; but I
> don't have a Piledriver CPU to do actual testing on my side.
> I'm still stuck with an old K10, not to mention my laptop, which
> comes with an old regular Atom.  :)
> 
> I did try to replace the k8 option by amdfam10 though.  In the
> half hundred thousand lines of logs issued by the build, I get
> something like a dozen differences between k8 and k10.  There
> were a tremendous amount of warnings too, but some of the ones
> you encountered did not appear: the thing with the missing jump
> target for instance, nor the ANNOTATE_NOSPEC_ALTERNATIVE on the
> retpoline thing.  I am running Debian Sid, currently shipping
> with Gcc 9, so this is a difference to take in account though.
> Finally, building an upstream Linux 5.2 kernel instead of
> Buster's 4.19 does not show most of the warnings I encountered,
> as these are being fixed as they come, but probably not as well
> in LTS kernels.
> 
> Doing a third run with addition of the tuning options (-mtune)
> made almost no difference at all, except on the build number and
> the CRC hash.  It seems to me that the architecture specific
> (-march) option already applies the proper tuning, at least for
> my architecture.
> 
> My last manipulation consisted in building Linux upstream 5.2.9,
> released lately, with -march=amdfam10, and this one is running
> quite well so far:
> 
>   $ uname -rv
>   5.2.9-k10 #1 SMP PREEMPT Fri Aug 16 16:13:08 CEST 2019
> 
> But again, no messages worth mentioning during the compilation.
> 
> Do your warnings appear when your build targets k8?
> Or when building a generic x86_64 kernel?

Actually I run kernel built with "k8" option, it works fine, I got no
warning during the compilation.

Investigating deeper your tips about "amdfam10" I checked the gcc
options web page:
https://gcc.gnu.org/onlinedocs/gcc/x86-Options.html
amdfam10 optimization was for Family 10 CPU but I have a Family 15h CPU
I notice that it also exists a "bdver1" for my CPU family so I wanted
give it a try and I compiled the kernel source with "bdver1" and
surprise I got no warning, all worked fine, :-) the command line I use
to compile is:

~/linux-source-4.19$ time make -s -j9 ; make -s -j9 modules

> Compilers may have good optimization routines to boost the speed
> of the code in several situations, but in other ones there are
> trade-offs to take between size and performance of the code.  I
> personally prefer smaller sized executables (-Os): they fit in
> less pages, so uses less CPU cache, and leave more room for my
> programs to get more of their own data in cache (or I might
> simply have spent too much time on suckless.org.  ;)

Do you remember which kernel CONFIG switch lets to do this optimization?

> 
> Activating CPU specific options is interesting on some
> particular use cases, but newer instruction often require
> setting up various bits in the CPU before use, which tends to
> inflate the resulting executable.  This may be interesting for
> scientific applications, or programs dealing with big data
> arrays in general.  In kernel mode however, the only case I can
> think of where CPU specific accelerators would be beneficial are
> disk ciphering and RAID arrays, for which I believe there is
> already some runtime detection of available instructions, even
> with the generic compiler options.

I have four disks in a RAID 5 software array configuration on my system,
they are managed by mdadm this is my /proc/mdstat file:

$ cat /proc/mdstat
Personalities : [raid0] [raid1] [raid10] [raid6] [raid5] [raid4]
md0 : active raid5 sda1[0] sdb1[1] sdd1[3](S) sdc1[2]
  1953258496 blocks super 1.2 level 5, 512k chunk, algorithm 2 [3/3]
[UUU]

unused devices: 

> 
> To be honest, I don't believe the performance gain to get from
> the compiler is tremendous here.  Figures from the author of the
> patch are there to tell us there is a gain indeed; but when you
> investigate in detail the percentage of performance brought by
> the tuning, it is only about 0.03% for the selected benchmark on
> median values.  See the "Data" section at the very end of the
> README, and do your own calculations:
> 
>   https://github.com/graysky2/kernel_gcc_patch/blob/master/README.md
> 
> The best you can do here is to do your own measures with your
> own pattern of usage.  If you are a developer, you can run timed
> builds of Linux, and see the time it takes.  If you are inclined
> toward image rendering speeds, there are a few demo-scenes out
> there where you might get a few figures such as the frame 

Re: Compiling Linux with "bdver2" gcc optimization option

2019-08-16 Thread Étienne Mollier
Bonjour,

Franco Martelli, on 2019-09-14:
> On 13/08/19 at 19:35, Étienne Mollier wrote:
[...]
> > I would do a few tests with a virtual
> > machine supporting bdver2 instructions before going live anyway,
> > and backups stored far away from the machine once testing, and
> > possibly without contact with that kernel.
>
> I didn't boot that kernel, I don't rely on it. Thanks if you can
> investigate on what happens during compilation process.

Woops, this sounds a bit like I might not have used a very clear
wording.  If I were at your place, I would proceed so; but I
don't have a Piledriver CPU to do actual testing on my side.
I'm still stuck with an old K10, not to mention my laptop, which
comes with an old regular Atom.  :)

I did try to replace the k8 option by amdfam10 though.  In the
half hundred thousand lines of logs issued by the build, I get
something like a dozen differences between k8 and k10.  There
were a tremendous amount of warnings too, but some of the ones
you encountered did not appear: the thing with the missing jump
target for instance, nor the ANNOTATE_NOSPEC_ALTERNATIVE on the
retpoline thing.  I am running Debian Sid, currently shipping
with Gcc 9, so this is a difference to take in account though.
Finally, building an upstream Linux 5.2 kernel instead of
Buster's 4.19 does not show most of the warnings I encountered,
as these are being fixed as they come, but probably not as well
in LTS kernels.

Doing a third run with addition of the tuning options (-mtune)
made almost no difference at all, except on the build number and
the CRC hash.  It seems to me that the architecture specific
(-march) option already applies the proper tuning, at least for
my architecture.

My last manipulation consisted in building Linux upstream 5.2.9,
released lately, with -march=amdfam10, and this one is running
quite well so far:

$ uname -rv
5.2.9-k10 #1 SMP PREEMPT Fri Aug 16 16:13:08 CEST 2019

But again, no messages worth mentioning during the compilation.

Do your warnings appear when your build targets k8?
Or when building a generic x86_64 kernel?


> > Note that someone from the Gentoo community has developed a set
> > of patches to expand the possibilities of optimization for the
> > kernel, depending on Linux and GCC versions.  You may be
> > interested in the following one for Buster:
> >
> > 
> > https://github.com/graysky2/kernel_gcc_patch/blob/master/enable_additional_cpu_optimizations_for_gcc_v8.1%2B_kernel_v4.13%2B.patch
> >
> > These mainly apply changes in various code sections to put the
> > flags in place, and provide options through the .config file of
> > the source code.  I haven't tested it, but I don't believe this
> > will solve your warnings, reading through the patch.  Yet it
> > does a bit more than just replacing the compiler flag: there is
> > notably a component related to L1 cache shift which is modified
> > too.  That should bring an appreciable performance boost if it
> > corrects cache line mismatch.
>
> Thanks, but I don't want to patch the kernel, that change to the
> Makefile was enough simple in order to get the optimization that I
> looking for.

Fair enough, I reread the whole patch, and your modification
seems sufficient, I believe.

> > Please be aware that CPU optimizations in kernel, targeting Zen
> > and Skylake in this case, seemed to be hardly detectable, or
> > even counter productive, with various computer usage patterns,
> > according to measures done by Phoronix earlier this year:
> >
> > https://www.phoronix.com/scan.php?page=article=linux-50-march=1
> >
> > Of course this may not be the case for your own typical load,
> > but I would recommend to do a few measures, to assess the actual
> > performance gain on your machine with, and without, CPU specific
> > compiler optimizations.
>
> I never experimented benchmark with and without bdver2 option, I assumed
> that if it exists an option for k8 in the kernel then changing it to
> bdver2 it would be good (I hope).

Compilers may have good optimization routines to boost the speed
of the code in several situations, but in other ones there are
trade-offs to take between size and performance of the code.  I
personally prefer smaller sized executables (-Os): they fit in
less pages, so uses less CPU cache, and leave more room for my
programs to get more of their own data in cache (or I might
simply have spent too much time on suckless.org.  ;)

Activating CPU specific options is interesting on some
particular use cases, but newer instruction often require
setting up various bits in the CPU before use, which tends to
inflate the resulting executable.  This may be interesting for
scientific applications, or programs dealing with big data
arrays in g

Re: Compiling Linux with "bdver2" gcc optimization option

2019-08-14 Thread Franco Martelli
On 13/08/19 at 19:35, Étienne Mollier wrote:
> Hi Franco,
> 
> I'm not fluent enough in GCC 8 for x86_64 to answer to all the
> various warnings you indicated.  Some may be harmless, and some
> may eat your data.  I would do a few tests with a virtual
> machine supporting bdver2 instructions before going live anyway,
> and backups stored far away from the machine once testing, and
> possibly without contact with that kernel.

I didn't boot that kernel, I don't rely on it. Thanks if you can
investigate on what happens during compilation process.
> 
> I also recall having had to move from ORC to DWARF unwinder to
> get the build working, but that was on old OS levels, not on
> newer ones, due to the libelf being too old.
> 
> Some of these seem related to CPU vulnerabilities mitigations,
> and might be worth a bug report against the kernel, either
> Debian or upstream, assuming it also appears /without/ your
> -march=bdver2 flag:
> 
>> mm/memory.o: warning: objtool: If this is a retpoline, please patch it in 
>> with alternatives and annotate it with ANNOTATE_NOSPEC_ALTERNATIVE.

I had asked to debian-kernel mailing list but nobody answered, maybe
could be something related to gcc 8 since all previous Debian kernel
versions worked with bdver2 optimization
> 
> Note that someone from the Gentoo community has developed a set
> of patches to expand the possibilities of optimization for the
> kernel, depending on Linux and GCC versions.  You may be
> interested in the following one for Buster:
> 
>   
> https://github.com/graysky2/kernel_gcc_patch/blob/master/enable_additional_cpu_optimizations_for_gcc_v8.1%2B_kernel_v4.13%2B.patch
> 
> These mainly apply changes in various code sections to put the
> flags in place, and provide options through the .config file of
> the source code.  I haven't tested it, but I don't believe this
> will solve your warnings, reading through the patch.  Yet it
> does a bit more than just replacing the compiler flag: there is
> notably a component related to L1 cache shift which is modified
> too.  That should bring an appreciable performance boost if it
> corrects cache line mismatch.

Thanks, but I don't want to patch the kernel, that change to the
Makefile was enough simple in order to get the optimization that I
looking for.
> 
> Please be aware that CPU optimizations in kernel, targeting Zen
> and Skylake in this case, seemed to be hardly detectable, or
> even counter productive, with various computer usage patterns,
> according to measures done by Phoronix earlier this year:
> 
>   https://www.phoronix.com/scan.php?page=article=linux-50-march=1
> 
> Of course this may not be the case for your own typical load,
> but I would recommend to do a few measures, to assess the actual
> performance gain on your machine with, and without, CPU specific
> compiler optimizations.

I never experimented benchmark with and without bdver2 option, I assumed
that if it exists an option for k8 in the kernel then changing it to
bdver2 it would be good (I hope).

-- 
Franco Martelli



Re: Compiling Linux with "bdver2" gcc optimization option

2019-08-13 Thread Étienne Mollier
Franco Martelli , on 2019-09-13:
> Hi, everybody
>
> in order to achieve Linux kernel optimized for my CPU AMD FX-8350
> Bulldozer2 I changed the line 121 of linux-source-4.19/arch/x86/Makefile
> from:
>
> cflags-$(CONFIG_MK8) += $(call cc-option,-march=k8)
>
> to:
>
> cflags-$(CONFIG_MK8) += $(call cc-option,-march=bdver2) \
> $(call cc-option,-mtune=bdver2,$(call 
> cc-option,-mtune=generic))
>
> compiling the kernel up to Debian 9.x stretch all worked fine but with
> Debian 10 buster I get a lot of warning messages:
[...snipped warnings...]
> what does it means? Is there a way to get the kernel optimized for my
> CPU as it happened in the previous Debian versions?

Hi Franco,

I'm not fluent enough in GCC 8 for x86_64 to answer to all the
various warnings you indicated.  Some may be harmless, and some
may eat your data.  I would do a few tests with a virtual
machine supporting bdver2 instructions before going live anyway,
and backups stored far away from the machine once testing, and
possibly without contact with that kernel.  That is, if it
happens to boot; these sort of things do not look very good
for instance:

> arch/x86/kernel/sys_x86_64.o: warning: objtool: get_align_mask()+0x1d: can't 
> find jump dest instruction at .text+0x2f

I also recall having had to move from ORC to DWARF unwinder to
get the build working, but that was on old OS levels, not on
newer ones, due to the libelf being too old.

Some of these seem related to CPU vulnerabilities mitigations,
and might be worth a bug report against the kernel, either
Debian or upstream, assuming it also appears /without/ your
-march=bdver2 flag:

> mm/memory.o: warning: objtool: If this is a retpoline, please patch it in 
> with alternatives and annotate it with ANNOTATE_NOSPEC_ALTERNATIVE.


Note that someone from the Gentoo community has developed a set
of patches to expand the possibilities of optimization for the
kernel, depending on Linux and GCC versions.  You may be
interested in the following one for Buster:


https://github.com/graysky2/kernel_gcc_patch/blob/master/enable_additional_cpu_optimizations_for_gcc_v8.1%2B_kernel_v4.13%2B.patch

These mainly apply changes in various code sections to put the
flags in place, and provide options through the .config file of
the source code.  I haven't tested it, but I don't believe this
will solve your warnings, reading through the patch.  Yet it
does a bit more than just replacing the compiler flag: there is
notably a component related to L1 cache shift which is modified
too.  That should bring an appreciable performance boost if it
corrects cache line mismatch.

Please be aware that CPU optimizations in kernel, targeting Zen
and Skylake in this case, seemed to be hardly detectable, or
even counter productive, with various computer usage patterns,
according to measures done by Phoronix earlier this year:

https://www.phoronix.com/scan.php?page=article=linux-50-march=1

Of course this may not be the case for your own typical load,
but I would recommend to do a few measures, to assess the actual
performance gain on your machine with, and without, CPU specific
compiler optimizations.

Kind regards,
-- 
Étienne Mollier 
  5ab1 4edf 63bb ccff 8b54  2fa9 59da 56fe fff3 882d



signature.asc
Description: OpenPGP digital signature


Compiling Linux with "bdver2" gcc optimization option

2019-08-13 Thread Franco Martelli
Hi, everybody

in order to achieve Linux kernel optimized for my CPU AMD FX-8350
Bulldozer2 I changed the line 121 of linux-source-4.19/arch/x86/Makefile
from:

cflags-$(CONFIG_MK8) += $(call cc-option,-march=k8)

to:

cflags-$(CONFIG_MK8) += $(call cc-option,-march=bdver2) \
$(call cc-option,-mtune=bdver2,$(call
cc-option,-mtune=generic))

compiling the kernel up to Debian 9.x stretch all worked fine but with
Debian 10 buster I get a lot of warning messages:


mm/memory.o: warning: objtool: remap_pfn_range()+0xd5: unsupported
intra-function call
mm/memory.o: warning: objtool: If this is a retpoline, please patch it
in with alternatives and annotate it with ANNOTATE_NOSPEC_ALTERNATIVE.
mm/mlock.o: warning: objtool: __munlock_isolate_lru_page()+0xd6: stack
state mismatch: cfa1=7+64 cfa2=7+56
mm/mlock.o: warning: objtool: clear_page_mlock()+0x39: unsupported
instruction in callable function
mm/mlock.o: warning: objtool: mlock_vma_page()+0x8e: sibling call from
callable instruction with modified stack frame
mm/mlock.o: warning: objtool: munlock_vma_page()+0x163: return with
modified stack frame
kernel/bpf/stackmap.o: warning: objtool: bpf_get_stack()+0x68: return
with modified stack frame
kernel/bpf/sockmap.o: warning: objtool: bpf_exec_tx_verdict()+0x436:
stack state mismatch: cfa1=7+168 cfa2=7+160
kernel/power/qos.o: warning: objtool: pm_qos_remove_request()+0x6d:
return with modified stack frame
arch/x86/kernel/dumpstack.o: warning: objtool: __die()+0xc2: return with
modified stack frame
arch/x86/kernel/cpu/amd.o: warning: objtool: bsp_init_amd()+0xb1: can't
find jump dest instruction at .text+0x193
arch/x86/kvm/x86.o: warning: objtool: kvm_set_cr3()+0x18: can't find
jump dest instruction at .text+0x5cc0
arch/x86/kernel/ldt.o: warning: objtool: write_ldt()+0x110: can't find
jump dest instruction at .text+0x56a
mm/mmap.o: warning: objtool: init_user_reserve()+0x34: return with
modified stack frame
mm/mmap.o: warning: objtool: init_admin_reserve()+0x34: return with
modified stack frame
mm/mmap.o: warning: objtool: vm_brk_flags()+0x55: stack state mismatch:
cfa1=7+80 cfa2=7+72
mm/mmap.o: warning: objtool: do_mmap()+0x1bf: stack state mismatch:
cfa1=7+80 cfa2=7+72
mm/mprotect.o: warning: objtool: change_protection()+0x4f5: can't find
jump dest instruction at .text+0x5a3
mm/mremap.o: warning: objtool: move_page_tables()+0x60: stack state
mismatch: cfa1=7+144 cfa2=7+136
mm/mremap.o: warning: objtool: __se_sys_mremap()+0x12d: stack state
mismatch: cfa1=7+160 cfa2=7+152
arch/x86/kernel/sys_x86_64.o: warning: objtool: get_align_mask()+0x1d:
can't find jump dest instruction at .text+0x2f
mm/page_vma_mapped.o: warning: objtool: check_pte()+0x108: return with
modified stack frame
mm/page_vma_mapped.o: warning: objtool: page_vma_mapped_walk()+0x15e:
stack state mismatch: cfa1=7+56 cfa2=7+40
mm/pagewalk.o: warning: objtool: __walk_page_range()+0x1be: return with
modified stack frame
kernel/printk/printk.o: warning: objtool: devkmsg_write.cold.15()+0x30:
can't find jump dest instruction at .text.unlikely+0x2a1
arch/x86/kvm/emulate.o: warning: objtool: rsm_load_state_32()+0x2e2:
can't find jump dest instruction at .text+0xfa4
arch/x86/kvm/i8254.o: warning: objtool: pit_ioport_read()+0x141: can't
find jump dest instruction at .text+0x7cb
arch/x86/kvm/mmu.o: warning: objtool:
kvm_calc_tdp_mmu_root_page_role()+0xb: can't find jump dest instruction
at .text+0x3fd
arch/x86/kvm/lapic.o: warning: objtool: recalculate_apic_map()+0x2f6:
can't find jump dest instruction at .text+0x968
mm/rmap.o: warning: objtool: try_to_unmap_one()+0x4d1: can't find jump
dest instruction at .text+0x185b
arch/x86/kvm/ioapic.o: warning: objtool:
rtc_irq_eoi_tracking_reset()+0x45: return with modified stack frame
arch/x86/kvm/ioapic.o: warning: objtool: ioapic_mmio_write()+0x62: stack
state mismatch: cfa1=7+48 cfa2=7+40
arch/x86/kvm/ioapic.o: warning: objtool: ioapic_mmio_read()+0xe5: stack
state mismatch: cfa1=7+64 cfa2=7+56
arch/x86/kvm/ioapic.o: warning: objtool: kvm_get_ioapic()+0x72: return
with modified stack frame
arch/x86/kvm/ioapic.o: warning: objtool: kvm_set_ioapic()+0x105: return
with modified stack frame
arch/x86/kvm/irq_comm.o: warning: objtool: kvm_set_msi_irq()+0x60:
return with modified stack frame
kernel/rcu/sync.o: warning: objtool: rcu_sync_init()+0x52: return with
modified stack frame
mm/vmalloc.o: warning: objtool: vmalloc_to_page()+0x150: return with
modified stack frame
mm/vmalloc.o: warning: objtool: vunmap_page_range()+0x2fc: return with
modified stack frame
mm/vmalloc.o: warning: objtool: vm_unmap_ram()+0x11f: sibling call from
callable instruction with modified stack frame
mm/vmalloc.o: warning: objtool: vmap_page_range_noflush()+0x2ec: return
with modified stack frame
mm/vmalloc.o: warning: objtool: vread()+0x1cf: stack state mismatch:
cfa1=7+96 cfa2=7+88
mm/vmalloc.o: warning: objtool: vwrite()+0x176: stack state mismatch:
cfa1=7+96 cfa2=7+88
arch/x86/kvm/cpuid.o: warning: objtool: do_cpuid_ent()+0x6b4: 

Re: Arduino and Python or gcc compiler?

2018-07-22 Thread cyaiplexys

On 07/22/2018 02:20 PM, Joe wrote:

...snip...


At the level of the Arduino, and what it is used for, the C required
isn't going to differ too much from Python. You're mostly going to
be bit-banging. If you know one modern procedural language, you can at
least potter around in others quite easily.


Judging by what others are saying plus what you say, it looks like 
sticking to C would actually be easier than trying to get it to work 
with Python.


...snip...


That's ok. I am getting good enough in Python (and have made my own
libraries at times) that if it's not there, I might be able to create
one. Thing is, Raspberry Pi seems more like a computer, rather than a
way to experiment controlling things (safely) like electronic
circuits on breadboards for the fun of it.


It is indeed. A Pi running a Debian desktop is painfully slow, but it
works. What it's surprisingly good at is running streaming software for
Internet TV, the system is optimised for high-definition HDMI output.
Google raspberry pi tv. You won't do that on an Arduino.


Good thing I don't have a need for running streaming software or 
anything like that. So that's not a problem.


...snip...


The kit comes with a LCD display, actually, and tutorials and
examples on using it. That I know I'll find interesting too. Ever
since I saw a video about LCD displays on a "The 8-bit guy" YouTube
video, I been wanting to toy around with those things.


Wait till you've had a bit of practice with them before you try writing
a driver for a new LCD display. The documentation for them is skimpy,
and you may need to guess a bit. I've made a few for the PIC 18F
series, which is comparable to this Atmel series.


I think what I'll be doing is just what is in the tutorials, at first. 
And toying around with what they have available. Looks like they already 
have a library built for the LCD display (it's a monochrome 20 x 40 or 
something like that) and some sample code on how to use it.



I am thinking this is going to be quite an interesting and fun hobby.



Certainly. My only work with the Arduino was using one as a graphics
co-processor for a PIC project to drive a 320x240 touch screen for a
camera control panel. There was a suitable Arduino library but not one
for the PIC, and time was in short supply. One drawback to the Arduino
here is that it doesn't have a lot of memory, so the screen fonts were
a bit chunky.


That's another thing I am noticing but a friend tells me I really won't 
need a lot of memory just for tinkering around with things. They do have 
a shield with an SD card reader/writer for it but my friend tells me 
that doesn't expand how much memory is available to store programs, but 
would only come in handy if you do a lot of writing of data or something.


Well, I guess you good folks got me straightened out. It looks like I 
won't need anything but what comes with the kit and the downloads to do 
the tinkering and will have to do it in C. I'll just forget about Python 
I guess. Not too big a problem.


I'm also amazed that Debian doesn't have much for the Arduino in the repo.




Re: Arduino and Python or gcc compiler?

2018-07-22 Thread Joe
On Sun, 22 Jul 2018 11:34:33 -0400
cyaiplexys  wrote:

> On 07/22/2018 11:13 AM, Erik Christiansen wrote:
> > On 22.07.18 10:29, cyaiplexys wrote:  
> >> I think my mindset also came from my days of trying to program the
> >> WowWee RoboSapien RS Media (ARM/Linux with Java). That was like a
> >> fully programmable computer and robot all in one.  
> > 
> > Then the full arduino environment will be more comfortable than raw
> > C on bare iron. While I program AVRs, including the ATmega328P used
> > on most arduino boards, in C and assembler, I understand that the
> > arduino environment provides a high level programming interface
> > which allows e.g. artists to write "sketches" to perform real-time
> > tasks. 

This is the great strength of the Arduino. Run the IDE on Windows or
Linux (the program format is the same on both), select the board you
have, plug it into a serial port (USB/serial chip these days) and
you're away. The Arduino board has a built-in bootloader, meaning you
don't need a specialist programmer, just a serial port.
 
> 
> After watching some YouTube tutorials, I am starting to see that. The 
> IDE isn't "real" C in that you're not directly compiling using gcc
> from the command line. It does everything for you behind the scenes.
> Not used to that since my old Windows days.
> 
> > There is quite a bit of peripheral hardware on an ATmega328P, from
> > serial USART, through timer/counters useful for e.g. PWM motor
> > control, through multi-channel 10 bit Analogue to digital
> > converter. The chip datasheet is 440 pages in length, and learning
> > to initialise and drive the on-chip paraphernalia is a non-trivial
> > task. The arduino environment provides a library of drivers AIUI,
> > to allow programming at the application level, rather than writing
> > your own drivers¹. It won't necessarily give you the last
> > microsecond of real-time performance, but it should be a low-pain
> > introduction. (Must be some reason for its popularity, I figure.)  
> 
> I got the starter kit with the Arduino UNO R3. Not knowing what that 
> means yet (I need to read into that) I am assuming that ATmega328P is 
> the Arduino MEGA and not the Arduino UNO R3? Or is it the CPU in all 
> Arduinos? I'll have to look into that. I did find out a bit after my 
> first post in this thread that Arduino isn't and ARM processor.
> 
> >> I don't mind using C, but am pretty bad at it. Maybe this is the
> >> time to finally get better at it.  
> > 
> > Learning two things at once is for self-driven stoics only, at
> > least if they're both non-trivial. Beginning with a friendly
> > development environment and application framework, complete with
> > examples which could be downloaded and used for tutorial purposes,
> > avoids the pain of a lot of stuff failing not because of coding
> > errors, but because not yet grokking the 440 pages of hardware spec
> > left one bit in that other mode enabling register unset, so it'll
> > never work until you find the clue in the doco.
> > 
> > There must be an arduino ML or forum, which would be a sanity saver.
> > Once master of that, then there's the AVRfreaks forum when the more
> > serious C journey begins. 

At the level of the Arduino, and what it is used for, the C required
isn't going to differ too much from Python. You're mostly going to
be bit-banging. If you know one modern procedural language, you can at
least potter around in others quite easily. 
> 
> I'll have to look into these forums and find one to join. I find
> forums and lists, etc. to be indispensable when learning new stuff.
> And also even if I am good with using something (like I am with
> Debian), still having some community based help had been very useful.
> 
> > OK, there are one or two arduinos with ARM chips, but I don't count
> > that as original arduino.  
> 
> Maybe that was the source of my confusion. But I think I'm sure that
> the Elegoo Super Starter Kit's Arduino UNO R3 is *not* ARM. They say
> it's 100% compatible with original Arduino so I assume it's got the
> same processor as the original.
> 
> > A raspberry Pi, running linux, would be a more familiar environment
> > by the sound of it. No problem running python there, but would
> > there be python I/O libraries?  

The 'Pi' comes from Python, which is its intended primary user
language. Peripherals intended for the Pi will come with Python
drivers, or at least Python interfaces.

> 
> That's ok. I am getting good enough in Python (and have made my own 
> libraries at times) that if it's not there, I might be able to create 
> one. Thing is, Raspberry Pi seems more like 

Re: Arduino and Python or gcc compiler?

2018-07-22 Thread Cindy-Sue Causey
On 7/21/18, cyaiplexys  wrote:
> On 07/21/2018 07:36 PM, deloptes wrote:
>> Hi, how old are you?
>> The way you wrote is supposing you are New Gen kid.
>
> Why thank you! :) Actually, physically I'm over half a century old. I
> just try to keep a young mind. I'm a New Gen kid to all this new tech
> stuff though.


The word "tinker" was the tell I picked up on there. As it turns out,
that was right on the money. :D

Cindy :)
-- 
Cindy-Sue Causey
Talking Rock, Pickens County, Georgia, USA

* runs with duct tape *



Re: Arduino and Python or gcc compiler?

2018-07-22 Thread cyaiplexys

On 07/22/2018 11:13 AM, Erik Christiansen wrote:

On 22.07.18 10:29, cyaiplexys wrote:

I think my mindset also came from my days of trying to program the WowWee
RoboSapien RS Media (ARM/Linux with Java). That was like a fully
programmable computer and robot all in one.


Then the full arduino environment will be more comfortable than raw C on
bare iron. While I program AVRs, including the ATmega328P used on most
arduino boards, in C and assembler, I understand that the arduino
environment provides a high level programming interface which allows
e.g. artists to write "sketches" to perform real-time tasks.


After watching some YouTube tutorials, I am starting to see that. The 
IDE isn't "real" C in that you're not directly compiling using gcc from 
the command line. It does everything for you behind the scenes. Not used 
to that since my old Windows days.



There is quite a bit of peripheral hardware on an ATmega328P, from
serial USART, through timer/counters useful for e.g. PWM motor control,
through multi-channel 10 bit Analogue to digital converter. The chip
datasheet is 440 pages in length, and learning to initialise and drive
the on-chip paraphernalia is a non-trivial task. The arduino environment
provides a library of drivers AIUI, to allow programming at the
application level, rather than writing your own drivers¹. It won't
necessarily give you the last microsecond of real-time performance, but
it should be a low-pain introduction. (Must be some reason for its
popularity, I figure.)


I got the starter kit with the Arduino UNO R3. Not knowing what that 
means yet (I need to read into that) I am assuming that ATmega328P is 
the Arduino MEGA and not the Arduino UNO R3? Or is it the CPU in all 
Arduinos? I'll have to look into that. I did find out a bit after my 
first post in this thread that Arduino isn't and ARM processor.



I don't mind using C, but am pretty bad at it. Maybe this is the time to
finally get better at it.


Learning two things at once is for self-driven stoics only, at least if
they're both non-trivial. Beginning with a friendly development
environment and application framework, complete with examples which
could be downloaded and used for tutorial purposes, avoids the pain of a
lot of stuff failing not because of coding errors, but because not yet
grokking the 440 pages of hardware spec left one bit in that other mode
enabling register unset, so it'll never work until you find the clue in
the doco.

There must be an arduino ML or forum, which would be a sanity saver.
Once master of that, then there's the AVRfreaks forum when the more
serious C journey begins.


I'll have to look into these forums and find one to join. I find forums 
and lists, etc. to be indispensable when learning new stuff. And also 
even if I am good with using something (like I am with Debian), still 
having some community based help had been very useful.



OK, there are one or two arduinos with ARM chips, but I don't count that
as original arduino.


Maybe that was the source of my confusion. But I think I'm sure that the 
Elegoo Super Starter Kit's Arduino UNO R3 is *not* ARM. They say it's 
100% compatible with original Arduino so I assume it's got the same 
processor as the original.



A raspberry Pi, running linux, would be a more familiar environment by
the sound of it. No problem running python there, but would there be
python I/O libraries?


That's ok. I am getting good enough in Python (and have made my own 
libraries at times) that if it's not there, I might be able to create 
one. Thing is, Raspberry Pi seems more like a computer, rather than a 
way to experiment controlling things (safely) like electronic circuits 
on breadboards for the fun of it.



¹ OK, drivers for e.g. 2x20 character LCDs can be found on the net, but
where there's an arduino LCD "shield" (plug-in daughterboard), there'll
be an arduino driver ready to use.

Erik


The kit comes with a LCD display, actually, and tutorials and examples 
on using it. That I know I'll find interesting too. Ever since I saw a 
video about LCD displays on a "The 8-bit guy" YouTube video, I been 
wanting to toy around with those things.


I am thinking this is going to be quite an interesting and fun hobby.



Re: Arduino and Python or gcc compiler?

2018-07-22 Thread Erik Christiansen
On 22.07.18 10:29, cyaiplexys wrote:
> I think my mindset also came from my days of trying to program the WowWee
> RoboSapien RS Media (ARM/Linux with Java). That was like a fully
> programmable computer and robot all in one.

Then the full arduino environment will be more comfortable than raw C on
bare iron. While I program AVRs, including the ATmega328P used on most
arduino boards, in C and assembler, I understand that the arduino
environment provides a high level programming interface which allows
e.g. artists to write "sketches" to perform real-time tasks.

There is quite a bit of peripheral hardware on an ATmega328P, from
serial USART, through timer/counters useful for e.g. PWM motor control,
through multi-channel 10 bit Analogue to digital converter. The chip
datasheet is 440 pages in length, and learning to initialise and drive
the on-chip paraphernalia is a non-trivial task. The arduino environment
provides a library of drivers AIUI, to allow programming at the
application level, rather than writing your own drivers¹. It won't
necessarily give you the last microsecond of real-time performance, but
it should be a low-pain introduction. (Must be some reason for its
popularity, I figure.)

> I don't mind using C, but am pretty bad at it. Maybe this is the time to
> finally get better at it.

Learning two things at once is for self-driven stoics only, at least if
they're both non-trivial. Beginning with a friendly development
environment and application framework, complete with examples which
could be downloaded and used for tutorial purposes, avoids the pain of a
lot of stuff failing not because of coding errors, but because not yet
grokking the 440 pages of hardware spec left one bit in that other mode
enabling register unset, so it'll never work until you find the clue in
the doco.

There must be an arduino ML or forum, which would be a sanity saver.
Once master of that, then there's the AVRfreaks forum when the more
serious C journey begins.

OK, there are one or two arduinos with ARM chips, but I don't count that
as original arduino.

A raspberry Pi, running linux, would be a more familiar environment by
the sound of it. No problem running python there, but would there be
python I/O libraries?

¹ OK, drivers for e.g. 2x20 character LCDs can be found on the net, but
where there's an arduino LCD "shield" (plug-in daughterboard), there'll
be an arduino driver ready to use.

Erik



Re: Arduino and Python or gcc compiler?

2018-07-22 Thread cyaiplexys

On 07/22/2018 06:20 AM, deloptes wrote:

cyaiplexys wrote:


Well, since I use Debian I assumed this would be a place to ask what to
get from the Debian repo that would help in achieving my goal. But you
do make a good point. I'll have to find some Arduino forums to ask some
questions in because I'm quite sure I'll have a lot of them.


Sure Arduino forums will be useful when you have specific Arduino questions.
Related to debian you have this page
https://wiki.debian.org/Arduino
It looks like it gives you the connection to the arduino board /dev/ttyACM0.

Next CPUs - IMO you definitely need to know for which CPU you develop code
https://www.arduino.cc/en/Products/Compare
but it could be that the IDE hides this.

Salt it with some background knowledge
https://www.arduino.cc/en/Tutorial/Foundations

It is not a one day exercise, but it may be fun.

>

I did AVR for a hobby. I bought few types of AVR chips a dev board, that I
had to soldier myself and a programmer (total cost ~ €25,-). It took me
some time to understand how the programmer is to be used with the board and
how it is intended to work on linux. I guess it was two weekends that I
spent reading and trying. Finally Enlightment was there and voila, I can
write, compile, flash and run the MCs. Altogether it spanned over 8 months
because of job and family. I think the total time spent was about 1 month
though.
So it depends on your level and skill. It might take months or hours, but at
the end you will be an expert.


When I get into these things, it might take me a few months to maybe 
even years to learn something new fully. And some things only take a 
weekend. Depends on what skills one needs to get going with it. I have 
35+ years programming experience in many different languages, and 
tinkered in electronics even as young as age 7. But the thing is, while 
I learned the basics (and when Google came around, Googled for stuff I 
didn't know that I needed to apply to a project), and even took a couple 
online courses in programming, I find it's a matter of use it or lose 
it. If I don't use it regularly (like I do with PHP, HTML, CSS, Perl, 
and Python in my job), then I tend to forget almost all I learned and 
kinda end up Googling for help with everything or looking up my code 
snippets and notes.


But at the same time, I enjoy tinkering with stuff, even if I might 
forget a year or two later. For my own hobbies, I just get curious about 
some of the "new" (I know this stuff has been around awhile) technology 
out there and like to see how it all works.


It might be also worth learning some C. 


I had done some C programming now and then (K & R C, ANSI C, Mix Power 
C, Borland C++, gcc, Visual C) and now anytime I do anything in C, I use 
gcc (and also valgrind, autotools, and I forgot what else I use but I 
use Kate for my editor for nearly everything and compile at command 
line). I still struggle with C because I don't use it much. However, I 
use a lot of stuff that has a similar structure to C such as perl and 
PHP. Funny thing is, I also learned Java but almost never use it!



I am not sure how python compiles low level code, but I guess it

> comes with overhead.

Python is a scripting language so natively it doesn't get compiled, 
really. To compile Python code to binary .so for like Python libraries 
(which is NOT required but there are some uses for doing so), I use a 
program called 'cython' (in the debian repos) that converts Python code 
to C code, then uses gcc to compile the resulting C code. Does a decent 
job of it for what I was doing.


> Given the amount of memory available, it might be wise to keep low
> footprint. Also you do not need to know a lot of details. Focus is on
> bitwise operations that are used when working with bits.

I actually haven't done much of that in *years* - since my OS9-Level II 
days. Got to brush up on that now.


> But there are very good examples, so if you have an understanding of
> the concept of C language, it shouldn't be a big challenge.
>
> good luck

Good to know. And thank you for all the really good information. I'm 
saving it for my "list to learn".




Re: Arduino and Python or gcc compiler?

2018-07-22 Thread cyaiplexys

On 07/22/2018 03:26 AM, Joe wrote:

Joe, please forgive me that I forgot to click "Reply to list". I have NO 
valid excuse why I keep doing stupid things like that. :(



On Sat, 21 Jul 2018 18:15:12 -0400
cyaiplexys  wrote:


I am getting the Elegoo Super Starter Kit (Arduino Uno R3) to tinker
with (it's on order as of when I'm writing this post).

I looked in the Debian repos for stuff on Arduino and didn't find
much (at least not of interest to me).

I did download the IDE from Elegoo and their tutorials and libraries.
But it's all in C/C++. While I do know C and C++ (to some extent),
I'm very bad at it (I admit to not using it very much, maybe once
every other blue moon and lately we haven't had any blue moons that
warranted using C).

I recently been doing stuff in Python (especially for work, which is
not Arduino related in any way). I am really getting to like Python.
I have created my own Python Libraries for other things (again
unrelated) and even compiled them to .so (binary) using the 'cython'
compiler.

While I could create C source of a Python script using cython, I
don't know how to compile the resulting C source and upload it to the
Arduino board. I would like to use gcc.

Is there a cross-platform compiler for Arduino and gcc that anyone
has had experience with that works or they can recommend?

Or some way to program in Python?




Sure if I was going there I wouldn't be after starting from here...

I've seen your later post, and you may indeed be overestimating what
the Arduino can do, it's basically a very well developed ecosystem for
a microcontroller, with lots of real-world interfaces available. Just
for tinkering with electronics, it's fine.

If you're after a more powerful (i.e. PC-like) tinkering gadget, you
might be better looking at the Raspberry Pi (Pi for Python) and the
subsequent similar devices. More expensive than the Arduino, but still
pretty cheap. The Pi runs more than one OS, but the Raspbian version of
Debian is probably most widely-used. The Pi also has a great many
interface devices available, and Python is the expected scripting
language.


I will probably end up with one of those sooner or later. A friend as a 
Pi (I thought Pi meant 3.14...)


I keep hearing about Arduino and Raspberry Pi and always wondered what 
they were all about. So I chose to experiment with Arduino first. I know 
*nothing* about either at the moment. Still in the learning, Googling, 
asking stupid questions, etc. phase. :)


I think my mindset also came from my days of trying to program the 
WowWee RoboSapien RS Media (ARM/Linux with Java). That was like a fully 
programmable computer and robot all in one.


I don't mind using C, but am pretty bad at it. Maybe this is the time to 
finally get better at it.




Re: Arduino and Python or gcc compiler?

2018-07-22 Thread deloptes
cyaiplexys wrote:

> Well, since I use Debian I assumed this would be a place to ask what to
> get from the Debian repo that would help in achieving my goal. But you
> do make a good point. I'll have to find some Arduino forums to ask some
> questions in because I'm quite sure I'll have a lot of them.

Sure Arduino forums will be useful when you have specific Arduino questions.
Related to debian you have this page
https://wiki.debian.org/Arduino
It looks like it gives you the connection to the arduino board /dev/ttyACM0.

Next CPUs - IMO you definitely need to know for which CPU you develop code
https://www.arduino.cc/en/Products/Compare
but it could be that the IDE hides this.

Salt it with some background knowledge
https://www.arduino.cc/en/Tutorial/Foundations

It is not a one day exercise, but it may be fun.

I did AVR for a hobby. I bought few types of AVR chips a dev board, that I
had to soldier myself and a programmer (total cost ~ €25,-). It took me
some time to understand how the programmer is to be used with the board and
how it is intended to work on linux. I guess it was two weekends that I
spent reading and trying. Finally Enlightment was there and voila, I can
write, compile, flash and run the MCs. Altogether it spanned over 8 months
because of job and family. I think the total time spent was about 1 month
though.
So it depends on your level and skill. It might take months or hours, but at
the end you will be an expert.
It might be also worth learning some C. I am not sure how python compiles
low level code, but I guess it comes with overhead. Given the amount of
memory available, it might be wise to keep low footprint. Also you do not
need to know a lot of details. Focus is on bitwise operations that are used
when working with bits. But there are very good examples, so if you have an
understanding of the concept of C language, it shouldn't be a big
challenge.

good luck








Re: Arduino and Python or gcc compiler?

2018-07-22 Thread Joe
On Sat, 21 Jul 2018 18:15:12 -0400
cyaiplexys  wrote:

> I am getting the Elegoo Super Starter Kit (Arduino Uno R3) to tinker 
> with (it's on order as of when I'm writing this post).
> 
> I looked in the Debian repos for stuff on Arduino and didn't find
> much (at least not of interest to me).
> 
> I did download the IDE from Elegoo and their tutorials and libraries. 
> But it's all in C/C++. While I do know C and C++ (to some extent),
> I'm very bad at it (I admit to not using it very much, maybe once
> every other blue moon and lately we haven't had any blue moons that
> warranted using C).
> 
> I recently been doing stuff in Python (especially for work, which is
> not Arduino related in any way). I am really getting to like Python.
> I have created my own Python Libraries for other things (again
> unrelated) and even compiled them to .so (binary) using the 'cython'
> compiler.
> 
> While I could create C source of a Python script using cython, I
> don't know how to compile the resulting C source and upload it to the
> Arduino board. I would like to use gcc.
> 
> Is there a cross-platform compiler for Arduino and gcc that anyone
> has had experience with that works or they can recommend?
> 
> Or some way to program in Python?
> 


Sure if I was going there I wouldn't be after starting from here...

I've seen your later post, and you may indeed be overestimating what
the Arduino can do, it's basically a very well developed ecosystem for
a microcontroller, with lots of real-world interfaces available. Just
for tinkering with electronics, it's fine.

If you're after a more powerful (i.e. PC-like) tinkering gadget, you
might be better looking at the Raspberry Pi (Pi for Python) and the
subsequent similar devices. More expensive than the Arduino, but still
pretty cheap. The Pi runs more than one OS, but the Raspbian version of
Debian is probably most widely-used. The Pi also has a great many
interface devices available, and Python is the expected scripting
language.

-- 
Joe



Re: Arduino and Python or gcc compiler?

2018-07-21 Thread cyaiplexys

On 07/21/2018 09:01 PM, David Christensen wrote:

On 07/21/18 15:15, cyaiplexys wrote:
I am getting the Elegoo Super Starter Kit (Arduino Uno R3) to tinker 
with (it's on order as of when I'm writing this post).


I looked in the Debian repos for stuff on Arduino and didn't find much 
(at least not of interest to me).


I did download the IDE from Elegoo and their tutorials and libraries. 
But it's all in C/C++. While I do know C and C++ (to some extent), I'm 
very bad at it (I admit to not using it very much, maybe once every 
other blue moon and lately we haven't had any blue moons that 
warranted using C).


I recently been doing stuff in Python (especially for work, which is 
not Arduino related in any way). I am really getting to like Python. I 
have created my own Python Libraries for other things (again 
unrelated) and even compiled them to .so (binary) using the 'cython' 
compiler.


While I could create C source of a Python script using cython, I don't 
know how to compile the resulting C source and upload it to the 
Arduino board. I would like to use gcc.


Is there a cross-platform compiler for Arduino and gcc that anyone has 
had experience with that works or they can recommend?


Or some way to program in Python?

I'll use C/C++ until I can figure the Python stuff out. But I really 
would like to be able to use Python at some point.


It sounds like your intended use is as a hobbyist (?).


Yes. I heard about it and got curious. I liked tinkering with 
electronics back in the day and kinda wondered what this is about. It's 
just basically for my own fun. I don't expect to make something the 
world can't live without or anything like that.



STFW for Arduino Uno R3: >
https://store.arduino.cc/arduino-uno-rev3

Microcontroller ATmega328P

Flash Memory 32 KB (ATmega328P) of which 0.5 KB used by bootloader

SRAM 2 KB (ATmega328P)

EEPROM 1 KB (ATmega328P)

Clock Speed 16 MHz



STFW for the CPU:

http://ww1.microchip.com/downloads/en/DeviceDoc/Atmel-42735-8-bit-AVR-Microcontroller-ATmega328-328P_Datasheet.pdf 



The Atmel® picoPower® ATmega328/P is a low-power CMOS 8-bit
microcontroller based on the AVR® enhanced RISC architecture.

STFW for embedded Python:

https://www.usenix.org/system/files/conference/atc12/atc12-final30.pdf

This  paper  presents  one  mechanism  for  doing  so:
an  efficient  embedded  Python  run-time  system  named
Owl. The Owl system is a complete Python development
toolchain and run-time system for microcontrollers that
do not have enough resources to run a real operating sys-
tem, but are still capable of running sophisticated soft-
ware systems.  These microcontrollers typically operate
at 50–100 MHz, have 64–128 KB of SRAM, and have
up  to  512  KB  of  on-chip  flash.


Note that the frequency, RAM, and ROM requirements for embedded Python 
exceed what is provided by the Arduino Uno.  So, that explains why I 
also find no solutions for Python on the Arduino Uno R3.



If you want an embedded kit that can do Python (2 or 3?), your best bet 
is to get a kit that supports Python OOTB:


https://wiki.python.org/moin/EmbeddedPython


Getting a kit that supports Linux OOTB would give you even more options:

https://www.linux.com/news/top-10-open-source-linux-boards-under-200


Lots of info there. Well, glad it's possible. Looks like it'll take some 
doing though. Obviously there won't be anything in Debian's Repo for it 
like I hoped.


Thank you for giving me some ideas on what to look for. That'll keep me 
busy for awhile!




Re: Arduino and Python or gcc compiler?

2018-07-21 Thread cyaiplexys

On 07/21/2018 07:36 PM, deloptes wrote:

Hi, how old are you?
The way you wrote is supposing you are New Gen kid.


Why thank you! :) Actually, physically I'm over half a century old. I 
just try to keep a young mind. I'm a New Gen kid to all this new tech 
stuff though.



Anyway few answers inline

cyaiplexys wrote:


I am getting the Elegoo Super Starter Kit (Arduino Uno R3) to tinker
with (it's on order as of when I'm writing this post).

I looked in the Debian repos for stuff on Arduino and didn't find much
(at least not of interest to me).



What did you expect to find exactly?


*gulp* Python libraries? Cython compiler for the Arduino CPU?

When I wrote this I didn't know exactly what I'm getting into. I heard 
of Arduino and had the impression it's an ARM or ARM-type processor on a 
board and you can interact with your electronic circuits you build with 
it and a computer. After writing the post I went and looked up some 
YouTube tutorials for beginners. I probably should have done that first 
before inserting foot in mouth. :-/



I did download the IDE from Elegoo and their tutorials and libraries.
But it's all in C/C++. While I do know C and C++ (to some extent), I'm
very bad at it (I admit to not using it very much, maybe once every
other blue moon and lately we haven't had any blue moons that warranted
using C).



Well for low level programming mostly C is used actually.
New things to learn -> write a list with dependencies and priorities.

:

More to learn -> add to the list
I did not have a look at Arduino but played with AVR chip programming, so
sure there is for Arduino as well.


I'll remain hopeful. I'm going to have a long list of things I'll want 
to learn.



Or some way to program in Python?

I'll use C/C++ until I can figure the Python stuff out. But I really
would like to be able to use Python at some point.


Finally you are on the wrong user list. This is general debian user list and
we discuss only debian related questions.
IMO Arduino and related should be somewhere else.


Well, since I use Debian I assumed this would be a place to ask what to 
get from the Debian repo that would help in achieving my goal. But you 
do make a good point. I'll have to find some Arduino forums to ask some 
questions in because I'm quite sure I'll have a lot of them.




Re: Arduino and Python or gcc compiler?

2018-07-21 Thread David Christensen

On 07/21/18 15:15, cyaiplexys wrote:
I am getting the Elegoo Super Starter Kit (Arduino Uno R3) to tinker 
with (it's on order as of when I'm writing this post).


I looked in the Debian repos for stuff on Arduino and didn't find much 
(at least not of interest to me).


I did download the IDE from Elegoo and their tutorials and libraries. 
But it's all in C/C++. While I do know C and C++ (to some extent), I'm 
very bad at it (I admit to not using it very much, maybe once every 
other blue moon and lately we haven't had any blue moons that warranted 
using C).


I recently been doing stuff in Python (especially for work, which is not 
Arduino related in any way). I am really getting to like Python. I have 
created my own Python Libraries for other things (again unrelated) and 
even compiled them to .so (binary) using the 'cython' compiler.


While I could create C source of a Python script using cython, I don't 
know how to compile the resulting C source and upload it to the Arduino 
board. I would like to use gcc.


Is there a cross-platform compiler for Arduino and gcc that anyone has 
had experience with that works or they can recommend?


Or some way to program in Python?

I'll use C/C++ until I can figure the Python stuff out. But I really 
would like to be able to use Python at some point.


It sounds like your intended use is as a hobbyist (?).


STFW for Arduino Uno R3:

https://store.arduino.cc/arduino-uno-rev3

Microcontroller ATmega328P

Flash Memory32 KB (ATmega328P) of which 0.5 KB used by bootloader

SRAM2 KB (ATmega328P)

EEPROM  1 KB (ATmega328P)

Clock Speed 16 MHz


STFW for the CPU:

http://ww1.microchip.com/downloads/en/DeviceDoc/Atmel-42735-8-bit-AVR-Microcontroller-ATmega328-328P_Datasheet.pdf

The Atmel® picoPower® ATmega328/P is a low-power CMOS 8-bit
microcontroller based on the AVR® enhanced RISC architecture.


STFW for embedded Python:

https://www.usenix.org/system/files/conference/atc12/atc12-final30.pdf

This  paper  presents  one  mechanism  for  doing  so:
an  efficient  embedded  Python  run-time  system  named
Owl. The Owl system is a complete Python development
toolchain and run-time system for microcontrollers that
do not have enough resources to run a real operating sys-
tem, but are still capable of running sophisticated soft-
ware systems.  These microcontrollers typically operate
at 50–100 MHz, have 64–128 KB of SRAM, and have
up  to  512  KB  of  on-chip  flash.


Note that the frequency, RAM, and ROM requirements for embedded Python 
exceed what is provided by the Arduino Uno.  So, that explains why I 
also find no solutions for Python on the Arduino Uno R3.



If you want an embedded kit that can do Python (2 or 3?), your best bet 
is to get a kit that supports Python OOTB:


https://wiki.python.org/moin/EmbeddedPython


Getting a kit that supports Linux OOTB would give you even more options:

https://www.linux.com/news/top-10-open-source-linux-boards-under-200


David



Re: Arduino and Python or gcc compiler?

2018-07-21 Thread deloptes
Hi, how old are you?
The way you wrote is supposing you are New Gen kid.
Anyway few answers inline

cyaiplexys wrote:

> I am getting the Elegoo Super Starter Kit (Arduino Uno R3) to tinker
> with (it's on order as of when I'm writing this post).
> 
> I looked in the Debian repos for stuff on Arduino and didn't find much
> (at least not of interest to me).
> 

What did you expect to find exactly?

> I did download the IDE from Elegoo and their tutorials and libraries.
> But it's all in C/C++. While I do know C and C++ (to some extent), I'm
> very bad at it (I admit to not using it very much, maybe once every
> other blue moon and lately we haven't had any blue moons that warranted
> using C).
> 

Well for low level programming mostly C is used actually.
New things to learn -> write a list with dependencies and priorities.

> I recently been doing stuff in Python (especially for work, which is not
> Arduino related in any way). I am really getting to like Python. I have
> created my own Python Libraries for other things (again unrelated) and
> even compiled them to .so (binary) using the 'cython' compiler.
> 

More to learn -> add to the list

> While I could create C source of a Python script using cython, I don't
> know how to compile the resulting C source and upload it to the Arduino
> board. I would like to use gcc.
> 
More to learn -> add to the list

> Is there a cross-platform compiler for Arduino and gcc that anyone has
> had experience with that works or they can recommend?
> 
More to learn -> add to the list
I did not have a look at Arduino but played with AVR chip programming, so
sure there is for Arduino as well.

> Or some way to program in Python?
> 
> I'll use C/C++ until I can figure the Python stuff out. But I really
> would like to be able to use Python at some point.

Finally you are on the wrong user list. This is general debian user list and
we discuss only debian related questions.
IMO Arduino and related should be somewhere else.

regards



Arduino and Python or gcc compiler?

2018-07-21 Thread cyaiplexys
I am getting the Elegoo Super Starter Kit (Arduino Uno R3) to tinker 
with (it's on order as of when I'm writing this post).


I looked in the Debian repos for stuff on Arduino and didn't find much 
(at least not of interest to me).


I did download the IDE from Elegoo and their tutorials and libraries. 
But it's all in C/C++. While I do know C and C++ (to some extent), I'm 
very bad at it (I admit to not using it very much, maybe once every 
other blue moon and lately we haven't had any blue moons that warranted 
using C).


I recently been doing stuff in Python (especially for work, which is not 
Arduino related in any way). I am really getting to like Python. I have 
created my own Python Libraries for other things (again unrelated) and 
even compiled them to .so (binary) using the 'cython' compiler.


While I could create C source of a Python script using cython, I don't 
know how to compile the resulting C source and upload it to the Arduino 
board. I would like to use gcc.


Is there a cross-platform compiler for Arduino and gcc that anyone has 
had experience with that works or they can recommend?


Or some way to program in Python?

I'll use C/C++ until I can figure the Python stuff out. But I really 
would like to be able to use Python at some point.





Re: GCC 7

2018-06-15 Thread tomas
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Thu, Jun 14, 2018 at 08:35:29AM -0700, Don Armstrong wrote:
> On Thu, 14 Jun 2018, to...@tuxteam.de wrote:
> > Took out mk-sbuild for a whirl. What I didn't like at all: when you
> > invoke a command and it goes out and starts installing packages for
> > you (and doing other assorted sysadmin tasks).
> 
> You can do everything that mk-sbuild does for you manually, but when
> you're setting up many different sbuild chroots, it makes things much
> easier. [And it makes my response much simpler.]

Yes, I understand *why* it is doing it. It just doesn't rhyme very
well with the way I do things.

Pulling in dependencies at install is something I expect (and can
easily check in advance, thanks to the well thought-out Debian
packaging system). Calling "apt-get install" (to my *main* system,
not to the chroot!) from a seemingly unrelated command is something
I... dislike (there were other things I disliked, too).

So this was just a heads-up for others like me. I had a look into
the mk-sbuild script and decided to purge ubuntu-dev-tools.

Cheers
- -- tomás
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAlsjVrkACgkQBcgs9XrR2kb7JgCfdcywY9A1ZaK4rwP3gw11OBc0
qcYAniTwFq3KnAFdSRIijkZNSY+Dpk82
=bq/r
-END PGP SIGNATURE-



Re: GCC 7

2018-06-14 Thread Don Armstrong
On Thu, 14 Jun 2018, to...@tuxteam.de wrote:
> Took out mk-sbuild for a whirl. What I didn't like at all: when you
> invoke a command and it goes out and starts installing packages for
> you (and doing other assorted sysadmin tasks).

You can do everything that mk-sbuild does for you manually, but when
you're setting up many different sbuild chroots, it makes things much
easier. [And it makes my response much simpler.]

The things that mk-sbuild installs are just sbuild, schroot, and
debootstrap, and possibly lvm2 if you're using lvm chroots; I actually
didn't notice that it even did that because I have all of them
installed. [And really, mk-sbuild *is* a sysadmin tool designed to
automate sysadmin tasks.]


-- 
Don Armstrong  https://www.donarmstrong.com

"I always tend to assume there's an infinite amount of money out
there." "There might as well be, [...] but most of it gets spent on
pornography, sugar water, and bombs. There is only so much that can be
scraped together for particle accelerators."
 -- Neal Stephenson _Anathem_ p262



Re: GCC 7

2018-06-14 Thread tomas
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Thu, Jun 14, 2018 at 01:06:27PM +0200, Irek Szcześniak wrote:
> I tried schroot in a different way, as described here:
> 
> https://wiki.debian.org/Schroot
> 
> As part of the process, you install a complete, fresh Buster with:
> 
> debootstrap buster /srv/chroot/buster
> 
> So this solution is like a container.

Yep, that rhymes better with how I tick :-)

Thanks, cheers
- -- tomás
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAlsiVskACgkQBcgs9XrR2kbRSwCfe3TRYv5PyHweQ/vDeAVjkWrW
UNUAnAukE4rx6kGJNnl/dI7/klbl9Pyk
=h0MJ
-END PGP SIGNATURE-



Re: GCC 7

2018-06-14 Thread Irek Szcześniak

I tried schroot in a different way, as described here:

https://wiki.debian.org/Schroot

As part of the process, you install a complete, fresh Buster with:

debootstrap buster /srv/chroot/buster

So this solution is like a container.


Best,
Irek

On 14.06.2018 12:47, to...@tuxteam.de wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Wed, Jun 13, 2018 at 08:37:57AM -0700, Don Armstrong wrote:

On Wed, 13 Jun 2018, Irek Szcześniak wrote:

Thanks for pointing out pbuilder, I think I'll give it a try.  I also might
want to try virtual containers, but it seems like an overkill.


You might also try out schroot.

Something like:

apt-get install schroot ubuntu-dev-tools;
mk-sbuild unstable;
schroot unstable;

will get you in an unstable chroot which you can use to build packages.
[schroot+sbuild is what Debian developers often use instead of pbuilder,
but either approach works.]


Took out mk-sbuild for a whirl. What I didn't like at all: when you
invoke a command and it goes out and starts installing packages for
you (and doing other assorted sysadmin tasks).

Pretty heavy-handed, if you ask me. YMMV.

Cheers
- -- tomás
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAlsiR8sACgkQBcgs9XrR2kYirgCfVtkknb0sQHxAMf26LFWq20PA
2GsAnRB7zxFJQtbUvm/zure+47es9fhx
=jWOu
-END PGP SIGNATURE-





Re: GCC 7

2018-06-14 Thread tomas
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Wed, Jun 13, 2018 at 08:37:57AM -0700, Don Armstrong wrote:
> On Wed, 13 Jun 2018, Irek Szcześniak wrote:
> > Thanks for pointing out pbuilder, I think I'll give it a try.  I also might
> > want to try virtual containers, but it seems like an overkill.
> 
> You might also try out schroot.
> 
> Something like:
> 
> apt-get install schroot ubuntu-dev-tools;
> mk-sbuild unstable;
> schroot unstable;
> 
> will get you in an unstable chroot which you can use to build packages.
> [schroot+sbuild is what Debian developers often use instead of pbuilder,
> but either approach works.]

Took out mk-sbuild for a whirl. What I didn't like at all: when you
invoke a command and it goes out and starts installing packages for
you (and doing other assorted sysadmin tasks). 

Pretty heavy-handed, if you ask me. YMMV.

Cheers
- -- tomás
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAlsiR8sACgkQBcgs9XrR2kYirgCfVtkknb0sQHxAMf26LFWq20PA
2GsAnRB7zxFJQtbUvm/zure+47es9fhx
=jWOu
-END PGP SIGNATURE-



Re: GCC 7

2018-06-14 Thread tomas
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Thu, Jun 14, 2018 at 10:44:59AM +0200, Irek Szcześniak wrote:
> Tomás, thank you again for your email.
> 
> I didn't finally try pbuilder, because compiling GCC solved my
> problem. If something goes wrong, I'll use schroot.  Thanks for
> pointing out pbuilder, it may come handy one day!

Glad you solved it :-)

Collaterally, I learnt about schroot, so thanks for this one as
well.

Cheers
- -- t
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAlsiMsgACgkQBcgs9XrR2kYQhwCfX8Ff3aD+aQpFfMPv0BFyi3cN
9yYAni+0aT9atlDxQ2R/5cTZxuJ3WpK2
=tdPR
-END PGP SIGNATURE-



Re: GCC 7

2018-06-14 Thread Irek Szcześniak

Tomás, thank you again for your email.

I didn't finally try pbuilder, because compiling GCC solved my problem. 
If something goes wrong, I'll use schroot.  Thanks for pointing out 
pbuilder, it may come handy one day!



Best,
Irek

On 13.06.2018 12:20, to...@tuxteam.de wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Wed, Jun 13, 2018 at 12:06:21PM +0200, Irek Szcześniak wrote:

Thanks, Tomás, for your email.

I should have written before that I don't want the GCC 7 to be a
system-wide compiler, along with libraries and some other
dependencies. I need GCC 7 to compile my own code (C++17) that I
run.  I don't need to distribute the binaries.


I see. Then pbuilder might well be an option (you might end up
having to run your application in the chroot, but hey).


Yes, GCC 7 is not in the backports, so it's not an option.  There
might be some Debian packages with GCC 7, but I worry about making a
FrankenDebian, and the ensuing dependency and linking problems.


Yeah -- I already mixed a newer version of GCC back then by enabling
testing into a stable and survived it (actually for a year's period,
on my main work machine) but ended up with nearly 100% testing after
a while. FrankenDebian isn't as bad as its reputation, but you want
to watch your step. Aptitude tends to become unusable after a while
(its dependency resolver seems to intelligent to master that much
chaos), but apt-get/apt can cope.

So if you know what you're doing and you are a bit fearless,
FrankenDebian isn't *that* bad. Not recommended for beginners and
those who just want peace with their computers, for sure.


Thanks for pointing out pbuilder, I think I'll give it a try.  I
also might want to try virtual containers, but it seems like an
overkill.

I might later drop an email to the debian-gcc mailing list.


Yes, perhaps someone gets nudged into backporting (actually you
might try yourself: just download the gcc-7 source package, its
build dependencies (apt-get build-dep) and build away, but gcc
is of course daunting, so you most probably end up shaving
a king-size yak :-)

Cheers
- -- tomás
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAlsg7/0ACgkQBcgs9XrR2kZCGgCfajN8v/e4CdGJDWGLuLYGqmxy
Kk0Anim4iK08WHgGK5wn8thy2mpgMH2F
=0/m3
-END PGP SIGNATURE-





Re: GCC 7

2018-06-14 Thread Irek Szcześniak

Thank you, Don, for your advice!

I tried schroot, and it's awesome!  I followed the steps on:

https://wiki.debian.org/Schroot

I was able to build my code just as on Buster.  The difference between 
schroot and chroot is that with schroot you have assess to the files 
outside the root directory of chroot (like /srv/chroot/buster), and I'm 
thinking specifically about the home directory.


Thanks!


Best,
Irek

On 13.06.2018 17:37, Don Armstrong wrote:

On Wed, 13 Jun 2018, Irek Szcześniak wrote:

Thanks for pointing out pbuilder, I think I'll give it a try.  I also might
want to try virtual containers, but it seems like an overkill.


You might also try out schroot.

Something like:

apt-get install schroot ubuntu-dev-tools;
mk-sbuild unstable;
schroot unstable;

will get you in an unstable chroot which you can use to build packages.
[schroot+sbuild is what Debian developers often use instead of pbuilder,
but either approach works.]





Re: GCC 7

2018-06-14 Thread Irek Szcześniak

Georgi, thank you for you email.

I gave it a try.  On Stretch, GCC 8.1 compiled and installed cleanly.  I 
put the path to the gcc binary (/usr/local/gcc-8.1.0/bin) in my PATH, 
and I compiled and ran my code without any other configuration.  I 
expected some linking problems, but the binary dynamically links to the 
system libraries, and things are OK.  Cool!  Thanks again!



Best,
Irek

On 13.06.2018 23:43, Georgi Naplatanov wrote:

On 06/13/2018 11:04 AM, Irek Szcześniak wrote:

Hi,

I need GCC 7 on my Debian Stretch.  Previously I upgraded my Stretch to
Testing (Buster), but I ran to some problems, and reinstalled the system
back to Stretch.

Could someone offer an advice on how to get a working GCC 7 on Debian
Stretch, without upgrading to Testing?


Another option could be to build GCC-7 yourself from source. Don't
forget to use appropriate prefix when you run "configure".

Kind regards
Georgi





Re: GCC 7

2018-06-13 Thread Georgi Naplatanov
On 06/13/2018 11:04 AM, Irek Szcześniak wrote:
> Hi,
> 
> I need GCC 7 on my Debian Stretch.  Previously I upgraded my Stretch to
> Testing (Buster), but I ran to some problems, and reinstalled the system
> back to Stretch.
> 
> Could someone offer an advice on how to get a working GCC 7 on Debian
> Stretch, without upgrading to Testing?

Another option could be to build GCC-7 yourself from source. Don't
forget to use appropriate prefix when you run "configure".

Kind regards
Georgi



Re: GCC 7

2018-06-13 Thread Don Armstrong
On Wed, 13 Jun 2018, Irek Szcześniak wrote:
> Thanks for pointing out pbuilder, I think I'll give it a try.  I also might
> want to try virtual containers, but it seems like an overkill.

You might also try out schroot.

Something like:

apt-get install schroot ubuntu-dev-tools;
mk-sbuild unstable;
schroot unstable;

will get you in an unstable chroot which you can use to build packages.
[schroot+sbuild is what Debian developers often use instead of pbuilder,
but either approach works.]

-- 
Don Armstrong  https://www.donarmstrong.com

The smallest quantity of bread that can be sliced and toasted has yet
to be experimentally determined. In the quantum limit we must
necessarily encounter fundamental toast particles which the author
will unflinchingly designate here as "croutons".
 -- Cser, Jim. Nanotechnology and the Physical Limits of Toastability.
AIR 1:3, June, 1995.



Re: GCC 7

2018-06-13 Thread tomas
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Wed, Jun 13, 2018 at 12:06:21PM +0200, Irek Szcześniak wrote:
> Thanks, Tomás, for your email.
> 
> I should have written before that I don't want the GCC 7 to be a
> system-wide compiler, along with libraries and some other
> dependencies. I need GCC 7 to compile my own code (C++17) that I
> run.  I don't need to distribute the binaries.

I see. Then pbuilder might well be an option (you might end up
having to run your application in the chroot, but hey).

> Yes, GCC 7 is not in the backports, so it's not an option.  There
> might be some Debian packages with GCC 7, but I worry about making a
> FrankenDebian, and the ensuing dependency and linking problems.

Yeah -- I already mixed a newer version of GCC back then by enabling
testing into a stable and survived it (actually for a year's period,
on my main work machine) but ended up with nearly 100% testing after
a while. FrankenDebian isn't as bad as its reputation, but you want
to watch your step. Aptitude tends to become unusable after a while
(its dependency resolver seems to intelligent to master that much
chaos), but apt-get/apt can cope.

So if you know what you're doing and you are a bit fearless,
FrankenDebian isn't *that* bad. Not recommended for beginners and
those who just want peace with their computers, for sure.

> Thanks for pointing out pbuilder, I think I'll give it a try.  I
> also might want to try virtual containers, but it seems like an
> overkill.
> 
> I might later drop an email to the debian-gcc mailing list.

Yes, perhaps someone gets nudged into backporting (actually you
might try yourself: just download the gcc-7 source package, its
build dependencies (apt-get build-dep) and build away, but gcc
is of course daunting, so you most probably end up shaving
a king-size yak :-)

Cheers
- -- tomás
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAlsg7/0ACgkQBcgs9XrR2kZCGgCfajN8v/e4CdGJDWGLuLYGqmxy
Kk0Anim4iK08WHgGK5wn8thy2mpgMH2F
=0/m3
-END PGP SIGNATURE-



Re: GCC 7

2018-06-13 Thread Irek Szcześniak

Thanks, Tomás, for your email.

I should have written before that I don't want the GCC 7 to be a 
system-wide compiler, along with libraries and some other dependencies. 
I need GCC 7 to compile my own code (C++17) that I run.  I don't need to 
distribute the binaries.


Yes, GCC 7 is not in the backports, so it's not an option.  There might 
be some Debian packages with GCC 7, but I worry about making a 
FrankenDebian, and the ensuing dependency and linking problems.


Thanks for pointing out pbuilder, I think I'll give it a try.  I also 
might want to try virtual containers, but it seems like an overkill.


I might later drop an email to the debian-gcc mailing list.


Best,
Irek

On 13.06.2018 11:21, to...@tuxteam.de wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Wed, Jun 13, 2018 at 10:04:25AM +0200, Irek Szcześniak wrote:

Hi,

I need GCC 7 on my Debian Stretch.  Previously I upgraded my Stretch
to Testing (Buster), but I ran to some problems, and reinstalled the
system back to Stretch.

Could someone offer an advice on how to get a working GCC 7 on
Debian Stretch, without upgrading to Testing?


Backports would be a place to go. There seem to be others in your
situation:

https://lists.debian.org/debian-gcc/2018/04/msg00137.html

(but I haven't seen an answer to this request in that mailing
list).

Perhaps pinging debian-gcc list is a good idea.

Alternatively, if you just want to build for testing, some
pbuilder (chroot) setup might help, but then your program
might want to link to newer core libraries...

Cheers
- -- tomás
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAlsg4hoACgkQBcgs9XrR2kZFiwCeLK2EU23uSBz2rpyW+rHLPfjz
Z8gAn1W7qif93Zdn1f49C4TW3Yex4NsZ
=qVRK
-END PGP SIGNATURE-





Re: GCC 7

2018-06-13 Thread tomas
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Wed, Jun 13, 2018 at 10:04:25AM +0200, Irek Szcześniak wrote:
> Hi,
> 
> I need GCC 7 on my Debian Stretch.  Previously I upgraded my Stretch
> to Testing (Buster), but I ran to some problems, and reinstalled the
> system back to Stretch.
> 
> Could someone offer an advice on how to get a working GCC 7 on
> Debian Stretch, without upgrading to Testing?

Backports would be a place to go. There seem to be others in your
situation:

https://lists.debian.org/debian-gcc/2018/04/msg00137.html

(but I haven't seen an answer to this request in that mailing
list).

Perhaps pinging debian-gcc list is a good idea.

Alternatively, if you just want to build for testing, some
pbuilder (chroot) setup might help, but then your program
might want to link to newer core libraries...

Cheers
- -- tomás
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAlsg4hoACgkQBcgs9XrR2kZFiwCeLK2EU23uSBz2rpyW+rHLPfjz
Z8gAn1W7qif93Zdn1f49C4TW3Yex4NsZ
=qVRK
-END PGP SIGNATURE-



GCC 7

2018-06-13 Thread Irek Szcześniak

Hi,

I need GCC 7 on my Debian Stretch.  Previously I upgraded my Stretch to 
Testing (Buster), but I ran to some problems, and reinstalled the system 
back to Stretch.


Could someone offer an advice on how to get a working GCC 7 on Debian 
Stretch, without upgrading to Testing?



Thanks & best,
Irek



Re: How to correctly select gcc / why dkms rebuild failed on xtables-addons

2018-03-20 Thread David Wright
On Tue 20 Mar 2018 at 23:18:29 (+0100), Neo wrote:
> Hey folks
> 
> I've had a setup with xtables-addons running (on jessie with
> standard repos), especially the geoip module in this case. The
> normal upgrade path installed gcc-4.9 and broke my dkms setup and in
> turn my iptables setup. So it fell back on my fail2ban protection
> against ssh scripts.
> 
> /usr/bin/gcc-4.8 was on strange file permissions, with not even
> execute perms for root. Thus de dkms rebuild failed.
> 
> now my questions:
> 
> why was gcc-4.8 binary set to no execution, even for root?
> 
> why is xtables-addons-dkms not using gcc-4.9?
> 
> a simple chmod 700 /usr/bin/gcc-4.8 fixed the problem.
> 
> Thank you for any enlightenment

Your fixup might give a clue as to how it got the wrong permissions:
you've just broken your gcc-4.8 which ought to be executable by all
(as should everything in /usr/bin).

lrwxrwxrwx 1 root   root 7 Feb 25  2015 gcc -> gcc-4.9*
-rwxr-xr-x 1 root   root715448 Dec 20  2014 gcc-4.8*
-rwxr-xr-x 1 root   root806344 Feb 10 18:17 gcc-4.9*

Cheers,
David.



How to correctly select gcc / why dkms rebuild failed on xtables-addons

2018-03-20 Thread Neo

Hey folks

I've had a setup with xtables-addons running (on jessie with standard 
repos), especially the geoip module in this case. The normal upgrade 
path installed gcc-4.9 and broke my dkms setup and in turn my iptables 
setup. So it fell back on my fail2ban protection against ssh scripts.


/usr/bin/gcc-4.8 was on strange file permissions, with not even execute 
perms for root. Thus de dkms rebuild failed.


now my questions:

why was gcc-4.8 binary set to no execution, even for root?

why is xtables-addons-dkms not using gcc-4.9?

a simple chmod 700 /usr/bin/gcc-4.8 fixed the problem.

Thank you for any enlightenment

best regards



Re: Install or build an older gcc/g++ on new Debian (GCC backport)

2018-02-23 Thread Reco
Hi.

On Fri, Feb 23, 2018 at 05:57:59PM +, Bas Ali wrote:
> 
> Hi,
> Just to need help for what concerning to build or/and install an older GCC on 
> a new Debian Distro (e.g 8.8 or 9.3)
> The goal is to be able to compile and build binaries on the New Debian with 
> an older GCC to keep backcompatibility of binaries program previously built 
> on Debian 7 (32bits Wheezy)  using the built-in GCC (4.7.2). Ideally the two 
> binaries built from a Debian 7 32bits and from Debian 8 64bits will be the 
> same byte a byte. 

That could be much more complex than using old GCC.
These guys - [1] - are trying to solve much easier problem - and they
aren't there yet.


> At this moment I know that it possible (but maybe not the good solution ?) to 
> build a 4.7.2 GCC source with the Built-in GCC of a Debian 8.8 (64bits 
> Jessie) but it appears that for > 4.5 GCC there is a need to build too other 
> packages (MPC, MPFR,..) separately (using some option to built on good 
> directory).

Being lazy, I solve such problems with good old chroot.
I mean, why go into all this trouble by compiling a toolchain from the
source if someone did it already.

You need something built for Debian 7 i386? Make a chroot of Debian 7
i386 and build you binaries there.

Making chroot by hand sounds too complex? Use LXC, they have a nice easy
way to set up pretty much any major Linux distribution in a container.

[1] https://wiki.debian.org/ReproducibleBuilds

Reco



Re: Install or build an older gcc/g++ on new Debian (GCC backport)

2018-02-23 Thread Greg Wooledge
On Fri, Feb 23, 2018 at 05:57:59PM +, Bas Ali wrote:
> Just to need help for what concerning to build or/and install an older GCC on 
> a new Debian Distro (e.g 8.8 or 9.3)
> The goal is to be able to compile and build binaries on the New Debian with 
> an older GCC to keep backcompatibility of binaries program previously built 
> on Debian 7 (32bits Wheezy)  using the built-in GCC (4.7.2). Ideally the two 
> binaries built from a Debian 7 32bits and from Debian 8 64bits will be the 
> same byte a byte. 

Just install wheezy in a chroot and compile there, if you want to produce
programs that can run on wheezy.



Install or build an older gcc/g++ on new Debian (GCC backport)

2018-02-23 Thread Bas Ali

Hi,
Just to need help for what concerning to build or/and install an older GCC on a 
new Debian Distro (e.g 8.8 or 9.3)
The goal is to be able to compile and build binaries on the New Debian with an 
older GCC to keep backcompatibility of binaries program previously built on 
Debian 7 (32bits Wheezy)  using the built-in GCC (4.7.2). Ideally the two 
binaries built from a Debian 7 32bits and from Debian 8 64bits will be the same 
byte a byte. 
At this moment I know that it possible (but maybe not the good solution ?) to 
build a 4.7.2 GCC source with the Built-in GCC of a Debian 8.8 (64bits Jessie) 
but it appears that for > 4.5 GCC there is a need to build too other packages 
(MPC, MPFR,..) separately (using some option to built on good directory).
Is this method bellow correct ? 
I think there will be the main libraries (libgcc, libc, libstdc++,.. ) to check 
for changes from previous version etc...
 Do I need to install gcc-multilib because the 4.7.2 GCC was from a 32 bits 
machine ?Do I need to add Multi ARCH  (e.g.: dpkg  --add-architecture i386) ?
Thanks in advanceAli


Re: kernel 4.14.15 compilation using GCC 8 in unstable.......

2018-01-27 Thread tv.deb...@googlemail.com

On 27/01/2018 22:47, Michael Lange wrote:

Hi,

On Sat, 27 Jan 2018 22:30:06 +0530
"tv.deb...@googlemail.com"  wrote:


Hi, you need to read the kernel-package doc, it requires configuration.
Read at the minimum /usr/share/doc/kernel-package/README.gz
It contains all the info you need, and even gives you hints as to how
to configure your system, like:

"
  Or, alternately, you could do:
--8<---cut here---start->8---
   cp /usr/share/kernel-package/examples/etc/kernel/postinst.d/initramfs
\ /etc/kernel/postinst.d/
   cp /usr/share/kernel-package/examples/etc/kernel/postrm.d/initramfs \
  /etc/kernel/postrm.d/
--8<---cut here---end--->8---
"

to get a working initrd.


it is certainly a good advice to read the docs before starting.
But then, I admit that I never did and never configured anything for
make-kpkg (besides installing required software of course) and the
resulting kernel packages including the initrd's "just worked".
So I guess that the OP's problem do not result from a misconfigured
kernel-package (unless the OP changed some defaults for the worse) but
from something else. Just a guess of course.

My guess is, that the "make clean" command issued before the last build
attempt failed to clean the source tree properly and the try before was
not succesful either.







Then "make-kpkg clean" may be the answer ?



Re: kernel 4.14.15 compilation using GCC 8 in unstable.......

2018-01-27 Thread Michael Lange
Hi,

On Sat, 27 Jan 2018 22:30:06 +0530
"tv.deb...@googlemail.com"  wrote:

> Hi, you need to read the kernel-package doc, it requires configuration. 
> Read at the minimum /usr/share/doc/kernel-package/README.gz
> It contains all the info you need, and even gives you hints as to how
> to configure your system, like:
> 
> "
>  Or, alternately, you could do:
> --8<---cut here---start->8---
>   cp /usr/share/kernel-package/examples/etc/kernel/postinst.d/initramfs
> \ /etc/kernel/postinst.d/
>   cp /usr/share/kernel-package/examples/etc/kernel/postrm.d/initramfs \
>  /etc/kernel/postrm.d/
> --8<---cut here---end--->8---
> "
> 
> to get a working initrd.

it is certainly a good advice to read the docs before starting.
But then, I admit that I never did and never configured anything for
make-kpkg (besides installing required software of course) and the
resulting kernel packages including the initrd's "just worked".
So I guess that the OP's problem do not result from a misconfigured
kernel-package (unless the OP changed some defaults for the worse) but
from something else. Just a guess of course.

My guess is, that the "make clean" command issued before the last build
attempt failed to clean the source tree properly and the try before was
not succesful either.





.-.. .. ...- .   .-.. --- -. --.   .- -. -..   .--. .-. --- ... .--. . .-.

... bacteriological warfare ... hard to believe we were once foolish
enough to play around with that.
-- McCoy, "The Omega Glory", stardate unknown



Re: kernel 4.14.15 compilation using GCC 8 in unstable.......

2018-01-27 Thread tv.deb...@googlemail.com

On 27/01/2018 20:30, Michael Fothergill wrote:

On 27 January 2018 at 13:38, Michael Lange <klappn...@freenet.de> wrote:


Hi,

On Sat, 27 Jan 2018 13:12:13 +
Michael Fothergill <michael.fotherg...@gmail.com> wrote:


​I think I will sign up on the gcc gnu help page and ask people if they
have a test case file I can run to 100% confirm the GCC 8 compiler is
running properly.​
​Once I am convinced it is then the next stage is to try to talk to the
developers who maintain the make-kpkg program.


are you still using gcc-8? Here this one didn't work at all for me,
compiling always aborted early with compiler errors. It worked
immediately though after I removed ggc-8 and upgraded gcc-7 to v. 7.3
from sid.

Regards

Michael



​I have sent the kernel-source package maintainer the following email:

**

Dear Sir,

I understand that you are the package maintainer for kernel-source ie
make-kpkg etc. within debian.

I am running debian unstable (Sid)on an amd64 kaveri box.

I installed GCC 8 from the experimental repository.  I am trying to use it
to compile the kernel 4.14.15 using make-kpkg to use the fixes for the
meltdown and spectre vulnerabilities.

The output from doing this is here:

https://pastebin.com/sgrhdCKW

Make-kpkg did not create any linux-image file ..?!

I copied over the config file from/boot and ran make-clean and the
command:  yes "" | make oldconfig before running make-kpkg.

Kernel compilations I do in gentoo (I am a gentoo user as well as a debian
user) usually take a while.

This ran too quickly I think.

Something is not quite right here I think.

It might be that more dependent packages needed to be installed to make
GCC8 run happily.

As a result I have sent an email to the gnu gcc help site (
gcc-h...@gcc.gnu.org) asking them for a test file to check that GCC8 is
running correctly.

But, maybe you might say that make-kpkg needs to be upgraded in some way to
work correctly here and GCC 8 ran OK...


The discussions on these two threads are relevant to this case:

https://lists.debian.org/debian-user/2018/01/msg01159.html

https://lists.debian.org/debian-user/2018/01/msg01002.html

We are all trying to compile kernels that defeat the meltdown and spectre
vulnerabilities.

Comments appreciated.

Regards
​
etc

*

Maybe will end up having to quit with GCC8 but it I am giving it one last
attempt here.

Cheers

MF






.-.. .. ...- .   .-.. --- -. --.   .- -. -..   .--. .-. --- ... .--. . .-.

 "It's hard to believe that something which is neither seen nor
felt can do so much harm."
 "That's true.  But an idea can't be seen or felt.  And that's
what kept the Troglytes in the mines all these centuries.  A mistaken
idea."
 -- Vanna and Kirk, "The Cloud Minders", stardate 5819.0






Hi, you need to read the kernel-package doc, it requires configuration. 
Read at the minimum /usr/share/doc/kernel-package/README.gz
It contains all the info you need, and even gives you hints as to how to 
configure your system, like:


"
Or, alternately, you could do:
--8<---cut here---start->8---
 cp /usr/share/kernel-package/examples/etc/kernel/postinst.d/initramfs \
/etc/kernel/postinst.d/
 cp /usr/share/kernel-package/examples/etc/kernel/postrm.d/initramfs \
/etc/kernel/postrm.d/
--8<---cut here---end--->8---
"

to get a working initrd.

Once it is configured you need a command that will look like:

make-kpkg -j 4 --revision 1 --append_to_version -mykernel --initrd 
kernel_image kernel_headers


to build both kernel and headers packages, and get and initrd to boot 
on. The default is to create the packages one level above the current 
directory (../).


I don't think it is the maintainer to walk you through the procedure, he 
already wrote the docs.


Building on a custom kernel is not very difficult, but it isn't as 
trivial as an "apt-get install", some extra work and care are required. 
And you may void your Debian warranty (you have none anyway) ;-) .




Re: kernel 4.14.15 compilation using GCC 8 in unstable.......

2018-01-27 Thread Michael Fothergill
On 27 January 2018 at 13:38, Michael Lange <klappn...@freenet.de> wrote:

> Hi,
>
> On Sat, 27 Jan 2018 13:12:13 +
> Michael Fothergill <michael.fotherg...@gmail.com> wrote:
>
> > ​I think I will sign up on the gcc gnu help page and ask people if they
> > have a test case file I can run to 100% confirm the GCC 8 compiler is
> > running properly.​
> > ​Once I am convinced it is then the next stage is to try to talk to the
> > developers who maintain the make-kpkg program.
>
> are you still using gcc-8? Here this one didn't work at all for me,
> compiling always aborted early with compiler errors. It worked
> immediately though after I removed ggc-8 and upgraded gcc-7 to v. 7.3
> from sid.
>
> Regards
>
> Michael
>

​I have sent the kernel-source package maintainer the following email:

**

Dear Sir,

I understand that you are the package maintainer for kernel-source ie
make-kpkg etc. within debian.

I am running debian unstable (Sid)on an amd64 kaveri box.

I installed GCC 8 from the experimental repository.  I am trying to use it
to compile the kernel 4.14.15 using make-kpkg to use the fixes for the
meltdown and spectre vulnerabilities.

The output from doing this is here:

https://pastebin.com/sgrhdCKW

Make-kpkg did not create any linux-image file ..?!

I copied over the config file from/boot and ran make-clean and the
command:  yes "" | make oldconfig before running make-kpkg.

Kernel compilations I do in gentoo (I am a gentoo user as well as a debian
user) usually take a while.

This ran too quickly I think.

Something is not quite right here I think.

It might be that more dependent packages needed to be installed to make
GCC8 run happily.

As a result I have sent an email to the gnu gcc help site (
gcc-h...@gcc.gnu.org) asking them for a test file to check that GCC8 is
running correctly.

But, maybe you might say that make-kpkg needs to be upgraded in some way to
work correctly here and GCC 8 ran OK...


The discussions on these two threads are relevant to this case:

https://lists.debian.org/debian-user/2018/01/msg01159.html

https://lists.debian.org/debian-user/2018/01/msg01002.html

We are all trying to compile kernels that defeat the meltdown and spectre
vulnerabilities.

Comments appreciated.

Regards
​
etc

*

Maybe will end up having to quit with GCC8 but it I am giving it one last
attempt here.

Cheers

MF




>
> .-.. .. ...- .   .-.. --- -. --.   .- -. -..   .--. .-. --- ... .--. . .-.
>
> "It's hard to believe that something which is neither seen nor
> felt can do so much harm."
> "That's true.  But an idea can't be seen or felt.  And that's
> what kept the Troglytes in the mines all these centuries.  A mistaken
> idea."
> -- Vanna and Kirk, "The Cloud Minders", stardate 5819.0
>
>


Re: kernel 4.14.15 compilation using GCC 8 in unstable.......

2018-01-27 Thread Michael Fothergill
On 27 January 2018 at 13:38, Michael Lange <klappn...@freenet.de> wrote:

> Hi,
>
> On Sat, 27 Jan 2018 13:12:13 +
> Michael Fothergill <michael.fotherg...@gmail.com> wrote:
>
> > ​I think I will sign up on the gcc gnu help page and ask people if they
> > have a test case file I can run to 100% confirm the GCC 8 compiler is
> > running properly.​
> > ​Once I am convinced it is then the next stage is to try to talk to the
> > developers who maintain the make-kpkg program.
>
> are you still using gcc-8? Here this one didn't work at all for me,
> compiling always aborted early with compiler errors. It worked
> immediately though after I removed ggc-8 and upgraded gcc-7 to v. 7.3
> from sid.
>
> Regards
>
>
> Michael
>

​PS The maintainer of  ​
 kernel-package
​ (https://tracker.debian.org/pkg/kernel-package) that contains make-kpkg
is: ​Manoj Srivastava <sriva...@debian.org> .

Cheers

MF



> .-.. .. ...- .   .-.. --- -. --.   .- -. -..   .--. .-. --- ... .--. . .-.
>
> "It's hard to believe that something which is neither seen nor
> felt can do so much harm."
> "That's true.  But an idea can't be seen or felt.  And that's
> what kept the Troglytes in the mines all these centuries.  A mistaken
> idea."
> -- Vanna and Kirk, "The Cloud Minders", stardate 5819.0
>
>


Re: kernel 4.14.15 compilation using GCC 8 in unstable.......

2018-01-27 Thread Michael Fothergill
On 27 January 2018 at 13:38, Michael Lange <klappn...@freenet.de> wrote:

> Hi,
>
> On Sat, 27 Jan 2018 13:12:13 +
> Michael Fothergill <michael.fotherg...@gmail.com> wrote:
>
> > ​I think I will sign up on the gcc gnu help page and ask people if they
> > have a test case file I can run to 100% confirm the GCC 8 compiler is
> > running properly.​
> > ​Once I am convinced it is then the next stage is to try to talk to the
> > developers who maintain the make-kpkg program.
>
> are you still using gcc-8? Here this one didn't work at all for me,
> compiling always aborted early with compiler errors. It worked
> immediately though after I removed ggc-8 and upgraded gcc-7 to v. 7.3
> from sid.
>

​In my case after I took you helpful advice and installed libelf-dev in GCC
8 (which I am still using)  the crash I had went away.
​
I think now GCC 8 is close to working OK.

Perhaps it needs another little nudge or some other package we don't know
about.

I have sent the gnu gcc help people the following email:

**

Dear All,

I am running debian unstable on an amd64 kaveri box.

I recently installed GCC 8 from the Debian experimental site:

https://packages.debian.org/experimental/devel/gcc-8

I also installed libelf-dev.

It did run correctly without it.

I have been using it to try to compile and install linux kernel 4.14.15
using the
debian package make-kpkg.

The output from doing this is here:

https://pastebin.com/sgrhdCKW

I copied over the config file from/boot and ran make-clean and the
command:  yes "" | make oldconfig before running make-kpkg.

Kernel compilations I do in gentoo usually take a while.

This ran too quickly I think.

Something is not quite right here.

Perhaps some more depedent packages needed to be installed to make GCC8 run
happily.

Do you have a test file I can compile that will check whether GCC 8 is
really running correctly?

The discussions on these two threads are relevant:

https://lists.debian.org/debian-user/2018/01/msg01159.html

https://lists.debian.org/debian-user/2018/01/msg01002.html

We are all trying to compile kernels that defeat the meltdown and spectre
vulnerabilities.

Comments appreciated.

Regards

​MF​



Maybe they can help here.

Cheers

MF



>
> Regards
>
> Michael
>
> .-.. .. ...- .   .-.. --- -. --.   .- -. -..   .--. .-. --- ... .--. . .-.
>
> "It's hard to believe that something which is neither seen nor
> felt can do so much harm."
> "That's true.  But an idea can't be seen or felt.  And that's
> what kept the Troglytes in the mines all these centuries.  A mistaken
> idea."
> -- Vanna and Kirk, "The Cloud Minders", stardate 5819.0
>
>


Re: kernel 4.14.15 compilation using GCC 8 in unstable.......

2018-01-27 Thread Michael Fothergill
On 27 January 2018 at 13:17, Michael Lange  wrote:

> On Sat, 27 Jan 2018 12:32:24 +
> Michael Fothergill  wrote:
>
> > On 27 January 2018 at 11:59, Michael Lange  wrote:
> >
> > > Hi,
> > >
> > > On Sat, 27 Jan 2018 11:26:25 +
> > > Michael Fothergill  wrote:
> > >
> > > >
> > > > Where would the default location of such a file be if were created
> > > > using the make-kpkg command?
> > >
> > > the package should be in the source's parent directory, in your case I
> > > guess in /usr/src .
> > >
> >
> > ​I think something is not right here. The compilation was very quick.
> > Normally in gentoo the kernel compilation takes a little while.
> > Maybe something got left out.
> >
> > Maybe I should have run mrproper after make clean before running
> > make-kpkg.
>
> Yes, I naturally cannot tell from here, but it sounds like for some
> reason the procedure was terminated prematurely.
>

​But, you would argue that what terminated was the make-kpkg efforts to
make use of the result of the successful compilation not a malfunction of
the compiler itself

At least I think that is what you are saying/suggesting here.

It did occur to me that maybe I still need some extra package to be
installed either for the compiler or make-kpkg here.

Cheers

MF​



>
> Regards
>
> Michael
>
>
> .-.. .. ...- .   .-.. --- -. --.   .- -. -..   .--. .-. --- ... .--. . .-.
>
> It is necessary to have purpose.
> -- Alice #1, "I, Mudd", stardate 4513.3
>
>


Re: kernel 4.14.15 compilation using GCC 8 in unstable.......

2018-01-27 Thread Michael Lange
Hi,

On Sat, 27 Jan 2018 13:12:13 +
Michael Fothergill <michael.fotherg...@gmail.com> wrote:

> ​I think I will sign up on the gcc gnu help page and ask people if they
> have a test case file I can run to 100% confirm the GCC 8 compiler is
> running properly.​
> ​Once I am convinced it is then the next stage is to try to talk to the
> developers who maintain the make-kpkg program.

are you still using gcc-8? Here this one didn't work at all for me,
compiling always aborted early with compiler errors. It worked
immediately though after I removed ggc-8 and upgraded gcc-7 to v. 7.3
from sid.

Regards

Michael

.-.. .. ...- .   .-.. --- -. --.   .- -. -..   .--. .-. --- ... .--. . .-.

"It's hard to believe that something which is neither seen nor
felt can do so much harm."
"That's true.  But an idea can't be seen or felt.  And that's
what kept the Troglytes in the mines all these centuries.  A mistaken
idea."
-- Vanna and Kirk, "The Cloud Minders", stardate 5819.0



Re: kernel 4.14.15 compilation using GCC 8 in unstable.......

2018-01-27 Thread Michael Fothergill
On 27 January 2018 at 12:43, Michael Lange <klappn...@freenet.de> wrote:

> Hi,
>
> On Sat, 27 Jan 2018 12:12:57 +
> Michael Fothergill <michael.fotherg...@gmail.com> wrote:
>
> >
> > ​Should the filename be something like linux-image-4.14.14.deb etc?
>
> With default settings for make-kpkg the filename is probably a little
> longer, here it looks like
>
> linux-image-4.15.0-rc9-klappnase270118_4.15.0-rc9-
> klappnase270118-10.00.Custom_amd64.deb
>
>
> >
> > Maybe Greg could think some find command that would search everywhere in
> > the install I have here and then find it in some funny directory (even
> > /tmp?) no one has ever heard of.
> >
> > I would be grateful for suggestions here.
> >
> > Could there be a bug in gcc 8 that made it forget to actually output the
> > file?
>
> I don't think that gcc is to blame.


​I think I will sign up on the gcc gnu help page and ask people if they
have a test case file I can run to 100% confirm the GCC 8 compiler is
running properly.​
​Once I am convinced it is then the next stage is to try to talk to the
developers who maintain the make-kpkg program.

Cheers

MF​




> Did you look at the final messages
> make-kpkg printed? If run successfully it should say something like
> "building package linux-image-..." .
>
> Regards
>
> Michael
>

​​



>
>
> .-.. .. ...- .   .-.. --- -. --.   .- -. -..   .--. .-. --- ... .--. . .-.
>
> Power is danger.
> -- The Centurion, "Balance of Terror", stardate 1709.2
>
>


Re: kernel 4.14.15 compilation using GCC 8 in unstable.......

2018-01-27 Thread Michael Lange
On Sat, 27 Jan 2018 12:32:24 +
Michael Fothergill  wrote:

> On 27 January 2018 at 11:59, Michael Lange  wrote:
> 
> > Hi,
> >
> > On Sat, 27 Jan 2018 11:26:25 +
> > Michael Fothergill  wrote:
> >
> > >
> > > Where would the default location of such a file be if were created
> > > using the make-kpkg command?
> >
> > the package should be in the source's parent directory, in your case I
> > guess in /usr/src .
> >
> 
> ​I think something is not right here. The compilation was very quick.
> Normally in gentoo the kernel compilation takes a little while.
> Maybe something got left out.
> 
> Maybe I should have run mrproper after make clean before running
> make-kpkg.

Yes, I naturally cannot tell from here, but it sounds like for some
reason the procedure was terminated prematurely.

Regards

Michael


.-.. .. ...- .   .-.. --- -. --.   .- -. -..   .--. .-. --- ... .--. . .-.

It is necessary to have purpose.
-- Alice #1, "I, Mudd", stardate 4513.3



Re: kernel 4.14.15 compilation using GCC 8 in unstable.......

2018-01-27 Thread Michael Fothergill
It does seem as if make-kpkg has gone awol here.

MF


Re: kernel 4.14.15 compilation using GCC 8 in unstable.......

2018-01-27 Thread Michael Fothergill
On 27 January 2018 at 12:43, Michael Lange <klappn...@freenet.de> wrote:

> Hi,
>
> On Sat, 27 Jan 2018 12:12:57 +
> Michael Fothergill <michael.fotherg...@gmail.com> wrote:
>
> >
> > ​Should the filename be something like linux-image-4.14.14.deb etc?
>
> With default settings for make-kpkg the filename is probably a little
> longer, here it looks like
>
> linux-image-4.15.0-rc9-klappnase270118_4.15.0-rc9-
> klappnase270118-10.00.Custom_amd64.deb
>
>
> >
> > Maybe Greg could think some find command that would search everywhere in
> > the install I have here and then find it in some funny directory (even
> > /tmp?) no one has ever heard of.
> >
> > I would be grateful for suggestions here.
> >
> > Could there be a bug in gcc 8 that made it forget to actually output the
> > file?
>
> I don't think that gcc is to blame. Did you look at the final messages
> make-kpkg printed? If run successfully it should say something like
> "building package linux-image-..." .
>

​It never did it.   It did this at the end:​


chmod 0644 debian/control debian/changelog
make -f debian/rules debian/stamp/conf/kernel-conf
make[2]: Entering directory '/usr/src/linux-4.14.15'
make[2]: 'debian/stamp/conf/kernel-conf' is up to date.
make[2]: Leaving directory '/usr/src/linux-4.14.15'
make[1]: Leaving directory '/usr/src/linux-4.14.15'
echo done > debian/stamp/conf/minimal_debian
exec debian/rules
nothing to be done.

​and stopped.

if you look through the rest of the output I posted above its not there
AFAICT.

Cheers

MF​



> Regards
>
> Michael
>
>
> .-.. .. ...- .   .-.. --- -. --.   .- -. -..   .--. .-. --- ... .--. . .-.
>
> Power is danger.
> -- The Centurion, "Balance of Terror", stardate 1709.2
>
>


Re: kernel 4.14.15 compilation using GCC 8 in unstable.......

2018-01-27 Thread Michael Fothergill
On 27 January 2018 at 11:59, Michael Lange  wrote:

> Hi,
>
> On Sat, 27 Jan 2018 11:26:25 +
> Michael Fothergill  wrote:
>
> >
> > Where would the default location of such a file be if were created using
> > the make-kpkg command?
>
> the package should be in the source's parent directory, in your case I
> guess in /usr/src .
>

​I think something is not right here. The compilation was very quick.
Normally in gentoo the kernel compilation takes a little while.
Maybe something got left out.

Maybe I should have run mrproper after make clean before running make-kpkg.

Cheers

MF​


>
> Regards
>
> Michael
>
>
> .-.. .. ...- .   .-.. --- -. --.   .- -. -..   .--. .-. --- ... .--. . .-.
>
> Vulcans never bluff.
> -- Spock, "The Doomsday Machine", stardate 4202.1
>
>


  1   2   3   4   5   6   7   8   9   10   >