problem building grass trunk

8 messages Options
Embed this post
Permalink
Stefano Salvador

problem building grass trunk

Reply Threaded More More options
Print post
Permalink
Hi,

I'm trying to compile revision 39598 of grass trunk but I get a list
of undefined symbol for almost all modules, the output of make is:

/root/grass_trunk/lib/form
/root/grass_trunk/lib/vector/diglib
/root/grass_trunk/lib/init
/root/grass_trunk/db/drivers/dbf
/root/grass_trunk/db/drivers/sqlite
/root/grass_trunk/db/drivers/ogr
/root/grass_trunk/db/db.columns
/root/grass_trunk/db/db.connect
/root/grass_trunk/db/db.copy
/root/grass_trunk/db/db.createdb
/root/grass_trunk/db/db.databases
/root/grass_trunk/db/db.describe
/root/grass_trunk/db/db.drivers
/root/grass_trunk/db/db.dropdb
/root/grass_trunk/db/db.droptable
/root/grass_trunk/db/db.execute
/root/grass_trunk/db/db.login
/root/grass_trunk/db/db.select
/root/grass_trunk/db/db.tables
/root/grass_trunk/display/d.barscale
/root/grass_trunk/display/d.colorlist
/root/grass_trunk/display/d.colortable
/root/grass_trunk/display/d.erase
/root/grass_trunk/display/d.font
[... many more ...]


if I run make in the first library with errors I get:

make /root/grass_trunk/dist.i686-pc-linux-gnu/etc/form
make[1]: Entering directory `/root/grass_trunk/lib/form'
make[1]: `/root/grass_trunk/dist.i686-pc-linux-gnu/etc/form' is up to date.
make[1]: Leaving directory `/root/grass_trunk/lib/form'
gcc -L/root/grass_trunk/dist.i686-pc-linux-gnu/lib
-L/root/grass_trunk/dist.i686-pc-linux-gnu/lib -Wl,--export-dynamic
-Wl,-rpath-link,/root/grass_trunk/dist.i686-pc-linux-gnu/lib   -o
/root/grass_trunk/dist.i686-pc-linux-gnu/etc/form/form
OBJ.i686-pc-linux-gnu/form.o -lgrass_ -lgrass_  -lgrass_ -lgrass_ \
                         -ltk8.4 -lm  -ltcl8.4 -lm -lm
OBJ.i686-pc-linux-gnu/form.o: In function `main':
/root/grass_trunk/lib/form/form.c:303: undefined reference to `G__gisinit'
/root/grass_trunk/lib/form/form.c:304: undefined reference to `G_debug'
[... many more ...]



the system is SUSE 10 with gcc 4.1, I have removed each previous
installation of grass.


any hint ?


Bye

Stefano
_______________________________________________
grass-dev mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/grass-dev
Glynn Clements

Re: problem building grass trunk

Reply Threaded More More options
Print post
Permalink

Stefano Salvador wrote:

> I'm trying to compile revision 39598 of grass trunk but I get a list
> of undefined symbol for almost all modules, the output of make is:

> if I run make in the first library with errors I get:

> -lgrass_ -lgrass_ -lgrass_ -lgrass_

Well, that's where it's going wrong.

I suspect that it's related to r38871, which uses $(eval $(call ...))
to define the *_LIBNAME, *LIB and *DEP variables:

        libs = \
                ARRAYSTATS:arraystats \
                BASIC:basic \
                BITMAP:bitmap \
        ...
       
        define lib_rules
        $(1)_LIBNAME = grass_$(2)
        ifneq ($(NEED_DEPS),)
        $(1)LIB = -l$$($(1)_LIBNAME) $$($(1)DEPS)
        else
        $(1)LIB = -l$$($(1)_LIBNAME)
        endif
        ifneq ($(1),IOSTREAM)
        $(1)DEP = $$(BASE_LIBDIR)/$$(LIB_PREFIX)$$($(1)_LIBNAME)$$(LIB_SUFFIX)
        else
        $(1)DEP = $$(BASE_LIBDIR)/$$(STLIB_PREFIX)$$($(1)_LIBNAME)$$(STLIB_SUFFIX)
        endif
        endef
       
        $(foreach lib,$(libs),$(eval $(call lib_rules,$(firstword $(subst :, ,$(lib))),$(lastword $(subst :, ,$(lib))))))

It looks as if $(1) is set okay, but $(2) is empty, so all of the
*_LIBNAME variables are being set to "grass_". You can confirm this by
using the -p switch (e.g. "make -p -C lib/form"), which will print all
of the variable definitions.

> the system is SUSE 10 with gcc 4.1, I have removed each previous
> installation of grass.

FWIW, it works for me with make 3.81 (and presumably for everyone else
who has compiled it in the last month). My first guess would be an
issue with your version of make; which version are you using?


--
Glynn Clements <[hidden email]>
_______________________________________________
grass-dev mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/grass-dev
Markus Neteler

Re: problem building grass trunk

Reply Threaded More More options
Print post
Permalink
On Tue, Oct 20, 2009 at 4:37 PM, Glynn Clements
<[hidden email]> wrote:

>
> Stefano Salvador wrote:
>
>> I'm trying to compile revision 39598 of grass trunk but I get a list
>> of undefined symbol for almost all modules, the output of make is:
>
>> if I run make in the first library with errors I get:
>
>> -lgrass_ -lgrass_ -lgrass_ -lgrass_
>
> Well, that's where it's going wrong.

Same problem on grass.osgeo.org - no more possibility to
create binaries and the online 7 manual.

> I suspect that it's related to r38871, which uses $(eval $(call ...))
> to define the *_LIBNAME, *LIB and *DEP variables:
>
>        libs = \
>                ARRAYSTATS:arraystats \
>                BASIC:basic \
>                BITMAP:bitmap \
>        ...
>
>        define lib_rules
>        $(1)_LIBNAME = grass_$(2)
>        ifneq ($(NEED_DEPS),)
>        $(1)LIB = -l$$($(1)_LIBNAME) $$($(1)DEPS)
>        else
>        $(1)LIB = -l$$($(1)_LIBNAME)
>        endif
>        ifneq ($(1),IOSTREAM)
>        $(1)DEP = $$(BASE_LIBDIR)/$$(LIB_PREFIX)$$($(1)_LIBNAME)$$(LIB_SUFFIX)
>        else
>        $(1)DEP = $$(BASE_LIBDIR)/$$(STLIB_PREFIX)$$($(1)_LIBNAME)$$(STLIB_SUFFIX)
>        endif
>        endef
>
>        $(foreach lib,$(libs),$(eval $(call lib_rules,$(firstword $(subst :, ,$(lib))),$(lastword $(subst :, ,$(lib))))))
>
> It looks as if $(1) is set okay, but $(2) is empty, so all of the
> *_LIBNAME variables are being set to "grass_".

Right.

> You can confirm this by
> using the -p switch (e.g. "make -p -C lib/form"), which will print all
> of the variable definitions.

Confirmed.


>> the system is SUSE 10 with gcc 4.1, I have removed each previous
>> installation of grass.
>
> FWIW, it works for me with make 3.81 (and presumably for everyone else
> who has compiled it in the last month). My first guess would be an
> issue with your version of make; which version are you using?

I am on Fedora 4 (so old, but so far ok) with
make -v
GNU Make 3.80

I think that this should continue to work... GRASS will be used
on many "ancient" machines.

Markus
_______________________________________________
grass-dev mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/grass-dev
Glynn Clements

Re: problem building grass trunk

Reply Threaded More More options
Print post
Permalink

Markus Neteler wrote:

> >> the system is SUSE 10 with gcc 4.1, I have removed each previous
> >> installation of grass.
> >
> > FWIW, it works for me with make 3.81 (and presumably for everyone else
> > who has compiled it in the last month). My first guess would be an
> > issue with your version of make; which version are you using?
>
> I am on Fedora 4 (so old, but so far ok) with
> make -v
> GNU Make 3.80
>
> I think that this should continue to work... GRASS will be used
> on many "ancient" machines.

3.81 was released on 1st April 2006, so it's not exactly
bleeding-edge.

Having to support 3.80 would mean that we would have to get rid of the
loop, and instead have 68 copies of:

        FOO_LIBNAME = grass_foo
        ifneq ($(NEED_DEPS),)
        FOOLIB = -l$(FOO_LIBNAME) $(FOODEPS)
        else
        FOOLIB = -l$(FOO_LIBNAME)
        endif
        FOODEP = $(BASE_LIBDIR)/$(LIB_PREFIX)$(FOO_LIBNAME)$(LIB_SUFFIX)

(one for each of the 68 libraries).

[We can't just conditionalise the definitions of the *DEPS variables,
as they're used when building shared libraries.]

It isn't an issue for 6.x, but for 7.0 I don't think that it's
unreasonable to require a version of make less than 3.5 years old.

It's not like the compiler, where the version used has some effect
upon the resulting binaries, and may be tied to the version of
binutils and/or libc. People building on ancient systems can always
install[*] make 3.81 specifically for building GRASS 7.

[*] "install" is an exaggeration; make consists of the "gmake"
executable, the (optional) "make" symlink, and the documentation. You
can just compile it then run the not-installed executable directly.

--
Glynn Clements <[hidden email]>
_______________________________________________
grass-dev mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/grass-dev
Stefano Salvador

Re: problem building grass trunk

Reply Threaded More More options
Print post
Permalink
> You can just compile it then run the not-installed executable directly.

This solution just works, I compiled everything with only an error in
r.in.wms but this is another problem.

Thanks,


Stefano
_______________________________________________
grass-dev mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/grass-dev
Markus Neteler

Re: problem building grass trunk

Reply Threaded More More options
Print post
Permalink
In reply to this post by Glynn Clements
On Wed, Oct 21, 2009 at 2:55 AM, Glynn Clements
<[hidden email]> wrote:

> Markus Neteler wrote:
>
>> >> the system is SUSE 10 with gcc 4.1, I have removed each previous
>> >> installation of grass.
>> >
>> > FWIW, it works for me with make 3.81 (and presumably for everyone else
>> > who has compiled it in the last month). My first guess would be an
>> > issue with your version of make; which version are you using?
>>
>> I am on Fedora 4 (so old, but so far ok) with
>> make -v
>> GNU Make 3.80
>>
>> I think that this should continue to work... GRASS will be used
>> on many "ancient" machines.
>
> 3.81 was released on 1st April 2006, so it's not exactly
> bleeding-edge.

Ok, that's true.

> Having to support 3.80 would mean that we would have to get rid of the
> loop, and instead have 68 copies of:
>
>        FOO_LIBNAME = grass_foo
>        ifneq ($(NEED_DEPS),)
>        FOOLIB = -l$(FOO_LIBNAME) $(FOODEPS)
>        else
>        FOOLIB = -l$(FOO_LIBNAME)
>        endif
>        FOODEP = $(BASE_LIBDIR)/$(LIB_PREFIX)$(FOO_LIBNAME)$(LIB_SUFFIX)
>
> (one for each of the 68 libraries).

Alright, you have easily convinced me now :)

> [We can't just conditionalise the definitions of the *DEPS variables,
> as they're used when building shared libraries.]
>
> It isn't an issue for 6.x, but for 7.0 I don't think that it's
> unreasonable to require a version of make less than 3.5 years old.

Suggestion: Add a test in configure for
make >= 3.81
?

Meanwhile I'll create a new make RPM for grass.osgeo.org.

Markus
_______________________________________________
grass-dev mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/grass-dev
Markus Neteler

Re: problem building grass trunk

Reply Threaded More More options
Print post
Permalink
In reply to this post by Markus Neteler
On Tue, Oct 20, 2009 at 9:47 PM, Markus Neteler <[hidden email]> wrote:

> On Tue, Oct 20, 2009 at 4:37 PM, Glynn Clements
> <[hidden email]> wrote:
>>
>> Stefano Salvador wrote:
>>
>>> I'm trying to compile revision 39598 of grass trunk but I get a list
>>> of undefined symbol for almost all modules, the output of make is:
>>
>>> if I run make in the first library with errors I get:
>>
>>> -lgrass_ -lgrass_ -lgrass_ -lgrass_
>>
>> Well, that's where it's going wrong.
>
> Same problem on grass.osgeo.org - no more possibility to
> create binaries and the online 7 manual.

For the record: After updating make to 3.81 the creation
of generic GRASS 7 Linux binaries and HTML manual is
possible again on a weekly base. I have triggered the
snapshot update, it has completed now:

http://grass.osgeo.org/grass70/manuals/html70_user/
http://grass.osgeo.org/grass70/binary/linux/snapshot/

Markus
_______________________________________________
grass-dev mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/grass-dev
Glynn Clements

Re: problem building grass trunk

Reply Threaded More More options
Print post
Permalink
In reply to this post by Markus Neteler

Markus Neteler wrote:

> > [We can't just conditionalise the definitions of the *DEPS variables,
> > as they're used when building shared libraries.]
> >
> > It isn't an issue for 6.x, but for 7.0 I don't think that it's
> > unreasonable to require a version of make less than 3.5 years old.
>
> Suggestion: Add a test in configure for
> make >= 3.81
> ?

We don't know which program will be used to actually build the source.
The "make" found in the path may be some ancient version or the
vendor's (non-GNU) make, but that doesn't matter if the user is going
to be using e.g. /path/to/gmake-3.81 to actually build GRASS.

--
Glynn Clements <[hidden email]>
_______________________________________________
grass-dev mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/grass-dev