[ptxdist] [Patch] openssl.make, corrected 'ifneq' to set the THUD variable correctly.
Hi, attached is a patch against SVN revison 7889. I had problems with the openssl rule and found out, that the THUD variable was not set. The reason was the 'ifneq' statement which should set THUD. "ifneq ($(and $(PTXCONF_ARCH_ARM),$(PTXCONF_ENDIAN_LITTLE)),)" Let's say PTXCONF_ARCH_ARM and PTXCONF_ENDIAN_LITTLE is 'y' so it is expanded to "ifneq ($(and y,y),)" "and y,y" will return y and $y is expanded to 'nothing' so 'nothing' is equal to 'nothing' and THUD is not set. -Jürgen Subject: [Patch] openssl.make, corrected 'ifneq' to set the THUD variable correctly. From: Juergen Kilb <[EMAIL PROTECTED]> Signed-off-by: Juergen Kilb <[EMAIL PROTECTED]> --- Index: openssl.make === --- openssl.make (Revision 7889) +++ openssl.make (Arbeitskopie) @@ -24,19 +24,19 @@ OPENSSL_SOURCE = $(SRCDIR)/$(OPENSSL).tar.gz OPENSSL_DIR = $(BUILDDIR)/$(OPENSSL) -ifneq ($(and $(PTXCONF_ARCH_ARM),$(PTXCONF_ENDIAN_LITTLE)),) +ifneq (and $(PTXCONF_ARCH_ARM),$(PTXCONF_ENDIAN_LITTLE),) THUD = linux-arm endif -ifneq ($(and $(PTXCONF_ARCH_ARM),$(PTXCONF_ENDIAN_BIG)),) +ifneq (and $(PTXCONF_ARCH_ARM),$(PTXCONF_ENDIAN_BIG),) THUD = linux-armeb endif -ifneq ($(and $(PTXCONF_ARCH_MIPS),$(PTXCONF_ENDIAN_LITTLE)),) +ifneq (and $(PTXCONF_ARCH_MIPS),$(PTXCONF_ENDIAN_LITTLE),) THUD = linux-mipsel endif -ifneq ($(and $(PTXCONF_ARCH_MIPS),$(PTXCONF_ENDIAN_BIG)),) +ifneq (and $(PTXCONF_ARCH_MIPS),$(PTXCONF_ENDIAN_BIG),) THUD = linux-mips endif -- ptxdist mailing list ptxdist@pengutronix.de
Re: [ptxdist] Ldconfig missing
Hi Robert, Use case: What _we_ would like to do is to include a ldconfig call within the post installation script of our own ipkg's where a shared library is involved. We have experienced difficulties with the LD_LIBRARY_PATH environment variable because we use e.g. our own shared libraries inside applicattions, services, daemons and php, each of them has different requirements for the environment (& -variables) and each of them loads symbols dynamically. These environment fixes for different purposes are at best cludges and have to be updated at various places if sth. changes. As the runtime linker is always involved and looks for ld.so.cache, problems with LD_LIBRARY_PATH (which does not work for non-root !) go away. I think it doesn't make sense to include any ld.so.cache per default. This has to be generated at runtime. A read only file system either contains no ld.so.cache or one has to remount it rw and call ldconfig once manually (or via some setup script). The ldconfig can be of course a configurable option inside the BSP, so even if it takes 550k or more, it's needn´t be mandatory. No patches yet, because I don't know a feasable way to do it, as ldconfig is part of glibc (toolchain) which is outside the BSP build I suppose (at least there is no glibc inside build-target/), so we would have to produce a cross compiled ldconfig inside the toolchain (which is even already done I remember) and collect it at the same stage e.g. where we copy over glibc inside our BSP ? Do we have to change the toolchain rules to put ldconfig somewhere first, before it can be harvested by the BSP rules ? Which @install_copy aware source directory should be used then? Best regards, Daniel. Robert Schwebel wrote: > > Hmm, first of all it would be good to find a sane usage pattern for > it: > ldconfig runs during runtime, so it would have to be built for the > target; then we need an idea how to handle ld.so.cache in the packet > management system (probably by not packaging it at all); > additionally, we need an idea how to create the ld.so.cache file in > case the root filesystem was mounted read-only, which is often the > case on embedded systems. > > ldconfig has a size of 550 kB (statically linked), so it is also a > matter of space. > > But anyway, if we find answers to the questions above, let's > integrate it. Patches are welcome. > > Robert > -- > Dipl.-Ing. Robert Schwebel | http://www.pengutronix.de Pengutronix >- Linux Solutions for Science and Industry Handelsregister: > Amtsgericht Hildesheim, HRA 2686 Hannoversche Str. 2, 31134 >Hildesheim, Germany Phone: +49-5121-206917-0 | Fax: > +49-5121-206917-9 -- Daniel Schnell | [EMAIL PROTECTED] Hugbúnaðargerð | www.marel.com Tel: +354 563 8098 Fax: +354 563 8001 Iceland -- ptxdist mailing list ptxdist@pengutronix.de
Re: [ptxdist] Ldconfig missing
Daniel Schnell wrote: > What _we_ would like to do is to include a ldconfig call within the > post installation script of our own ipkg's where a shared library is > involved. We have experienced difficulties with the LD_LIBRARY_PATH > environment variable because we use e.g. our own shared libraries > inside applicattions, services, daemons and php, each of them has > different requirements for the environment (& -variables) and each of > them loads symbols dynamically. These environment fixes for different > purposes are at best cludges and have to be updated at various places > if sth. changes. As the runtime linker is always involved and looks > for ld.so.cache, problems with LD_LIBRARY_PATH (which does not work > for non-root !) go away. Hmm? AFAIK LD_LIBRARY_PATH work for normal users, too. > I think it doesn't make sense to include any ld.so.cache per default. Perhaps it is possible to generate ld.so.cache prior rootfs bundling. At leat modern glibc support "ldconfig -r". (-r to change root) maybe this works > This has to be generated at runtime. A read only file system either > contains no ld.so.cache or one has to remount it rw and call ldconfig > once manually (or via some setup script). > The ldconfig can be of course a configurable option inside the BSP, > so even if it takes 550k or more, it's needn´t be mandatory. sure :) > No patches yet, because I don't know a feasable way to do it, as > ldconfig is part of glibc (toolchain) which is outside the BSP build > I suppose (at least there is no glibc inside build-target/), so we > would have to produce a cross compiled ldconfig inside the toolchain > (which is even already done I remember) and collect it at the same at least the latest OSELAS.Toolchain-1.1.1 doesn't produce a ldconfig executable, maybe toolchain-trunk does > stage e.g. where we copy over glibc inside our BSP ? Do we have to > change the toolchain rules to put ldconfig somewhere first, before it > can be harvested by the BSP rules ? Which @install_copy aware source > directory should be used then? have a look at "rules/glibc.make" and search for "install_copy_toolchain_usr" BTW: the uclibc guys seem (just did bit googling) to have a dedicated "cross" ldconfigmaybe this can be build and used to generate a ld.so.cache. Marc -- Marc Kleine-Budde Phone: +49-231-2826-924 Pengutronix - Linux Solutions for Science and Industry Vertretung West/Dortmund http://www.pengutronix.de signature.asc Description: OpenPGP digital signature -- ptxdist mailing list ptxdist@pengutronix.de
Re: [ptxdist] Ldconfig missing
On Mon, Mar 31, 2008 at 03:27:05PM +0200, Marc Kleine-Budde wrote: > > What _we_ would like to do is to include a ldconfig call within the > > post installation script of our own ipkg's where a shared library is > > involved. We have experienced difficulties with the LD_LIBRARY_PATH > > environment variable because we use e.g. our own shared libraries > > inside applicattions, services, daemons and php, each of them has > > different requirements for the environment (& -variables) and each of > > them loads symbols dynamically. These environment fixes for different > > purposes are at best cludges and have to be updated at various places > > if sth. changes. Understood. > > As the runtime linker is always involved and looks > > for ld.so.cache, problems with LD_LIBRARY_PATH (which does not work > > for non-root !) go away. > > Hmm? AFAIK LD_LIBRARY_PATH work for normal users, too. That should be right. > > I think it doesn't make sense to include any ld.so.cache per default. > > Perhaps it is possible to generate ld.so.cache prior rootfs bundling. At > leat modern glibc support "ldconfig -r". (-r to change root) maybe this > works Don't think this is a good idea, because you'd have to take care of modularity issues; an ipkg might want to bring it's own path with it. > > No patches yet, because I don't know a feasable way to do it, as > > ldconfig is part of glibc (toolchain) which is outside the BSP build > > I suppose (at least there is no glibc inside build-target/), so we > > would have to produce a cross compiled ldconfig inside the toolchain > > (which is even already done I remember) and collect it at the same > > at least the latest OSELAS.Toolchain-1.1.1 doesn't produce a ldconfig > executable, maybe toolchain-trunk does Do you have a built tree, somewhere? Can you check where it comes from? > > stage e.g. where we copy over glibc inside our BSP? Do we have to > > change the toolchain rules to put ldconfig somewhere first, before it > > can be harvested by the BSP rules? Which @install_copy aware source > > directory should be used then? > > have a look at "rules/glibc.make" and search for > "install_copy_toolchain_usr" > > BTW: the uclibc guys seem (just did bit googling) to have a dedicated > "cross" ldconfigmaybe this can be build and used to generate a > ld.so.cache. Do you have a pointer? May be something to be integrated into busybox. Robert -- Dipl.-Ing. Robert Schwebel | http://www.pengutronix.de Pengutronix - Linux Solutions for Science and Industry Handelsregister: Amtsgericht Hildesheim, HRA 2686 Hannoversche Str. 2, 31134 Hildesheim, Germany Phone: +49-5121-206917-0 | Fax: +49-5121-206917-9 -- ptxdist mailing list ptxdist@pengutronix.de
Re: [ptxdist] [Patch] openssl.make, corrected 'ifneq' to set the THUD variable correctly.
On Sun, Mar 30, 2008 at 07:52:02PM +0100, Juergen Kilb wrote: > attached is a patch against SVN revison 7889. > > I had problems with the openssl rule and found out, that the THUD > variable was not set. The reason was the 'ifneq' statement which > should set THUD. Are you sure? Because it works here. It may happen that you'll have to run 'ptxdist platformconfig' again and just save the result; we have recently added support for strange platforms like blackfin that need different toolchains for u-boot, kernel and userland; if you run the command above, the corresponding variables should be set magically. > "ifneq ($(and $(PTXCONF_ARCH_ARM),$(PTXCONF_ENDIAN_LITTLE)),)" > > Let's say PTXCONF_ARCH_ARM and PTXCONF_ENDIAN_LITTLE is 'y' > > so it is expanded to > "ifneq ($(and y,y),)" > > "and y,y" will return y and $y is expanded to 'nothing' so 'nothing' is equal > to 'nothing' and THUD is not set. Please check "info automake": `$(and CONDITION1[,CONDITION2[,CONDITION3...]])' The `and' function provides a "short-circuiting" AND operation. Each argument is expanded, in order. If an argument expands to an empty string the processing stops and the result of the expansion is the empty string. If all arguments expand to a non-empty string then the result of the expansion is the expansion of the last argument. So the arguments are expanded as you described, the $(and) function expands to the expansion of the last argument (y), which is != nothing. Should be right. Stand alone example: [EMAIL PROTECTED]:~$ cat Makefile BAZ=$(and $(FOO),$(BAR)) all: @echo $(BAZ) [EMAIL PROTECTED]:~$ make FOO= BAR= [EMAIL PROTECTED]:~$ make FOO=y BAR= [EMAIL PROTECTED]:~$ make FOO= BAR=y [EMAIL PROTECTED]:~$ make FOO=y BAR=y y Q.E.D. Robert -- Dipl.-Ing. Robert Schwebel | http://www.pengutronix.de Pengutronix - Linux Solutions for Science and Industry Handelsregister: Amtsgericht Hildesheim, HRA 2686 Hannoversche Str. 2, 31134 Hildesheim, Germany Phone: +49-5121-206917-0 | Fax: +49-5121-206917-9 -- ptxdist mailing list ptxdist@pengutronix.de
Re: [ptxdist] [Patch] openssl.make, corrected 'ifneq' to set the THUD variable correctly.
Hi, [EMAIL PROTECTED] wrote on 31.03.2008 17:05:35: > So the arguments are expanded as you described, the $(and) function expands to > the expansion of the last argument (y), which is != nothing. > > Should be right. Stand alone example: > > [EMAIL PROTECTED]:~$ cat Makefile > BAZ=$(and $(FOO),$(BAR)) > > all: > @echo $(BAZ) > [EMAIL PROTECTED]:~$ make FOO= BAR= > > [EMAIL PROTECTED]:~$ make FOO=y BAR= > > [EMAIL PROTECTED]:~$ make FOO= BAR=y > > [EMAIL PROTECTED]:~$ make FOO=y BAR=y > y > > Q.E.D. If i do the same, the result is different... but why ? [EMAIL PROTECTED]:~> cat Makefile BAZ=$(and $(FOO),$(BAR)) all: @echo $(BAZ) [EMAIL PROTECTED]:~> make FOO= BAR= [EMAIL PROTECTED]:~> make FOO=y BAR= [EMAIL PROTECTED]:~> make FOO= BAR=y [EMAIL PROTECTED]:~> make FOO=y BAR=y [EMAIL PROTECTED]:~> Maybe the 'make' version ? [EMAIL PROTECTED]:~> make -v GNU Make 3.80 Copyright (C) 2002 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. [EMAIL PROTECTED]:~> -Jürgen -- ptxdist mailing list ptxdist@pengutronix.de
Re: [ptxdist] [Patch] openssl.make, corrected 'ifneq' to set the THUD variable correctly.
On Mon, Mar 31, 2008 at 05:54:09PM +0200, Jürgen Kilb wrote: > If i do the same, the result is different... but why ? > > [EMAIL PROTECTED]:~> cat Makefile > BAZ=$(and $(FOO),$(BAR)) > > all: > @echo $(BAZ) > [EMAIL PROTECTED]:~> make FOO= BAR= > > [EMAIL PROTECTED]:~> make FOO=y BAR= > > [EMAIL PROTECTED]:~> make FOO= BAR=y > > [EMAIL PROTECTED]:~> make FOO=y BAR=y > > [EMAIL PROTECTED]:~> > > Maybe the 'make' version ? > > [EMAIL PROTECTED]:~> make -v > GNU Make 3.80 > Copyright (C) 2002 Free Software Foundation, Inc. > This is free software; see the source for copying conditions. > There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A > PARTICULAR PURPOSE. > [EMAIL PROTECTED]:~> Hmm, I have 3.81. Does anyone have a better idea, or should we depend on 3.81? However, it would be a little bit uggly... Robert -- Dipl.-Ing. Robert Schwebel | http://www.pengutronix.de Pengutronix - Linux Solutions for Science and Industry Handelsregister: Amtsgericht Hildesheim, HRA 2686 Hannoversche Str. 2, 31134 Hildesheim, Germany Phone: +49-5121-206917-0 | Fax: +49-5121-206917-9 -- ptxdist mailing list ptxdist@pengutronix.de
Re: [ptxdist] [Patch] openssl.make, corrected 'ifneq' to set the THUD variable correctly.
Hi, [EMAIL PROTECTED] wrote on 31.03.2008 18:22:23: > On Mon, Mar 31, 2008 at 05:54:09PM +0200, Jürgen Kilb wrote: > > If i do the same, the result is different... but why ? > > > > [EMAIL PROTECTED]:~> cat Makefile > > BAZ=$(and $(FOO),$(BAR)) > > > > all: > > @echo $(BAZ) > > [EMAIL PROTECTED]:~> make FOO= BAR= > > > > [EMAIL PROTECTED]:~> make FOO=y BAR= > > > > [EMAIL PROTECTED]:~> make FOO= BAR=y > > > > [EMAIL PROTECTED]:~> make FOO=y BAR=y > > > > [EMAIL PROTECTED]:~> > > > > Maybe the 'make' version ? > > > > [EMAIL PROTECTED]:~> make -v > > GNU Make 3.80 > > Copyright (C) 2002 Free Software Foundation, Inc. > > This is free software; see the source for copying conditions. > > There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A > > PARTICULAR PURPOSE. > > [EMAIL PROTECTED]:~> > > Hmm, I have 3.81. Does anyone have a better idea, or should we depend on > 3.81? However, it would be a little bit uggly... > make was the problem :-( It works with a fresh build "make-3.81" [EMAIL PROTECTED]:~/make-3.81> cd .. [EMAIL PROTECTED]:~> make-3.81/make FOO= BAR= [EMAIL PROTECTED]:~> make-3.81/make FOO=y BAR= [EMAIL PROTECTED]:~> make-3.81/make FOO= BAR=y [EMAIL PROTECTED]:~> make-3.81/make FOO=y BAR=y y [EMAIL PROTECTED]:~> -Jürgen -- ptxdist mailing list ptxdist@pengutronix.de
