Re: [Simulavr-devel] simulavr-1.0.0 Build Fails.

[Georg-Johann Lay]

Hi, please CC me in your answers, I am not subscribed to this list
and just found your mail per accident while skimming the mail archive.

Thomas K a écrit:

(Not CC'ing you as I don't see you email address.)

> Hi Johann,
>
> as Klaus wrote, version 1.0 is just a little bit outdated :-) So, with
> the current versions of gcc you'll get errors just because of newer
> version of gcc!

If you get errors from g++, then maybe because g++ switched the default
language, cf. the "GCC 6 Release Series, Caveats".

http://gcc.gnu.org/gcc-6/changes.html

If you need some specific C++ dialect in the project, you can add
-std=... to the default XCCFLAGS, see

http://gcc.gnu.org/onlinedocs/gcc/C-Dialect-Options.html

Moreover, some warnings indicate that varargs arguments don't fit the
expected %-code.  This might lead to simulavr crashing or going bananas.

> But if I understand your "No avail." right, you're pinned on version
> 1.0? Why, 

I am not restricted to a specific version, it was just the case that
using master didn't fix "hwtiner.h not found".  And the run time error
"option -M not recognized" also persists with master.

> what's your scope to use simulavr? (just curious)

Mainly because it supplies a gdb server.  I added a new feature to
GCC / GAS

https://gcc.gnu.org/PR81268

and was curious how a debugger would represent respective code.  As
I am not using debuggers for AVR, I am not really familiar with the
nits and bits thereof.  What I don't need is (internal) I/O simulation,
I'd be just fine with a working AVR core simulator + gdb server.

For GCC testing I am using avrtest simulator because of its speed,
and in cases when a run test fails, avrtest provides some nice features
for logging (and also profiling).

> On the other hand, that hwtimer.h isn't found is not because of newer
> gcc version. How do you get the package? Cloned from git repo? Or dist

$ git clone --branch master *.git

> package (tar.gz)? Could you check, if the file hwtimer.h is contained in
> your package and where?

As already noted, the problem is that simulavr has some implicit
"builddir == srcdir" assertions and is using bad include paths with -I.
It will need -I$(srcdir)/ui instead of -Iui and similar for some more
paths in CXXFLAGS.  In one case, the canonical choice would be 
$(top_srcdir).

I am preferring builddir != srcdir if possible, and autotools support
it well.  Just see configure --help.  I supplied a patch to fix that
issue.  I'd expect that simulavr patches would automatically pop up
here in the simulavr-devel mailing list, but obviously they don't...

So here is a pointer to the fix:

https://savannah.nongnu.org/patch/?9406

Cheers, Johann

> cu, Thomas

...and excuse me for not using TOFU style.