[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). 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 ?
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
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
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
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
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@denx.de Bus error -- please leave by the rear door.
Regards
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@lists.sourceforge.net [mailto:u-boot-users-admin@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).
participants (3)
-
Chuck Meade -
Pierre AUBERT -
Wolfgang Denk