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
> implementat
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-intu
> 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 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 appe
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
EXPORT_
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-intu
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 contai
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 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 e
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 "x",
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 i
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
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 de
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 obj
[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 t
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 exter
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,
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
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/parse
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 parse
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
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
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
26 matches
Mail list logo
