Linking

Linking

[Viswesh S]

[-- Attachment #1: Type: text/plain, Size: 3708 bytes --]

Hi,
I am quite new to grub2 anf I find some issue in make of grub2
I modify the hello module by adding a new file a.c, with a function test() in it.
I call the function test from hello entry point - grub_cmd_hello()
When I do a make, I get the error that 
test in hello is not defined
make: *** [moddep.lst] Error 1

I have modified the conf/common.mk accordingly as shown below.
# For hello.mod.
hello_mod_SOURCES = hello/hello.c hello/a.c
CLEANFILES += hello.mod mod-hello.o mod-hello.c pre-hello.o hello_mod-hello_hello.o hello_mod-hello_a.o und-hello.lst
ifneq ($(hello_mod_EXPORTS),no)
CLEANFILES += def-hello.lst
DEFSYMFILES += def-hello.lst
endif
MOSTLYCLEANFILES += hello_mod-hello_hello.d  hello_mod-hello_a.d
UNDSYMFILES += und-hello.lst
hello.mod: pre-hello.o mod-hello.o
        -rm -f $@
        $(TARGET_CC) $(hello_mod_LDFLAGS) $(TARGET_LDFLAGS) -Wl,-r,-d -o $@ $^
        $(STRIP) --strip-unneeded -K grub_mod_init -K grub_mod_fini -R .note -R .comment $@
pre-hello.o: $(hello_mod_DEPENDENCIES) hello_mod-hello_hello.o hello_mod-hello_a.o
        -rm -f $@
        $(TARGET_CC) $(hello_mod_LDFLAGS) $(TARGET_LDFLAGS) -Wl,-r,-d -o $@ hello_mod-hello_hello.o
mod-hello.o: mod-hello.c
        $(TARGET_CC) $(TARGET_CPPFLAGS) $(TARGET_CFLAGS) $(hello_mod_CFLAGS) -c -o $@ $<
mod-hello.c: moddep.lst genmodsrc.sh
        sh $(srcdir)/genmodsrc.sh 'hello' $< > $@ || (rm -f $@; exit 1)
ifneq ($(hello_mod_EXPORTS),no)
def-hello.lst: pre-hello.o
        $(NM) -g --defined-only -P -p $< | sed 's/^\([^ ]*\).*/\1 hello/' > $@
endif
und-hello.lst: pre-hello.o
        echo 'hello' > $@
        $(NM) -u -P -p $< | cut -f1 -d' ' >> $@
hello_mod-hello_hello.o: hello/hello.c $(hello/hello.c_DEPENDENCIES)
        $(TARGET_CC) -Ihello -I$(srcdir)/hello $(TARGET_CPPFLAGS)  $(TARGET_CFLAGS) $(hello_mod_CFLAGS) -MD -c -o $@ $<
-include hello_mod-hello_hello.d
hello_mod-hello_a.o: hello/a.c $(hello/a.c_DEPENDENCIES)
        $(TARGET_CC) -Ihello -I$(srcdir)/hello $(TARGET_CPPFLAGS)  $(TARGET_CFLAGS) $(hello_mod_CFLAGS) -MD -c -o $@ $<
-include hello_mod-hello_a.d

CLEANFILES += cmd-hello_mod-hello_hello.lst fs-hello_mod-hello_hello.lst
COMMANDFILES += cmd-hello_mod-hello_hello.lst
FSFILES += fs-hello_mod-hello_hello.lst
cmd-hello_mod-hello_hello.lst: hello/hello.c $(hello/hello.c_DEPENDENCIES) gencmdlist.sh
        set -e;           $(TARGET_CC) -Ihello -I$(srcdir)/hello $(TARGET_CPPFLAGS) $(TARGET_CFLAGS) $(hello_mod_CFLAGS) -E $<    | sh $(srcdir)/gencmdlist.sh hello > $@ || (rm -f $@; exit 1)
cmd-hello_mod-hello_a.lst: hello/a.c $(hello/a.c_DEPENDENCIES) gencmdlist.sh
        set -e;           $(TARGET_CC) -Ihello -I$(srcdir)/hello $(TARGET_CPPFLAGS) $(TARGET_CFLAGS) $(hello_mod_CFLAGS) -E $<    | sh $(srcdir)/gencmdlist.sh hello > $@ || (rm -f $@; exit 1)

fs-hello_mod-hello_hello.lst: hello/hello.c $(hello/hello.c_DEPENDENCIES) genfslist.sh
        set -e;           $(TARGET_CC) -Ihello -I$(srcdir)/hello $(TARGET_CPPFLAGS) $(TARGET_CFLAGS) $(hello_mod_CFLAGS) -E $<    | sh $(srcdir)/genfslist.sh hello > $@ || (rm -f $@; exit 1)
fs-hello_mod-hello_a.lst: hello/a.c $(hello/a.c_DEPENDENCIES) genfslist.sh
        set -e;           $(TARGET_CC) -Ihello -I$(srcdir)/hello $(TARGET_CPPFLAGS) $(TARGET_CFLAGS) $(hello_mod_CFLAGS) -E $<    | sh $(srcdir)/genfslist.sh hello > $@ || (rm -f $@; exit 1)

Could anyone let me know whether I need to do anything more.
Viswesh


      Explore your hobbies and interests. Go to http://in.promos.yahoo.com/groups/

[-- Attachment #2: Type: text/html, Size: 6046 bytes --]

Re: Linking

[Pavel Roskin]

Quoting Viswesh S <viswesh_vichu@yahoo.com>:

> I have modified the conf/common.mk accordingly as shown below.

It's a generated file.  Please modify conf/common.rmk instead and run  
autogen.sh.

-- 
Regards,
Pavel Roskin

Remove conf/*.mk from svn (was: Re: Linking)

[Colin D Bennett]

On Thu, 24 Jul 2008 22:17:06 -0700 (PDT)
Viswesh S <viswesh_vichu@yahoo.com> wrote:

> I have modified the conf/common.mk accordingly as shown below.

GRUB developers,

I think we should remove conf/*.mk from the Subversion repository.  If
people are going to be developing on GRUB and checking out svn
branches, then I think it's fine to require them to have Ruby.  For
released tarballs that we expect non-developers to use, we just need to
generate the *.mk files and include them in the tarball.

What is the benefit of having conf/*.mk files in svn?  They cause lots
of merge conflicts: sure, the conflicts are easy to resolve by simply
choosing to take one of the revisions, but then that merge really has
not meaning, since it won't be in sync with your .rmk file until it's
once again regenerated and checked in.

Removing the autogenerated .mk files would also eliminate problems new
developers like Viswesh and I have encountered -- we won't be tempted
to modify a non-versioned file like this.

Regards,
Colin

Re: Remove conf/*.mk from svn

[Christian Franke]

Colin D Bennett wrote:
> On Thu, 24 Jul 2008 22:17:06 -0700 (PDT)
> Viswesh S <...> wrote:
>
>   
>> I have modified the conf/common.mk accordingly as shown below.
>>     
>
> GRUB developers,
>
> I think we should remove conf/*.mk from the Subversion repository.  If
> people are going to be developing on GRUB and checking out svn
> branches, then I think it's fine to require them to have Ruby.  For
> released tarballs that we expect non-developers to use, we just need to
> generate the *.mk files and include them in the tarball.
>
> What is the benefit of having conf/*.mk files in svn?  They cause lots
> of merge conflicts: sure, the conflicts are easy to resolve by simply
> choosing to take one of the revisions, but then that merge really has
> not meaning, since it won't be in sync with your .rmk file until it's
> once again regenerated and checked in.
>
> Removing the autogenerated .mk files would also eliminate problems new
> developers like Viswesh and I have encountered -- we won't be tempted
> to modify a non-versioned file like this.
>
>   

I agree, the files generated by ./autogen.sh should be included in 
tarball, but not in the repo.
Additional prerequisites (autoconf, ruby) for builds from svn are IMO OK.

In my local grub2 git repo, these files are excluded:
configure
config.h.in
stamp-h.in
conf/*.mk

BTW: autogen.sh should "touch stamp-h.in" to be consistent with the 
Makefile rule for config.h.in.

Christian

Re: Remove conf/*.mk from svn

[Pavel Roskin]

On Fri, 2008-07-25 at 20:41 +0200, Christian Franke wrote:

> I agree, the files generated by ./autogen.sh should be included in 
> tarball, but not in the repo.
> Additional prerequisites (autoconf, ruby) for builds from svn are IMO OK.

I agree.

At least we should put a message into *.mk files that would make it
clear that they are generated.

> BTW: autogen.sh should "touch stamp-h.in" to be consistent with the 
> Makefile rule for config.h.in.

What difference would it make?

-- 
Regards,
Pavel Roskin

Re: Remove conf/*.mk from svn

[Christian Franke]

Pavel Roskin wrote:
> On Fri, 2008-07-25 at 20:41 +0200, Christian Franke wrote:
>
>   
>> I agree, the files generated by ./autogen.sh should be included in 
>> tarball, but not in the repo.
>> Additional prerequisites (autoconf, ruby) for builds from svn are IMO OK.
>>     
>
> I agree.
>
> At least we should put a message into *.mk files that would make it
> clear that they are generated.
>
>   

Yes.

For a release tarball, It IMO also makes sense to include 
util/parser.tab.c. It is platform-independent and rarely changed. This 
would remove bison from the list of prerequisites.


>> BTW: autogen.sh should "touch stamp-h.in" to be consistent with the 
>> Makefile rule for config.h.in.
>>     
>
> What difference would it make?
>
>   


$ patch < patch_changing_configure.ac_or_aclocal.m4

$ ./autogen.sh # runs autoheader etc.

$ ./configure

$ make # re-runs autoheader because stamp-h.in was not updated

Christian

Re: Remove conf/*.mk from svn

[Pavel Roskin]

On Mon, 2008-07-28 at 00:28 +0200, Christian Franke wrote:
> Pavel Roskin wrote:

> > At least we should put a message into *.mk files that would make it
> > clear that they are generated.
> >
> >   
> 
> Yes.

Done.

> For a release tarball, It IMO also makes sense to include 
> util/parser.tab.c. It is platform-independent and rarely changed. This 
> would remove bison from the list of prerequisites.

It seems to me that gendistlist.sh should be rewritten from scratch.
It's completely outdated.  It should sort its output in C locale for
consistency.  It should be smart enough not to pick *.sh files for which
*.sh.in exists.  It should include documentation and all C files barred
known exceptions (symlist.c, grub_*_init.c, mod-*.c)

Once gendistlist.sh is good enough to allow "make distcheck" to pass,
then we can do little adjustments and decide what should or should not
be in the distribution.

> >> BTW: autogen.sh should "touch stamp-h.in" to be consistent with
> the 
> >> Makefile rule for config.h.in.
> >>     
> >
> > What difference would it make?
> >
> >   
> 
> 
> $ patch < patch_changing_configure.ac_or_aclocal.m4
> 
> $ ./autogen.sh # runs autoheader etc.
> 
> $ ./configure
> 
> $ make # re-runs autoheader because stamp-h.in was not updated

Thanks.  Fixed.

-- 
Regards,
Pavel Roskin

Re: Remove conf/*.mk from svn

[Marco Gerards]

Hi,

Christian Franke <Christian.Franke@t-online.de> writes:

> For a release tarball, It IMO also makes sense to include
> util/parser.tab.c. It is platform-independent and rarely changed. This
> would remove bison from the list of prerequisites.

Fine for me.

--
Marco

Re: Remove conf/*.mk from svn (was: Re: Linking)

[Robert Millan]

On Fri, Jul 25, 2008 at 08:18:27AM -0700, Colin D Bennett wrote:
> On Thu, 24 Jul 2008 22:17:06 -0700 (PDT)
> Viswesh S <viswesh_vichu@yahoo.com> wrote:
> 
> > I have modified the conf/common.mk accordingly as shown below.
> 
> GRUB developers,
> 
> I think we should remove conf/*.mk from the Subversion repository.  If
> people are going to be developing on GRUB and checking out svn
> branches, then I think it's fine to require them to have Ruby.  For
> released tarballs that we expect non-developers to use, we just need to
> generate the *.mk files and include them in the tarball.
> 
> What is the benefit of having conf/*.mk files in svn?  They cause lots
> of merge conflicts: sure, the conflicts are easy to resolve by simply
> choosing to take one of the revisions, but then that merge really has
> not meaning, since it won't be in sync with your .rmk file until it's
> once again regenerated and checked in.
> 
> Removing the autogenerated .mk files would also eliminate problems new
> developers like Viswesh and I have encountered -- we won't be tempted
> to modify a non-versioned file like this.

I'd check with Okuji first.  IIRC he didn't like that idea.

-- 
Robert Millan

<GPLv2> I know my rights; I want my phone call!
<DRM> What good is a phone call… if you are unable to speak?
(as seen on /.)

Re: Remove conf/*.mk from svn (was: Re: Linking)

[Yoshinori K. Okuji]

On Friday 25 July 2008 22:43:10 Robert Millan wrote:
> On Fri, Jul 25, 2008 at 08:18:27AM -0700, Colin D Bennett wrote:
> > On Thu, 24 Jul 2008 22:17:06 -0700 (PDT)
> >
> > Viswesh S <viswesh_vichu@yahoo.com> wrote:
> > > I have modified the conf/common.mk accordingly as shown below.
> >
> > GRUB developers,
> >
> > I think we should remove conf/*.mk from the Subversion repository.  If
> > people are going to be developing on GRUB and checking out svn
> > branches, then I think it's fine to require them to have Ruby.  For
> > released tarballs that we expect non-developers to use, we just need to
> > generate the *.mk files and include them in the tarball.
> >
> > What is the benefit of having conf/*.mk files in svn?  They cause lots
> > of merge conflicts: sure, the conflicts are easy to resolve by simply
> > choosing to take one of the revisions, but then that merge really has
> > not meaning, since it won't be in sync with your .rmk file until it's
> > once again regenerated and checked in.
> >
> > Removing the autogenerated .mk files would also eliminate problems new
> > developers like Viswesh and I have encountered -- we won't be tempted
> > to modify a non-versioned file like this.
>
> I'd check with Okuji first.  IIRC he didn't like that idea.

I don't like. You can check the archive for my comments on this.

Regards,
Okuji

Re: Remove conf/*.mk from svn

[Marco Gerards]

Hi,

Colin D Bennett <colin@gibibit.com> writes:

[...]

> I think we should remove conf/*.mk from the Subversion repository.  If
> people are going to be developing on GRUB and checking out svn
> branches, then I think it's fine to require them to have Ruby.  For
> released tarballs that we expect non-developers to use, we just need to
> generate the *.mk files and include them in the tarball.

I do not have problems with this.  Besides this, it will stop people
from sending in patches with .mk changes in it :-)

--
Marco

Re: Remove conf/*.mk from svn

[Vesa Jääskeläinen]

Marco Gerards wrote:
> Colin D Bennett <colin@gibibit.com> writes:
>> I think we should remove conf/*.mk from the Subversion repository.  If
>> people are going to be developing on GRUB and checking out svn
>> branches, then I think it's fine to require them to have Ruby.  For
>> released tarballs that we expect non-developers to use, we just need to
>> generate the *.mk files and include them in the tarball.
> 
> I do not have problems with this.  Besides this, it will stop people
> from sending in patches with .mk changes in it :-)

I think Okuji's objection is based on fact that it makes it harder for 
people to compile from sources. Now what if we would generate those 
files when making a release? Of course this should be enabled to 
script/makefile to make it automatically so it is not forgotten ;)

Thanks,
Vesa Jääskeläinen

Re: Remove conf/*.mk from svn

[Marco Gerards]

Vesa Jääskeläinen <chaac@nic.fi> writes:

> Marco Gerards wrote:
>> Colin D Bennett <colin@gibibit.com> writes:
>>> I think we should remove conf/*.mk from the Subversion repository.  If
>>> people are going to be developing on GRUB and checking out svn
>>> branches, then I think it's fine to require them to have Ruby.  For
>>> released tarballs that we expect non-developers to use, we just need to
>>> generate the *.mk files and include them in the tarball.
>>
>> I do not have problems with this.  Besides this, it will stop people
>> from sending in patches with .mk changes in it :-)
>
> I think Okuji's objection is based on fact that it makes it harder for
> people to compile from sources. Now what if we would generate those
> files when making a release? Of course this should be enabled to
> script/makefile to make it automatically so it is not forgotten ;)

Right.  Just to be clear, personally I didn't have these objections
but Okuji has.

Actually, since ruby is required to generate these files, I guess we
can better keep the .mk files.

--
Marco

Seeking for the start

[administrador02032]

Hi:

I am new. You know. I have around two months studying grub. But I feel 
myself lost. I understand the structure and the language. But I do not
have a start ( except boot's module ). What I want to know in general
terms is :

General characteristics of the kernel. (It was maded in order to do what?)
General characteristics out of every module.
I want knowing if exists some engineering design associated with grub and
his development.

I hope not to seem so lost as actually I seat  myself.

Thanks

Alex

Re: Remove conf/*.mk from svn

[Felix Zielcke]

Am Dienstag, den 05.08.2008, 17:48 +0200 schrieb Marco Gerards:

> 
> Actually, since ruby is required to generate these files, I guess we
> can better keep the .mk files.
> 

Just a little note from me:

The Debian package build depends already on ruby so this won't be a
problem for all Debian guys and especially not for Robert or me.

On Debian/Ubuntu you can just use 'apt-get build-dep grub2' and it
installs every package for you which you need to build grub2 so ruby
will be always needed/installed for the Debian package.

But well Debian isn't the only distribution and I don't know how others
deal with grub2 :)

Re: Remove conf/*.mk from svn

[Javier Martín]

[-- Attachment #1: Type: text/plain, Size: 1348 bytes --]

El mar, 05-08-2008 a las 17:48 +0200, Marco Gerards escribió:
> Vesa Jääskeläinen <chaac@nic.fi> writes:
> 
> > Marco Gerards wrote:
> >> Colin D Bennett <colin@gibibit.com> writes:
> >>> I think we should remove conf/*.mk from the Subversion repository.  If
> >>> people are going to be developing on GRUB and checking out svn
> >>> branches, then I think it's fine to require them to have Ruby.  For
> >>> released tarballs that we expect non-developers to use, we just need to
> >>> generate the *.mk files and include them in the tarball.
> >>
> >> I do not have problems with this.  Besides this, it will stop people
> >> from sending in patches with .mk changes in it :-)
> >
> > I think Okuji's objection is based on fact that it makes it harder for
> > people to compile from sources. Now what if we would generate those
> > files when making a release? Of course this should be enabled to
> > script/makefile to make it automatically so it is not forgotten ;)
> 
> Right.  Just to be clear, personally I didn't have these objections
> but Okuji has.
> 
> Actually, since ruby is required to generate these files, I guess we
> can better keep the .mk files.
Why not rewrite genmk.rb in a more common language (i.e. with an
interpreter more commonly found in stock GNU installs) like Python or
Perl?

Habbit

[-- Attachment #2: Esta parte del mensaje está firmada digitalmente --]
[-- Type: application/pgp-signature, Size: 827 bytes --]

Re: Remove conf/*.mk from svn

[Colin D Bennett]

On Tue, 05 Aug 2008 20:41:53 +0200
Javier Martín <lordhabbit@gmail.com> wrote:

> El mar, 05-08-2008 a las 17:48 +0200, Marco Gerards escribió:
> > Vesa Jääskeläinen <chaac@nic.fi> writes:
> > 
> > > Marco Gerards wrote:
> > >> Colin D Bennett <colin@gibibit.com> writes:
> > >>> I think we should remove conf/*.mk from the Subversion
> > >>> repository.  If people are going to be developing on GRUB and
> > >>> checking out svn branches, then I think it's fine to require
> > >>> them to have Ruby.  For released tarballs that we expect
> > >>> non-developers to use, we just need to generate the *.mk files
> > >>> and include them in the tarball.
> > >>
> > >> I do not have problems with this.  Besides this, it will stop
> > >> people from sending in patches with .mk changes in it :-)
> > >
> > > I think Okuji's objection is based on fact that it makes it
> > > harder for people to compile from sources. Now what if we would
> > > generate those files when making a release? Of course this should
> > > be enabled to script/makefile to make it automatically so it is
> > > not forgotten ;)
> > 
> > Right.  Just to be clear, personally I didn't have these objections
> > but Okuji has.
> > 
> > Actually, since ruby is required to generate these files, I guess we
> > can better keep the .mk files.
> Why not rewrite genmk.rb in a more common language (i.e. with an
> interpreter more commonly found in stock GNU installs) like Python or
> Perl?

Fine with me.  It shouldn't be too hard for someone who understands it.

Based on the discussions following my initial suggestion, it sounds
like it is considered too much work for people compiling from a svn
checkout to install Ruby?

Did I emphasize enough that released tarballs or any sort of archived
snapshot should be generated *with* the .mk files?  I am concerned only
with the files under version control -- the point being that files
generated from often-modified files (such as the ``conf/*.rmk`` which
are often modified) have no business being under version control.  I
think that this is even more important than lesser modified files such
as the configure script, etc., since fewer developers have to touch
that.

Regards,
Colin