On Sat, Mar 05, 2005 at 11:36:23AM -0500, Kai Germaschewski wrote:
> However, I spoke too soon. There actually is a legitimate use for
> EXPORT_SYMBOL() in a lib-y object, e.g. lib/dump_stack.c. This provides a
> default implementation for dump_stack(). Most archs provide their own
>
On Sat, Mar 05, 2005 at 10:19:23AM -0500, Kai Germaschewski wrote:
> On Sat, 5 Mar 2005, Adrian Bunk wrote:
>
> > And this can break as soon as the "unused" object files contains
> > EXPORT_SYMBOL's.
> >
> > Is it really worth it doing it in this non-intuitive way?
>
> I don't think it
> That's usually solved through #define's (see e.g. lib/extable.c).
Well, you can obviously solve pretty much everything with #define's, but
it's usually also the ugliest solution.
>From my point of view, the preferences for solving issues like the
extable.c one are:
o Do it automatically.
On Sat, Mar 05, 2005 at 11:36:23AM -0500, Kai Germaschewski wrote:
> On Sat, 5 Mar 2005, Adrian Bunk wrote:
>
> > This warning sounds like a good plan (but it won't let many objects stay
> > inside lib-y).
>
> The patch is simple (except that the warning it throws looks rather ugly),
> see
On Sat, 5 Mar 2005, Adrian Bunk wrote:
> This warning sounds like a good plan (but it won't let many objects stay
> inside lib-y).
The patch is simple (except that the warning it throws looks rather ugly),
see appended.
However, I spoke too soon. There actually is a legitimate use for
On Sat, Mar 05, 2005 at 10:19:23AM -0500, Kai Germaschewski wrote:
> On Sat, 5 Mar 2005, Adrian Bunk wrote:
>
> > And this can break as soon as the "unused" object files contains
> > EXPORT_SYMBOL's.
> >
> > Is it really worth it doing it in this non-intuitive way?
>
> I don't think it
On Sat, 5 Mar 2005, Adrian Bunk wrote:
> And this can break as soon as the "unused" object files contains
> EXPORT_SYMBOL's.
>
> Is it really worth it doing it in this non-intuitive way?
I don't think it non-intuitive, it's how libraries work. However, as you
say, it is broken for files
On Sat, Mar 05, 2005 at 12:09:29AM -0500, Kai Germaschewski wrote:
> On Fri, 4 Mar 2005, Adrian Bunk wrote:
>
> > > [...] So ld looks into the lib .a archive, determines that none of
> > > the symbols in that object file are needed to resolve a reference and
> > > drops the entire .o file.
>
>
On Sat, Mar 05, 2005 at 12:09:29AM -0500, Kai Germaschewski wrote:
On Fri, 4 Mar 2005, Adrian Bunk wrote:
[...] So ld looks into the lib .a archive, determines that none of
the symbols in that object file are needed to resolve a reference and
drops the entire .o file.
Silly
On Sat, 5 Mar 2005, Adrian Bunk wrote:
And this can break as soon as the unused object files contains
EXPORT_SYMBOL's.
Is it really worth it doing it in this non-intuitive way?
I don't think it non-intuitive, it's how libraries work. However, as you
say, it is broken for files containing
On Sat, Mar 05, 2005 at 10:19:23AM -0500, Kai Germaschewski wrote:
On Sat, 5 Mar 2005, Adrian Bunk wrote:
And this can break as soon as the unused object files contains
EXPORT_SYMBOL's.
Is it really worth it doing it in this non-intuitive way?
I don't think it non-intuitive, it's
On Sat, 5 Mar 2005, Adrian Bunk wrote:
This warning sounds like a good plan (but it won't let many objects stay
inside lib-y).
The patch is simple (except that the warning it throws looks rather ugly),
see appended.
However, I spoke too soon. There actually is a legitimate use for
On Sat, Mar 05, 2005 at 11:36:23AM -0500, Kai Germaschewski wrote:
On Sat, 5 Mar 2005, Adrian Bunk wrote:
This warning sounds like a good plan (but it won't let many objects stay
inside lib-y).
The patch is simple (except that the warning it throws looks rather ugly),
see appended.
That's usually solved through #define's (see e.g. lib/extable.c).
Well, you can obviously solve pretty much everything with #define's, but
it's usually also the ugliest solution.
From my point of view, the preferences for solving issues like the
extable.c one are:
o Do it automatically. If
On Sat, Mar 05, 2005 at 10:19:23AM -0500, Kai Germaschewski wrote:
On Sat, 5 Mar 2005, Adrian Bunk wrote:
And this can break as soon as the unused object files contains
EXPORT_SYMBOL's.
Is it really worth it doing it in this non-intuitive way?
I don't think it non-intuitive, it's
On Sat, Mar 05, 2005 at 11:36:23AM -0500, Kai Germaschewski wrote:
However, I spoke too soon. There actually is a legitimate use for
EXPORT_SYMBOL() in a lib-y object, e.g. lib/dump_stack.c. This provides a
default implementation for dump_stack(). Most archs provide their own
implementation
On Fri, 4 Mar 2005, Adrian Bunk wrote:
> > [...] So ld looks into the lib .a archive, determines that none of
> > the symbols in that object file are needed to resolve a reference and
> > drops the entire .o file.
> Silly question:
> What's the advantage of lib-y compared to obj-y?
Basically
On Fri, Mar 04, 2005 at 02:11:13PM -0500, Kai Germaschewski wrote:
> On Fri, 4 Mar 2005, Rusty Russell wrote:
>
> > On Wed, 2005-03-02 at 15:00 +0100, Adrian Bunk wrote:
> > > Why doesn't an EXPORT_SYMBOL create a reference?
> >
> > It does: EXPORT_SYMBOL(x) drops the address of "x", including
>
On Fri, Mar 04, 2005 at 07:56:38PM +0100, Adrian Bunk wrote:
> On Fri, Mar 04, 2005 at 09:23:17PM +1100, Rusty Russell wrote:
> > On Wed, 2005-03-02 at 15:00 +0100, Adrian Bunk wrote:
> > > Why doesn't an EXPORT_SYMBOL create a reference?
> >
> > It does: EXPORT_SYMBOL(x) drops the address of
On Fri, 4 Mar 2005, Rusty Russell wrote:
> On Wed, 2005-03-02 at 15:00 +0100, Adrian Bunk wrote:
> > Why doesn't an EXPORT_SYMBOL create a reference?
>
> It does: EXPORT_SYMBOL(x) drops the address of "x", including
> __attribute_used__, in the __ksymtab section.
Well, the problem is that this
On Fri, Mar 04, 2005 at 09:23:17PM +1100, Rusty Russell wrote:
> On Wed, 2005-03-02 at 15:00 +0100, Adrian Bunk wrote:
> > Why doesn't an EXPORT_SYMBOL create a reference?
>
> It does: EXPORT_SYMBOL(x) drops the address of "x", including
> __attribute_used__, in the __ksymtab section.
>
>
On Wed, 2005-03-02 at 15:00 +0100, Adrian Bunk wrote:
> Why doesn't an EXPORT_SYMBOL create a reference?
It does: EXPORT_SYMBOL(x) drops the address of "x", including
__attribute_used__, in the __ksymtab section.
However, if CONFIG_MODULES=n, it does nothing: perhaps that is what you
are seeing.
On Wed, 2005-03-02 at 12:23 -0500, [EMAIL PROTECTED] wrote:
> static int __init init_hermes(void)
> {
> return 0;
> }
>
> static void __exit exit_hermes(void)
> {
> }
>
> module_init(init_hermes);
> module_exit(exit_hermes);
>
> That's it. As far as I can tell, gcc 4.0 semi-correctly
On Wed, 2005-03-02 at 12:23 -0500, [EMAIL PROTECTED] wrote:
static int __init init_hermes(void)
{
return 0;
}
static void __exit exit_hermes(void)
{
}
module_init(init_hermes);
module_exit(exit_hermes);
That's it. As far as I can tell, gcc 4.0 semi-correctly determined
On Wed, 2005-03-02 at 15:00 +0100, Adrian Bunk wrote:
Why doesn't an EXPORT_SYMBOL create a reference?
It does: EXPORT_SYMBOL(x) drops the address of x, including
__attribute_used__, in the __ksymtab section.
However, if CONFIG_MODULES=n, it does nothing: perhaps that is what you
are seeing.
On Fri, Mar 04, 2005 at 09:23:17PM +1100, Rusty Russell wrote:
On Wed, 2005-03-02 at 15:00 +0100, Adrian Bunk wrote:
Why doesn't an EXPORT_SYMBOL create a reference?
It does: EXPORT_SYMBOL(x) drops the address of x, including
__attribute_used__, in the __ksymtab section.
However, if
On Fri, 4 Mar 2005, Rusty Russell wrote:
On Wed, 2005-03-02 at 15:00 +0100, Adrian Bunk wrote:
Why doesn't an EXPORT_SYMBOL create a reference?
It does: EXPORT_SYMBOL(x) drops the address of x, including
__attribute_used__, in the __ksymtab section.
Well, the problem is that this is still
On Fri, Mar 04, 2005 at 07:56:38PM +0100, Adrian Bunk wrote:
On Fri, Mar 04, 2005 at 09:23:17PM +1100, Rusty Russell wrote:
On Wed, 2005-03-02 at 15:00 +0100, Adrian Bunk wrote:
Why doesn't an EXPORT_SYMBOL create a reference?
It does: EXPORT_SYMBOL(x) drops the address of x, including
On Fri, Mar 04, 2005 at 02:11:13PM -0500, Kai Germaschewski wrote:
On Fri, 4 Mar 2005, Rusty Russell wrote:
On Wed, 2005-03-02 at 15:00 +0100, Adrian Bunk wrote:
Why doesn't an EXPORT_SYMBOL create a reference?
It does: EXPORT_SYMBOL(x) drops the address of x, including
On Fri, 4 Mar 2005, Adrian Bunk wrote:
[...] So ld looks into the lib .a archive, determines that none of
the symbols in that object file are needed to resolve a reference and
drops the entire .o file.
Silly question:
What's the advantage of lib-y compared to obj-y?
Basically exactly
On Wed, Mar 02, 2005 at 08:28:46AM -0800, Andrew Morton wrote:
> Adrian Bunk <[EMAIL PROTECTED]> wrote:
> >
> > > In lib/Makefile, remove parser.o from the lib-y: rule and add
> > >
> > > obj-y+= parser.o
> >
> > This I didn't find.
> >
> > Is it really the intention to silently omit
On Wed, Mar 02, 2005 at 08:28:46AM -0800, Andrew Morton wrote:
Adrian Bunk [EMAIL PROTECTED] wrote:
In lib/Makefile, remove parser.o from the lib-y: rule and add
obj-y+= parser.o
This I didn't find.
Is it really the intention to silently omit objects that are not
[EMAIL PROTECTED] wrote:
>
> (hermes.c)
> static int __init init_hermes(void)
> {
> return 0;
> }
>
> static void __exit exit_hermes(void)
> {
> }
>
> module_init(init_hermes);
> module_exit(exit_hermes);
>
> That's it. As far as I can tell, gcc 4.0 semi-correctly determined
On Wed, 02 Mar 2005 08:28:46 PST, Andrew Morton said:
> Adrian Bunk <[EMAIL PROTECTED]> wrote:
> > Why doesn't an EXPORT_SYMBOL create a reference?
>
> It does, but that reference is within the same compilation unit as the
> definition. IOW: there are no references to the symbol which are
Adrian Bunk <[EMAIL PROTECTED]> wrote:
>
> > In lib/Makefile, remove parser.o from the lib-y: rule and add
> >
> > obj-y += parser.o
>
> This I didn't find.
>
> Is it really the intention to silently omit objects that are not
> referenced or could this be changed?
In some cases,
Oops, should have read all the messages before posting!
I'll try the fix you said, I knew it'd be something like that.
It's attached.
BTW, is attaching things like this the preferred method?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
On Wed, Mar 02, 2005 at 03:24:14AM -0800, Andrew Morton wrote:
> Vincent Vanackere <[EMAIL PROTECTED]> wrote:
> >
> > I have the exact same problem.
> > .config is attached
> > (this may be a debian specific problem as I'm running debian too)
>
> OK, there are no vmlinux references to
Works fine for me now, thanks !
Vincent
On Wed, 2 Mar 2005 03:24:14 -0800, Andrew Morton <[EMAIL PROTECTED]> wrote:
> OK, there are no vmlinux references to lib/parser.o's symbols. So it isn't
> getting linked in.
>
> In lib/Makefile, remove parser.o from the lib-y: rule and add
>
> obj-y
Vincent Vanackere <[EMAIL PROTECTED]> wrote:
>
> I have the exact same problem.
> .config is attached
> (this may be a debian specific problem as I'm running debian too)
OK, there are no vmlinux references to lib/parser.o's symbols. So it isn't
getting linked in.
In lib/Makefile, remove
I have the exact same problem.
.config is attached
(this may be a debian specific problem as I'm running debian too)
Regards,
Vincent
On Wed, 2 Mar 2005 01:23:31 -0800, Andrew Morton <[EMAIL PROTECTED]> wrote:
> Keenan Pepper <[EMAIL PROTECTED]> wrote:
> >
> > I j
Keenan Pepper <[EMAIL PROTECTED]> wrote:
>
> I just compiled 2.6.11-rc5-mm1 and got undefined
> symbols "match_int", "match_octal", "match_token", and "match_strdup" in
> several modules.
Please send me your .config file.
-
To un
Keenan Pepper [EMAIL PROTECTED] wrote:
I just compiled 2.6.11-rc5-mm1 and got undefined
symbols match_int, match_octal, match_token, and match_strdup in
several modules.
Please send me your .config file.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body
I have the exact same problem.
.config is attached
(this may be a debian specific problem as I'm running debian too)
Regards,
Vincent
On Wed, 2 Mar 2005 01:23:31 -0800, Andrew Morton [EMAIL PROTECTED] wrote:
Keenan Pepper [EMAIL PROTECTED] wrote:
I just compiled 2.6.11-rc5-mm1 and got
Vincent Vanackere [EMAIL PROTECTED] wrote:
I have the exact same problem.
.config is attached
(this may be a debian specific problem as I'm running debian too)
OK, there are no vmlinux references to lib/parser.o's symbols. So it isn't
getting linked in.
In lib/Makefile, remove parser.o
Works fine for me now, thanks !
Vincent
On Wed, 2 Mar 2005 03:24:14 -0800, Andrew Morton [EMAIL PROTECTED] wrote:
OK, there are no vmlinux references to lib/parser.o's symbols. So it isn't
getting linked in.
In lib/Makefile, remove parser.o from the lib-y: rule and add
obj-y +=
On Wed, Mar 02, 2005 at 03:24:14AM -0800, Andrew Morton wrote:
Vincent Vanackere [EMAIL PROTECTED] wrote:
I have the exact same problem.
.config is attached
(this may be a debian specific problem as I'm running debian too)
OK, there are no vmlinux references to lib/parser.o's
Oops, should have read all the messages before posting!
I'll try the fix you said, I knew it'd be something like that.
It's attached.
BTW, is attaching things like this the preferred method?
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL
Adrian Bunk [EMAIL PROTECTED] wrote:
In lib/Makefile, remove parser.o from the lib-y: rule and add
obj-y += parser.o
This I didn't find.
Is it really the intention to silently omit objects that are not
referenced or could this be changed?
In some cases, yes, it it
On Wed, 02 Mar 2005 08:28:46 PST, Andrew Morton said:
Adrian Bunk [EMAIL PROTECTED] wrote:
Why doesn't an EXPORT_SYMBOL create a reference?
It does, but that reference is within the same compilation unit as the
definition. IOW: there are no references to the symbol which are external
to
[EMAIL PROTECTED] wrote:
(hermes.c)
static int __init init_hermes(void)
{
return 0;
}
static void __exit exit_hermes(void)
{
}
module_init(init_hermes);
module_exit(exit_hermes);
That's it. As far as I can tell, gcc 4.0 semi-correctly determined they
were
Hi everybody, I just joined the LKML!
Don't worry, this is not just a test message, I do actually have
something to say. I just compiled 2.6.11-rc5-mm1 and got undefined
symbols "match_int", "match_octal", "match_token", and "match_strdup" in
several modu
Hi everybody, I just joined the LKML!
Don't worry, this is not just a test message, I do actually have
something to say. I just compiled 2.6.11-rc5-mm1 and got undefined
symbols match_int, match_octal, match_token, and match_strdup in
several modules. This is using binutils 2.15 and gcc 3.4.4
52 matches
Mail list logo
