[U-Boot-Users] Library order problem

[U-Boot-Users] Library order problem

[Pierre AUBERT]

Hello everybody,

I'm currently developping a driver for a LCD driver (the Epson SED13806
used on the Embedded
Planet ECCX board). In this driver, I need to call board specific
functions, then I added a file in the RPXClassic
board directory. During the link phase, I have some errors because of
undefined references to the board specific
functions. These errors are due to the library order defined in the main
Makefile. The board library is the first in the
list. I've tried to change this order in the following way :

LIBS  = board/$(BOARDDIR)/lib$(BOARD).a
LIBS += cpu/$(CPU)/lib$(CPU).a
LIBS += lib_$(ARCH)/lib$(ARCH).a
LIBS += fs/jffs2/libjffs2.a fs/fdos/libfdos.a
LIBS += net/libnet.a
LIBS += disk/libdisk.a
LIBS += rtc/librtc.a
LIBS += dtt/libdtt.a
LIBS += drivers/libdrivers.a
LIBS += post/libpost.a post/cpu/libcpu.a
LIBS += common/libcommon.a
LIBS += lib_generic/libgeneric.a

becomes
LIBS  = cpu/$(CPU)/lib$(CPU).a
LIBS += lib_$(ARCH)/lib$(ARCH).a
LIBS += fs/jffs2/libjffs2.a fs/fdos/libfdos.a
LIBS += net/libnet.a
LIBS += disk/libdisk.a
LIBS += rtc/librtc.a
LIBS += dtt/libdtt.a
LIBS += drivers/libdrivers.a
LIBS += post/libpost.a post/cpu/libcpu.a
LIBS += common/libcommon.a
LIBS += lib_generic/libgeneric.a
LIBS += board/$(BOARDDIR)/lib$(BOARD).a

This modification solves my problem. I ran the MAKEALL script for 8xx,
8260, 824x and 74xx boards (I don't have any compiler for other
processors) without any problem.

What do you think about this modification ?

[U-Boot-Users] Library order problem

[Wolfgang Denk]

In message <3DDA4D62.F255E9B3@staubli.com> you wrote:
> 
> board directory. During the link phase, I have some errors because of
> undefined references to the board specific
> functions. These errors are due to the library order defined in the main
> Makefile. The board library is the first in the
> list. I've tried to change this order in the following way :

Please note that the libraries are already searched twice:

...
u-boot:         depend subdirs $(OBJS) $(LIBS) $(LDSCRIPT)
		$(LD) $(LDFLAGS) $(OBJS) $(LIBS) $(LIBS) -Map u-boot.map -o u-boot


This is ugly, and I really would like to get rid of this.

> This modification solves my problem. I ran the MAKEALL script for 8xx,
> 8260, 824x and 74xx boards (I don't have any compiler for other
> processors) without any problem.
> 
> What do you think about this modification ?

Maybe there is a better way? We used to have ranlib for  things  like
this, but it does not seem to help on PPC. Anybody any ideas?

Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd at denx.de
Bus error -- please leave by the rear door.

[U-Boot-Users] Library order problem

[Chuck Meade]

Hi Pierre,

Can you post that SED13806 LCD driver to the list or send it
to me?  Sounds interesting.

Thanks,
Chuck

> -----Original Message-----
> From: u-boot-users-admin at lists.sourceforge.net
> [mailto:u-boot-users-admin at lists.sourceforge.net]On Behalf Of Pierre
> AUBERT
> Sent: Tuesday, November 19, 2002 9:41 AM
> To: Mailing list U-Boot
> Subject: [U-Boot-Users] Library order problem
> 
> 
> Hello everybody,
> 
> I'm currently developping a driver for a LCD driver (the Epson SED13806
> used on the Embedded
> Planet ECCX board).

[U-Boot-Users] Library order problem

[Chuck Meade]

I believe that this is GNU-specific, but try surrounding $(LIBS)
with the --start-group and --end-group switches.  That has worked
for me in the past when a group of interdependent libraries has
needed multiple-scanning.  This should allow just one instance of
$(LIBS) as well.

Chuck Meade
The PTR Group


> Please note that the libraries are already searched twice:
> 
> ...
> u-boot:         depend subdirs $(OBJS) $(LIBS) $(LDSCRIPT)
> 		$(LD) $(LDFLAGS) $(OBJS) $(LIBS) $(LIBS) -Map u-boot.map -o u-boot
> 
> This is ugly, and I really would like to get rid of this.
> 
...
> 
> Maybe there is a better way? We used to have ranlib for  things  like
> this, but it does not seem to help on PPC. Anybody any ideas?
> 
> Best regards,
> 
> Wolfgang Denk

[U-Boot-Users] Library order problem

[Pierre AUBERT]

Chuck Meade wrote:

> Hi Pierre,
>
> Can you post that SED13806 LCD driver to the list or send it
> to me?  Sounds interesting.
>

Sure, I would post it to the list when it will be a little bit more stable
!!!
Regards

>
> Thanks,
> Chuck
>

[U-Boot-Users] Library order problem

[Pierre AUBERT]

Wolfgang Denk wrote:

> In message <3DDA4D62.F255E9B3@staubli.com> you wrote:
> >
> > board directory. During the link phase, I have some errors because of
> > undefined references to the board specific
> > functions. These errors are due to the library order defined in the main
> > Makefile. The board library is the first in the
> > list. I've tried to change this order in the following way :
>
> Please note that the libraries are already searched twice:

I know that, but even with the two passes, I still have some unresolved symbols.

>
>
> ...
> u-boot:         depend subdirs $(OBJS) $(LIBS) $(LDSCRIPT)
>                 $(LD) $(LDFLAGS) $(OBJS) $(LIBS) $(LIBS) -Map u-boot.map -o u-boot
>
> This is ugly, and I really would like to get rid of this.
>
> > This modification solves my problem. I ran the MAKEALL script for 8xx,
> > 8260, 824x and 74xx boards (I don't have any compiler for other
> > processors) without any problem.
> >
> > What do you think about this modification ?
>
> Maybe there is a better way? We used to have ranlib for  things  like
> this, but it does not seem to help on PPC. Anybody any ideas?
>
> Best regards,
>
> Wolfgang Denk
>
> --
> Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
> Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd at denx.de
> Bus error -- please leave by the rear door.

Regards

[U-Boot-Users] Library order problem

[Marius Gröger]

Wolfgang Denk <wd@denx.de> schrieb am 19.11.02 16:28:50:

> Maybe there is a better way? We used to have ranlib for  things  like
> this, but it does not seem to help on PPC. Anybody any ideas?

I don't think ranlib helps if symbols are backward referenced
across library boundaries. GNU ld seems to be running only
1 pass over the libs.

Don't know about that start/end group thing, but it may be
worth a try.

Regards,
Marius.

______________________________________________________________________________
Werden Sie kreativ! Jetzt HTML-Mails nicht nur schreiben - nein -
GESTALTEN, bei WEB.DE FreeMail! http://freemail.web.de/features/?mc=021141

[U-Boot-Users] Library order problem

[Pierre AUBERT]

Chuck Meade wrote:

> I believe that this is GNU-specific, but try surrounding $(LIBS)
> with the --start-group and --end-group switches.  That has worked
> for me in the past when a group of interdependent libraries has
> needed multiple-scanning.  This should allow just one instance of
> $(LIBS) as well.
>

You're right, it works for me with only one invocation of LIBS and the old
definition (with the board specific library in first).
I think it's a good way to solve this problem.

>
> Chuck Meade
> The PTR Group
>
> > Please note that the libraries are already searched twice:
> >
> > ...
> > u-boot:         depend subdirs $(OBJS) $(LIBS) $(LDSCRIPT)
> >               $(LD) $(LDFLAGS) $(OBJS) $(LIBS) $(LIBS) -Map u-boot.map -o u-boot
> >
> > This is ugly, and I really would like to get rid of this.
> >
> ...
> >
> > Maybe there is a better way? We used to have ranlib for  things  like
> > this, but it does not seem to help on PPC. Anybody any ideas?
> >
> > Best regards,
> >
> > Wolfgang Denk

Best regards

[U-Boot-Users] Library order problem

[Wolfgang Denk]

In message <IIEEICKJLNEPBBDJICNGMENJCKAA.chuck@ThePTRGroup.com> you wrote:
> I believe that this is GNU-specific, but try surrounding $(LIBS)
> with the --start-group and --end-group switches.  That has worked
> for me in the past when a group of interdependent libraries has
> needed multiple-scanning.  This should allow just one instance of
> $(LIBS) as well.

My "MAKEALL" is still running, but this indeed helps.

Thanks a lot!

Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd at denx.de
The day-to-day travails of the IBM programmer are so amusing to  most
of us who are fortunate enough never to have been one - like watching
Charlie Chaplin trying to cook a shoe.