[PATCH] cpukit: Move zlib into librtemcpu.a and do not install libz.a.
The JFFS2 file system can optionally use zlib as a compressor and if this is the only reference to zlib the application will not link. Adding -lz does not work because librtemscpu.a is added to the end of ld's command line via the bsp_specs hack and user added libraries appear before this. --- cpukit/wrapup/Makefile.am | 2 ++ cpukit/zlib/Makefile.am | 2 +- cpukit/zlib/preinstall.am | 14 -- 3 files changed, 3 insertions(+), 15 deletions(-) diff --git a/cpukit/wrapup/Makefile.am b/cpukit/wrapup/Makefile.am index e89426f..b8c0ee2 100644 --- a/cpukit/wrapup/Makefile.am +++ b/cpukit/wrapup/Makefile.am @@ -77,6 +77,8 @@ if NEWLIB TMP_LIBS += ../libmd/libmd.a endif +TMP_LIBS += ../zlib/libz.a + librtemscpu.a: $(TMP_LIBS) rm -f $@ $(MKDIR_P) $(ARCH) diff --git a/cpukit/zlib/Makefile.am b/cpukit/zlib/Makefile.am index 478134b..54be345 100644 --- a/cpukit/zlib/Makefile.am +++ b/cpukit/zlib/Makefile.am @@ -1,6 +1,6 @@ include $(top_srcdir)/automake/compile.am -project_lib_LIBRARIES = libz.a +noinst_LIBRARIES = libz.a libz_a_SOURCES = adler32.c libz_a_SOURCES += compress.c diff --git a/cpukit/zlib/preinstall.am b/cpukit/zlib/preinstall.am index 7eb8f7b..a17f25c 100644 --- a/cpukit/zlib/preinstall.am +++ b/cpukit/zlib/preinstall.am @@ -13,25 +13,11 @@ all-am: $(PREINSTALL_FILES) PREINSTALL_FILES = CLEANFILES += $(PREINSTALL_FILES) -all-local: $(TMPINSTALL_FILES) - -TMPINSTALL_FILES = -CLEANFILES += $(TMPINSTALL_FILES) - -$(PROJECT_LIB)/$(dirstamp): - @$(MKDIR_P) $(PROJECT_LIB) - @: > $(PROJECT_LIB)/$(dirstamp) -PREINSTALL_DIRS += $(PROJECT_LIB)/$(dirstamp) - $(PROJECT_INCLUDE)/$(dirstamp): @$(MKDIR_P) $(PROJECT_INCLUDE) @: > $(PROJECT_INCLUDE)/$(dirstamp) PREINSTALL_DIRS += $(PROJECT_INCLUDE)/$(dirstamp) -$(PROJECT_LIB)/libz.a: libz.a $(PROJECT_LIB)/$(dirstamp) - $(INSTALL_DATA) $< $(PROJECT_LIB)/libz.a -TMPINSTALL_FILES += $(PROJECT_LIB)/libz.a - $(PROJECT_INCLUDE)/zlib.h: zlib.h $(PROJECT_INCLUDE)/$(dirstamp) $(INSTALL_DATA) $< $(PROJECT_INCLUDE)/zlib.h PREINSTALL_FILES += $(PROJECT_INCLUDE)/zlib.h -- 1.8.5.2 (Apple Git-48) ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH] cpukit: Move zlib into librtemcpu.a and do not install libz.a.
On 17/09/14 02:26, Chris Johns wrote: The JFFS2 file system can optionally use zlib as a compressor and if this is the only reference to zlib the application will not link. Adding -lz does not work because librtemscpu.a is added to the end of ld's command line via the bsp_specs hack and user added libraries appear before this. If we remove libz.a then this will break all application Makefiles, that assume that RTEMS provides it. I would still provide libz.a. -- Sebastian Huber, embedded brains GmbH Address : Dornierstr. 4, D-82178 Puchheim, Germany Phone : +49 89 189 47 41-16 Fax : +49 89 189 47 41-09 E-Mail : sebastian.hu...@embedded-brains.de PGP : Public key available on request. Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG. ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH] cpukit: Move zlib into librtemcpu.a and do not install libz.a.
On 17/09/2014 3:30 pm, Sebastian Huber wrote: On 17/09/14 02:26, Chris Johns wrote: The JFFS2 file system can optionally use zlib as a compressor and if this is the only reference to zlib the application will not link. Adding -lz does not work because librtemscpu.a is added to the end of ld's command line via the bsp_specs hack and user added libraries appear before this. If we remove libz.a then this will break all application Makefiles, that assume that RTEMS provides it. I would still provide libz.a. Will the linker complain if the symbols are in 2 separate archives ? To me this will appear confusing and result in questions about which is which and why there are 2 copies. I would like to see all these little libraries go away and in post 4.11 (say 5.0) I will be pushing for this very hard for this very reason. Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH] cpukit: Move zlib into librtemcpu.a and do not install libz.a.
On 17/09/14 07:51, Chris Johns wrote:
On 17/09/2014 3:30 pm, Sebastian Huber wrote:
On 17/09/14 02:26, Chris Johns wrote:
The JFFS2 file system can optionally use zlib as a compressor and
if this is the only reference to zlib the application will not link.
Adding -lz does not work because librtemscpu.a is added to the end of
ld's command line via the bsp_specs hack and user added libraries
appear before this.
If we remove libz.a then this will break all application Makefiles, that
assume that RTEMS provides it. I would still provide libz.a.
Will the linker complain if the symbols are in 2 separate archives ?
Since the object files are identical it doesn't matter.
To me this will appear confusing and result in questions about which is which
and why there are 2 copies.
Yes, it is confusing and brittle, but it doesn't break user Makefiles.
Another option would be to patch GCC:
diff --git a/gcc/config/rtems.h b/gcc/config/rtems.h
index f14aed3..8f9fa1e 100644
--- a/gcc/config/rtems.h
+++ b/gcc/config/rtems.h
@@ -44,7 +44,7 @@ see the files COPYING3 and COPYING.RUNTIME respectively. If
not, see
#undef LIB_SPEC
#define LIB_SPEC "%{!qrtems: " STD_LIB_SPEC "} " \
"%{!nostdlib: %{qrtems: --start-group \
- -lrtemsbsp -lrtemscpu \
+ -lrtemsbsp -lrtemscpu -lz \
-lc -lgcc --end-group %{!qnolinkcmds: -T linkcmds%s}}}"
#define TARGET_POSIX_IO
--
Sebastian Huber, embedded brains GmbH
Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone : +49 89 189 47 41-16
Fax : +49 89 189 47 41-09
E-Mail : sebastian.hu...@embedded-brains.de
PGP : Public key available on request.
Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH] cpukit: Move zlib into librtemcpu.a and do not install libz.a.
On 17/09/2014 4:26 pm, Sebastian Huber wrote:
On 17/09/14 07:51, Chris Johns wrote:
On 17/09/2014 3:30 pm, Sebastian Huber wrote:
On 17/09/14 02:26, Chris Johns wrote:
The JFFS2 file system can optionally use zlib as a compressor and
if this is the only reference to zlib the application will not link.
Adding -lz does not work because librtemscpu.a is added to the end of
ld's command line via the bsp_specs hack and user added libraries
appear before this.
If we remove libz.a then this will break all application Makefiles, that
assume that RTEMS provides it. I would still provide libz.a.
Will the linker complain if the symbols are in 2 separate archives ?
Since the object files are identical it doesn't matter.
Hmm still ...
To me this will appear confusing and result in questions about which
is which
and why there are 2 copies.
Yes, it is confusing and brittle, but it doesn't break user Makefiles.
So a user's edit for a 4.11 release (ignoring the transition pain for
those with apps on 4.11) or us having to put up with the questions and
confusion for the life of 4.11.
Another option would be to patch GCC:
diff --git a/gcc/config/rtems.h b/gcc/config/rtems.h
index f14aed3..8f9fa1e 100644
--- a/gcc/config/rtems.h
+++ b/gcc/config/rtems.h
@@ -44,7 +44,7 @@ see the files COPYING3 and COPYING.RUNTIME
respectively. If not, see
#undef LIB_SPEC
#define LIB_SPEC "%{!qrtems: " STD_LIB_SPEC "} " \
"%{!nostdlib: %{qrtems: --start-group \
- -lrtemsbsp -lrtemscpu \
+ -lrtemsbsp -lrtemscpu -lz \
-lc -lgcc --end-group %{!qnolinkcmds: -T linkcmds%s}}}"
#define TARGET_POSIX_IO
Yeah this is ok.
Chris
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH] cpukit: Move zlib into librtemcpu.a and do not install libz.a.
On 09/17/2014 02:26 AM, Chris Johns wrote: The JFFS2 file system can optionally use zlib as a compressor and if this is the only reference to zlib the application will not link. Moving libz.a into librtemscpu.a is not a wise idea. Adding -lz does not work because librtemscpu.a is added to the end of ld's command line via the bsp_specs hack and user added libraries appear before this. That's simply a bug somewhere. You should fix it. Ralf ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH] cpukit: Move zlib into librtemcpu.a and do not install libz.a.
We have now a similar problem with the new PING command: powerpc-rtems4.11-gcc --pipe -B /opt/rtems-4.11/powerpc-rtems4.11/br_uid/lib -specs bsp_specs -qrtems -mcpu=603e -meabi -msdata=sysv -fno-common -mstrict-align -O2 -g -fno-keep-inline-functions -Wl,-Map,b-br_uid/app.map b-br_uid/init.o -o b-br_uid/app.exe -luid -lini -lbed -lyaffs2 -ldemo -lftpd -ltelnetd -lquicc -lnfs -lm /opt/rtems-4.11/powerpc-rtems4.11/br_uid/lib/librtemscpu.a(libshell_a-main_ping.o): In function `main_ping': /home/sh/rtems-4.11/c/src/../../cpukit/libmisc/shell/main_ping.c:1642: undefined reference to `sqrt' -- Sebastian Huber, embedded brains GmbH Address : Dornierstr. 4, D-82178 Puchheim, Germany Phone : +49 89 189 47 41-16 Fax : +49 89 189 47 41-09 E-Mail : sebastian.hu...@embedded-brains.de PGP : Public key available on request. Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG. ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH] cpukit: Move zlib into librtemcpu.a and do not install libz.a.
On 18/09/2014 11:05 pm, Ralf Corsepius wrote: On 09/17/2014 02:26 AM, Chris Johns wrote: The JFFS2 file system can optionally use zlib as a compressor and if this is the only reference to zlib the application will not link. Moving libz.a into librtemscpu.a is not a wise idea. Why ? RTEMS is one source tree that must be built together and used as one so the idea of splitting libraries is counter to this. Yes years ago the separated libraries helped the link speed but those days are long gone. The zlib source not a separate package built separately and it can be argued the separation of this and other libraries without any specific versioning between them is bug and a big one. Adding -lz does not work because librtemscpu.a is added to the end of ld's command line via the bsp_specs hack and user added libraries appear before this. That's simply a bug somewhere. You should fix it. Yes using bsp_specs is simply a bug and a hack however it is too late to fix for 4.11 and RTEMS has dependences on these libraries so we need a solution. I looked into removing bsp_specs about 18months ago and saw no clear alternative without ripping out the build system and breaking all applications. That can happen after 4.11 has been released. There is a solution on the table that I am ok with for 4.11. It is not pretty or nice but it solves the current problem with little impact to users. If you have another solution in mind please provide a tested patch. Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
