[GRASS5] Problems compiling and running GRASS6.CVS

GRASS GIS GRASS GIS developer
1

Hi all, in order to try the latest GUI (among other new features), I've compiled and run the current CVS version. On the first run through of make, there were a lot of errors regarding failed compiles which seemed to be related to path errors. After make install, the source code would not start, and crashed with errors.

I ran make another couple of times, and on try 2.5 (ctrl-c in the middle of try 2) I got a clean compile. make install now gives a running executable.

Should I report this as a bug, or is it too soon in the development cycle to worry about this behaviour?

Michael

2

Michael Rensing wrote:

Hi all, in order to try the latest GUI (among other new features), I've
compiled and run the current CVS version. On the first run through of
make, there were a lot of errors regarding failed compiles which seemed
to be related to path errors. After make install, the source code would
not start, and crashed with errors.

I ran make another couple of times, and on try 2.5 (ctrl-c in the middle
of try 2) I got a clean compile. make install now gives a running
executable.

Should I report this as a bug, or is it too soon in the development
cycle to worry about this behaviour?

Can you provide specific details?

--
Glynn Clements <glynn@gclements.plus.com>

3

Glynn Clements wrote:

Michael Rensing wrote:

Hi all, in order to try the latest GUI (among other new features), I've compiled and run the current CVS version. On the first run through of make, there were a lot of errors regarding failed compiles which seemed to be related to path errors. After make install, the source code would not start, and crashed with errors.

I ran make another couple of times, and on try 2.5 (ctrl-c in the middle of try 2) I got a clean compile. make install now gives a running executable.

Should I report this as a bug, or is it too soon in the development cycle to worry about this behaviour?
    
Can you provide specific details?

I'd have to wipe the directory and reload from CVS, but I'm just getting started, so I don't mind doing it a couple of times. However, the output just scrolls by on the screen so I'd have to capture it somehow and then send you the file.

Do you want me to do that, or try something else?

Michael

4

Michael Rensing wrote:

>> Hi all, in order to try the latest GUI (among other new features), I've
>> compiled and run the current CVS version. On the first run through of
>> make, there were a lot of errors regarding failed compiles which seemed
>> to be related to path errors. After make install, the source code would
>> not start, and crashed with errors.
>>
>> I ran make another couple of times, and on try 2.5 (ctrl-c in the middle
>> of try 2) I got a clean compile. make install now gives a running
>> executable.
>>
>> Should I report this as a bug, or is it too soon in the development
>> cycle to worry about this behaviour?
>
> Can you provide specific details?

I'd have to wipe the directory and reload from CVS,

"make distclean" should remove everything which was generated by the
build process, leaving only the files which are in the CVS repository.

but I'm just getting
started, so I don't mind doing it a couple of times. However, the output
just scrolls by on the screen so I'd have to capture it somehow and then
send you the file.

Do you want me to do that, or try something else?

If there are any build errors, it would be useful to see the relevant
portion of the output from "make", not the entire file.

Typically, the relevant portion is just the command which fails.

If a library fails to build, anything which depends on it will also
fail; in that case, we only need to see the errors for the library.

In general, I would suggest running "make" as:

  make CFLAGS_WARNING= &>build.log

so that you have a record if anything goes wrong.

[The current default setting of CFLAGS_WARNING enables too many
warnings, resulting in significant warnings getting lost in the noise.
I'll change that.]

--
Glynn Clements <glynn@gclements.plus.com>

5

[The current default setting of CFLAGS_WARNING enables too many
warnings, resulting in significant warnings getting lost in the noise.
I'll change that.]

what are the recommended gcc settings for pedantic developers to use?

Hamish

6

Hamish wrote:

> [The current default setting of CFLAGS_WARNING enables too many
> warnings, resulting in significant warnings getting lost in the noise.
> I'll change that.]

what are the recommended gcc settings for pedantic developers to use?

If you're compiling a specific module which you're working on, the
default setting (-Wall -Wconversion -Wno-implicit-int) is probably
appropriate. Otherwise, it should be empty, so that you only get the
compiler's default warnings.

FWIW, I wouldn't suggest trying to eliminate all of the warnings
arising from -Wconversion; just check that they don't indicate flaws
in your code.

--
Glynn Clements <glynn@gclements.plus.com>

7

On Wed, Apr 05, 2006 at 08:59:23PM +0100, Glynn Clements wrote:

Hamish wrote:

> > [The current default setting of CFLAGS_WARNING enables too many
> > warnings, resulting in significant warnings getting lost in the noise.
> > I'll change that.]
>
> what are the recommended gcc settings for pedantic developers to use?

If you're compiling a specific module which you're working on, the
default setting (-Wall -Wconversion -Wno-implicit-int) is probably
appropriate. Otherwise, it should be empty, so that you only get the
compiler's default warnings.

FWIW, I wouldn't suggest trying to eliminate all of the warnings
arising from -Wconversion; just check that they don't indicate flaws
in your code.

I am using
CFLAGS="-g -Wall -pedantic -Werror-implicit-function-declaration -fno-common"

for long time now which seems to be quite successfully as it
- stops on severe problems (so, nothing get's lost in noise then)
- traps most wrong/absent declarations

Markus

8

Markus Neteler wrote:

> > > [The current default setting of CFLAGS_WARNING enables too many
> > > warnings, resulting in significant warnings getting lost in the noise.
> > > I'll change that.]
> >
> > what are the recommended gcc settings for pedantic developers to use?
>
> If you're compiling a specific module which you're working on, the
> default setting (-Wall -Wconversion -Wno-implicit-int) is probably
> appropriate. Otherwise, it should be empty, so that you only get the
> compiler's default warnings.
>
> FWIW, I wouldn't suggest trying to eliminate all of the warnings
> arising from -Wconversion; just check that they don't indicate flaws
> in your code.
>

I am using
CFLAGS="-g -Wall -pedantic -Werror-implicit-function-declaration -fno-common"

for long time now which seems to be quite successfully as it
- stops on severe problems (so, nothing get's lost in noise then)
- traps most wrong/absent declarations

Note that CFLAGS_WARNING is appended to the compilation command
regardless of the CFLAGS setting.

I intend to remove the references to CFLAGS_WARNING; the user should
use CFLAGS as above to select the warning switches.

The actuall setting of CFLAGS_WARNING comes from SC_CONFIG_CFLAGS in
aclocal.m4. I'm not sure if it was there originally or added later.

--
Glynn Clements <glynn@gclements.plus.com>

9

On Wed, Apr 05, 2006 at 10:59:15PM +0100, Glynn Clements wrote:

Markus Neteler wrote:

> > > > [The current default setting of CFLAGS_WARNING enables too many
> > > > warnings, resulting in significant warnings getting lost in the noise.
> > > > I'll change that.]
> > >
> > > what are the recommended gcc settings for pedantic developers to use?
> >
> > If you're compiling a specific module which you're working on, the
> > default setting (-Wall -Wconversion -Wno-implicit-int) is probably
> > appropriate. Otherwise, it should be empty, so that you only get the
> > compiler's default warnings.
> >
> > FWIW, I wouldn't suggest trying to eliminate all of the warnings
> > arising from -Wconversion; just check that they don't indicate flaws
> > in your code.
> >
>
> I am using
> CFLAGS="-g -Wall -pedantic -Werror-implicit-function-declaration -fno-common"
>
> for long time now which seems to be quite successfully as it
> - stops on severe problems (so, nothing get's lost in noise then)
> - traps most wrong/absent declarations

Note that CFLAGS_WARNING is appended to the compilation command
regardless of the CFLAGS setting.

I intend to remove the references to CFLAGS_WARNING; the user should
use CFLAGS as above to select the warning switches.

The actuall setting of CFLAGS_WARNING comes from SC_CONFIG_CFLAGS in
aclocal.m4. I'm not sure if it was there originally or added later.

Ah, sorry for the confusion. So, good that you want to clean up stuff.

thanks

Markus

10

On Wed, 5 Apr 2006, Glynn Clements wrote:

Note that CFLAGS_WARNING is appended to the compilation command
regardless of the CFLAGS setting.

I intend to remove the references to CFLAGS_WARNING; the user should
use CFLAGS as above to select the warning switches.

The actuall setting of CFLAGS_WARNING comes from SC_CONFIG_CFLAGS in
aclocal.m4. I'm not sure if it was there originally or added later.

It was there originally when all the SC_* stuff was ported/copied from Tcl/Tk. Prior to that -Wall was hardcoded in, which broke things with non-gcc compilers. So I considered it an improvement that now it was only added when the compiler was gcc, and left it in. But a good idea to remove it and let the developers specify their own CFLAGS I think.

Paul

11

Glynn Clements wrote:

I intend to remove the references to CFLAGS_WARNING; the user should
use CFLAGS as above to select the warning switches.

OK, I've removed the following automated flags from Platform.make.in:

CFLAGS_DEBUG
CFLAGS_OPTIMIZE
CFLAGS_WARNING
LDFLAGS_DEBUG
LDFLAGS_OPTIMIZE

Of these, only CFLAGS_WARNING was actually being used.

The user can still add flags by setting CFLAGS, CXXFLAGS, and LDFLAGS
when running configure.

--
Glynn Clements <glynn@gclements.plus.com>

12

The user can still add flags by setting CFLAGS, CXXFLAGS, and LDFLAGS
when running configure.

While on the subject,

I've always been a bit confused about r.terraflow/IOStream/lib/src/Makefile
mixed use of CPPFLAGS and CXXFLAGS. grep shows support for CPPFLAGS in
aclocal.m4, configure.in, and Platform.make,... Are they two distinct
things or two attempts at the same thing? Also I think LFS support in
r.terraflow (it commonly creates >2gb temp files) is slightly confused;
outside the normal ./configure switches?

Hamish

13

Hamish wrote:

> The user can still add flags by setting CFLAGS, CXXFLAGS, and LDFLAGS
> when running configure.

While on the subject,

I've always been a bit confused about r.terraflow/IOStream/lib/src/Makefile
mixed use of CPPFLAGS and CXXFLAGS. grep shows support for CPPFLAGS in
aclocal.m4, configure.in, and Platform.make,... Are they two distinct
things or two attempts at the same thing?

Distinct.

CPPFLAGS should contain switches related to the C preprocessor (e.g.
-D, -I etc), while CFLAGS/CXXFLAGS should contain switches related to
the actual C/C++ compilers.

The command for compiling C files should include both $(CPPFLAGS) and
$(CFLAGS), while that for C++ files should include $(CPPFLAGS) and
$(CXXFLAGS), so CPPFLAGS should affect either type of file while
CFLAGS and CXXFLAGS should each only affect one type.

Also I think LFS support in
r.terraflow (it commonly creates >2gb temp files) is slightly confused;
outside the normal ./configure switches?

Probably.

--
Glynn Clements <glynn@gclements.plus.com>