-u and EXTERN(foo) have different semantics

[Neal H. Walfield]

The ld info page states the following:

  `EXTERN(SYMBOL SYMBOL ...)'
       Force SYMBOL to be entered in the output file as an undefined
       symbol.  Doing this may, for example, trigger linking of additional
       modules from standard libraries.  You may list several SYMBOLs for
       each `EXTERN', and you may use `EXTERN' multiple times.  This
       command has the same effect as the `-u' command-line option.

However, I believe that I have run across a situation where `-u' and
`EXTERN' behave differently.  Consider the following three files:

foo.c:

extern void bar (void);

int
main (int argc, char *argv[])
{
  bar ();
  return 0;
}

bar.c:

void
bar (void)
{
  return;
}

and the linker script libbar.a:

EXTERN(bar)
INPUT(-lbar2)


bar.c will be compiled and placed in libbar2.a.  foo.o will be linked
with libbar.a to create an executable, foo.  For instance:

  cc -Wall   -c -o bar.o bar.c
  rm -f libbar2.a
  ar cru libbar2.a bar.o
  ranlib libbar2.a
  cc -Wall   -c -o foo.o foo.c
  cc foo.o -o foo -L. -lbar

This works well.  However, if -lbar is placed before foo.o, an
undefined reference to bar is produced despite the fact that bar
should have been brought in from libbar2.a by the EXTERN(bar) in
libbar.a.

  cc -L. -lbar foo.o -o foo
  foo.o: In function `main':
  foo.o(.text+0x7): undefined reference to `bar'
  collect2: ld returned 1 exit status

However, if the contents of libbar.a are instead passed on the command
line, the link succeeds:

  cc -ubar -L. -lbar2 foo.o -o foo


Which are the correct semantics and is this really a bug?

Thanks.