| Submitter | Yao Zhao |
|---|---|
| Date | Aug. 7, 2012, 5:31 p.m. |
| Message ID | <1344360704-23172-1-git-send-email-yao.zhao@windriver.com> |
| Download | mbox | patch |
| Permalink | /patch/34047/ |
| State | New |
| Headers | show |
Comments
On 07/08/2012 1:31 PM, Yao Zhao wrote: > In order to fix the QA Issue for libpam which installed to /lib but > reference /usr/libxx/libz and libcrack, install libz and libcrack > to /lib. OpenBSD puts libpam.so in /lib, so it seems kosher... > do_install() { > - oe_runmake DESTDIR=${D} install > + #libz.a installs to libdir, overwrite the env libdir > + #install pkgconfig to env libdir/pkgconfig > + oe_runmake DESTDIR=${D} pkgconfigdir="${libdir}/pkgconfig" \ > + libdir="${base_libdir}" install > } If you're specifying --libdir when configuring, why do you need libdir during make, as well? - Derek
Op 7 aug. 2012, om 19:31 heeft Yao Zhao <yao.zhao@windriver.com> het volgende geschreven: > In order to fix the QA Issue for libpam which installed to /lib but > reference /usr/libxx/libz and libcrack, install libz and libcrack > to /lib. > > Signed-off-by: Yao Zhao <yao.zhao@windriver.com> > --- > meta/recipes-core/zlib/zlib_1.2.7.bb | 8 ++++++-- > meta/recipes-extended/cracklib/cracklib_2.8.19.bb | 2 ++ > 2 files changed, 8 insertions(+), 2 deletions(-) > > diff --git a/meta/recipes-core/zlib/zlib_1.2.7.bb b/meta/recipes-core/zlib/zlib_1.2.7.bb > index 803fec3..d351437 100644 > --- a/meta/recipes-core/zlib/zlib_1.2.7.bb > +++ b/meta/recipes-core/zlib/zlib_1.2.7.bb > @@ -13,7 +13,8 @@ SRC_URI[md5sum] = "2ab442d169156f34c379c968f3f482dd" > SRC_URI[sha256sum] = "49e2e9658dfb036900da6ea0267a737fa3c4eee6666776d378c79d52e9334934" > > do_configure (){ > - ./configure --prefix=${prefix} --shared --libdir=${libdir} > + #sharedlibdir sets to {libdir} if not set > + ./configure --prefix=${prefix} --shared --libdir="${base_libdir}" > } > > do_compile (){ > @@ -21,7 +22,10 @@ do_compile (){ > } > > do_install() { > - oe_runmake DESTDIR=${D} install > + #libz.a installs to libdir, overwrite the env libdir > + #install pkgconfig to env libdir/pkgconfig > + oe_runmake DESTDIR=${D} pkgconfigdir="${libdir}/pkgconfig" \ > + libdir="${base_libdir}" install > } > > BBCLASSEXTEND = "native nativesdk" > diff --git a/meta/recipes-extended/cracklib/cracklib_2.8.19.bb b/meta/recipes-extended/cracklib/cracklib_2.8.19.bb > index 2951396..aca6211 100644 > --- a/meta/recipes-extended/cracklib/cracklib_2.8.19.bb > +++ b/meta/recipes-extended/cracklib/cracklib_2.8.19.bb > @@ -15,3 +15,5 @@ SRC_URI[md5sum] = "ca0ec168d9c6466612204e8dfb2df8a9" > SRC_URI[sha256sum] = "7086b0ca23f875c9cd9ea2a993c262384b274dba9c4ea1da845ec8ac290748a9" > > inherit autotools gettext > + > +libdir = "${base_libdir}" Again, missing PR bump and missing buildhistory diffs.
On Tue, 2012-08-07 at 14:30 -0400, Yao Zhao wrote: > On 12-08-07 01:39 PM, Derek Buitenhuis wrote: > > On 07/08/2012 1:31 PM, Yao Zhao wrote: > >> In order to fix the QA Issue for libpam which installed to /lib but > >> reference /usr/libxx/libz and libcrack, install libz and libcrack > >> to /lib. > > OpenBSD puts libpam.so in /lib, so it seems kosher... > > > >> do_install() { > >> - oe_runmake DESTDIR=${D} install > >> + #libz.a installs to libdir, overwrite the env libdir > >> + #install pkgconfig to env libdir/pkgconfig > >> + oe_runmake DESTDIR=${D} pkgconfigdir="${libdir}/pkgconfig" \ > >> + libdir="${base_libdir}" install > >> } > > If you're specifying --libdir when configuring, why do you need > > libdir during make, as well? > zlib is not using autotools although it has configure. > when install, oe_runmake will be make -e so Makefile will always use > env's libdir which is the usr/libxx, we have to overwrite it when install. Where do libz.a and libz.so end up after your patch? p.
On 12-08-07 01:39 PM, Derek Buitenhuis wrote: > On 07/08/2012 1:31 PM, Yao Zhao wrote: >> In order to fix the QA Issue for libpam which installed to /lib but >> reference /usr/libxx/libz and libcrack, install libz and libcrack >> to /lib. > OpenBSD puts libpam.so in /lib, so it seems kosher... > >> do_install() { >> - oe_runmake DESTDIR=${D} install >> + #libz.a installs to libdir, overwrite the env libdir >> + #install pkgconfig to env libdir/pkgconfig >> + oe_runmake DESTDIR=${D} pkgconfigdir="${libdir}/pkgconfig" \ >> + libdir="${base_libdir}" install >> } > If you're specifying --libdir when configuring, why do you need > libdir during make, as well? zlib is not using autotools although it has configure. when install, oe_runmake will be make -e so Makefile will always use env's libdir which is the usr/libxx, we have to overwrite it when install. yao > - Derek > > _______________________________________________ > Openembedded-core mailing list > Openembedded-core@lists.openembedded.org > http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
On 07/08/2012 2:30 PM, Yao Zhao wrote: > zlib is not using autotools although it has configure. > when install, oe_runmake will be make -e so Makefile will always use > env's libdir which is the usr/libxx, we have to overwrite it when install. Perhaps you don't need to specify during configure then? :shrug: - Derek
On 12-08-07 02:30 PM, Phil Blundell wrote: > On Tue, 2012-08-07 at 14:30 -0400, Yao Zhao wrote: >> On 12-08-07 01:39 PM, Derek Buitenhuis wrote: >>> On 07/08/2012 1:31 PM, Yao Zhao wrote: >>>> In order to fix the QA Issue for libpam which installed to /lib but >>>> reference /usr/libxx/libz and libcrack, install libz and libcrack >>>> to /lib. >>> OpenBSD puts libpam.so in /lib, so it seems kosher... >>> >>>> do_install() { >>>> - oe_runmake DESTDIR=${D} install >>>> + #libz.a installs to libdir, overwrite the env libdir >>>> + #install pkgconfig to env libdir/pkgconfig >>>> + oe_runmake DESTDIR=${D} pkgconfigdir="${libdir}/pkgconfig" \ >>>> + libdir="${base_libdir}" install >>>> } >>> If you're specifying --libdir when configuring, why do you need >>> libdir during make, as well? >> zlib is not using autotools although it has configure. >> when install, oe_runmake will be make -e so Makefile will always use >> env's libdir which is the usr/libxx, we have to overwrite it when install. > Where do libz.a and libz.so end up after your patch? packages-split$ tree . ??? zlib ? ??? lib ? ??? libz.so.1 -> libz.so.1.2.7 ? ??? libz.so.1.2.7 ??? zlib-dbg ? ??? lib ? ??? usr ? ??? src ? ??? debug ? ??? zlib-1.2.7-r0 ? ??? zlib-1.2.7 ? ??? adler32.c ? ??? compress.c ? ??? crc32.c ? ??? crc32.h ? ??? deflate.c ? ??? deflate.h ? ??? gzclose.c ? ??? gzguts.h ? ??? gzlib.c ? ??? gzread.c ? ??? gzwrite.c ? ??? infback.c ? ??? inffast.c ? ??? inffast.h ? ??? inffixed.h ? ??? inflate.c ? ??? inflate.h ? ??? inftrees.c ? ??? inftrees.h ? ??? trees.c ? ??? trees.h ? ??? uncompr.c ? ??? zconf.h ? ??? zlib.h ? ??? zutil.c ? ??? zutil.h ??? zlib-dev ? ??? lib ? ? ??? libz.so -> libz.so.1.2.7 ? ??? usr ? ??? include ? ? ??? zconf.h ? ? ??? zlib.h ? ??? lib ? ??? pkgconfig ? ??? zlib.pc ??? zlib-doc ? ??? usr ? ??? share ? ??? man ? ??? man3 ? ??? zlib.3 ??? zlib-locale ??? zlib.shlibdeps ??? zlib-staticdev ??? lib ??? libz.a cracklib ??? lib ? ??? libcrack.so.2 -> libcrack.so.2.8.1 ? ??? libcrack.so.2.8.1 ??? usr ??? sbin ? ??? cracklib-check ? ??? cracklib-format ? ??? cracklib-packer ? ??? cracklib-unpacker ? ??? create-cracklib-dict ??? share ??? cracklib ??? cracklib.magic ??? cracklib-small cracklib-staticdev/ ??? lib ??? libcrack.a usr/sbin/* reference lib should be fine, so I didn't change that part. yao > p. > > > _______________________________________________ > Openembedded-core mailing list > Openembedded-core@lists.openembedded.org > http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
On Tue, 2012-08-07 at 14:35 -0400, Yao Zhao wrote: > On 12-08-07 02:30 PM, Phil Blundell wrote: > > Where do libz.a and libz.so end up after your patch? > ??? zlib-dev > ? ??? lib > ? ? ??? libz.so -> libz.so.1.2.7 > ??? zlib-staticdev > ??? lib > ??? libz.a I found the output from "tree" a bit hard to read, but that doesn't look right to me. p.
On 12-08-07 02:38 PM, Phil Blundell wrote: > On Tue, 2012-08-07 at 14:35 -0400, Yao Zhao wrote: >> On 12-08-07 02:30 PM, Phil Blundell wrote: >>> Where do libz.a and libz.so end up after your patch? >> ??? zlib-dev >> ? ??? lib >> ? ? ??? libz.so -> libz.so.1.2.7 >> ??? zlib-staticdev >> ??? lib >> ??? libz.a > I found the output from "tree" a bit hard to read, but that doesn't look > right to me. any reason? It shouldn't go to lib, but still /usr/libxx? yao > p. > > > > _______________________________________________ > Openembedded-core mailing list > Openembedded-core@lists.openembedded.org > http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
On Tue, 2012-08-07 at 14:43 -0400, Yao Zhao wrote: > On 12-08-07 02:38 PM, Phil Blundell wrote: > > On Tue, 2012-08-07 at 14:35 -0400, Yao Zhao wrote: > >> On 12-08-07 02:30 PM, Phil Blundell wrote: > >>> Where do libz.a and libz.so end up after your patch? > >> ??? zlib-dev > >> ? ??? lib > >> ? ? ??? libz.so -> libz.so.1.2.7 > >> ??? zlib-staticdev > >> ??? lib > >> ??? libz.a > > I found the output from "tree" a bit hard to read, but that doesn't look > > right to me. > any reason? It shouldn't go to lib, but still /usr/libxx? Conventionally, yeah. I think the linker does search both but the development files would traditionally go in /usr/lib. p.
On 12-08-07 02:45 PM, Phil Blundell wrote: > On Tue, 2012-08-07 at 14:43 -0400, Yao Zhao wrote: >> On 12-08-07 02:38 PM, Phil Blundell wrote: >>> On Tue, 2012-08-07 at 14:35 -0400, Yao Zhao wrote: >>>> On 12-08-07 02:30 PM, Phil Blundell wrote: >>>>> Where do libz.a and libz.so end up after your patch? >>>> ??? zlib-dev >>>> ? ??? lib >>>> ? ? ??? libz.so -> libz.so.1.2.7 >>>> ??? zlib-staticdev >>>> ??? lib >>>> ??? libz.a >>> I found the output from "tree" a bit hard to read, but that doesn't look >>> right to me. >> any reason? It shouldn't go to lib, but still /usr/libxx? > Conventionally, yeah. I think the linker does search both but the > development files would traditionally go in /usr/lib. If don't install libz.a to the same directory, will linker find libz.a not libz.so if -L /usr/lib -L /lib? yao > p. > > > > _______________________________________________ > Openembedded-core mailing list > Openembedded-core@lists.openembedded.org > http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
On Tue, 2012-08-07 at 15:29 -0400, Yao Zhao wrote: > On 12-08-07 02:45 PM, Phil Blundell wrote: > > On Tue, 2012-08-07 at 14:43 -0400, Yao Zhao wrote: > >> On 12-08-07 02:38 PM, Phil Blundell wrote: > >>> On Tue, 2012-08-07 at 14:35 -0400, Yao Zhao wrote: > >>>> On 12-08-07 02:30 PM, Phil Blundell wrote: > >>>>> Where do libz.a and libz.so end up after your patch? > >>>> ??? zlib-dev > >>>> ? ??? lib > >>>> ? ? ??? libz.so -> libz.so.1.2.7 > >>>> ??? zlib-staticdev > >>>> ??? lib > >>>> ??? libz.a > >>> I found the output from "tree" a bit hard to read, but that doesn't look > >>> right to me. > >> any reason? It shouldn't go to lib, but still /usr/libxx? > > Conventionally, yeah. I think the linker does search both but the > > development files would traditionally go in /usr/lib. > If don't install libz.a to the same directory, will linker find libz.a > not libz.so if -L /usr/lib -L /lib? You want both libz.a and libz.so in /usr/lib so I think that ought to be a non-issue. But in any case, I think (though I'm not 100% certain) that it will look for libz.so in all paths before searching for libz.a. p.
On 12-08-07 05:20 PM, Phil Blundell wrote: > On Tue, 2012-08-07 at 15:29 -0400, Yao Zhao wrote: >> On 12-08-07 02:45 PM, Phil Blundell wrote: >>> On Tue, 2012-08-07 at 14:43 -0400, Yao Zhao wrote: >>>> On 12-08-07 02:38 PM, Phil Blundell wrote: >>>>> On Tue, 2012-08-07 at 14:35 -0400, Yao Zhao wrote: >>>>>> On 12-08-07 02:30 PM, Phil Blundell wrote: >>>>>>> Where do libz.a and libz.so end up after your patch? >>>>>> ??? zlib-dev >>>>>> ? ??? lib >>>>>> ? ? ??? libz.so -> libz.so.1.2.7 >>>>>> ??? zlib-staticdev >>>>>> ??? lib >>>>>> ??? libz.a >>>>> I found the output from "tree" a bit hard to read, but that doesn't look >>>>> right to me. >>>> any reason? It shouldn't go to lib, but still /usr/libxx? >>> Conventionally, yeah. I think the linker does search both but the >>> development files would traditionally go in /usr/lib. >> If don't install libz.a to the same directory, will linker find libz.a >> not libz.so if -L /usr/lib -L /lib? > You want both libz.a and libz.so in /usr/lib so I think that ought to be > a non-issue. But in any case, I think (though I'm not 100% certain) > that it will look for libz.so in all paths before searching for libz.a. I want both libz.a and libz.so* in /lib. I wrote a simple test case: cat Makefile all: gcc -c -fPIC -DPIC -o test.o test.c -g gcc -o libtest.so -shared test.o gcc -c -o test_main.o test_main.c -g ar rc libtest.a test.o mv libtest.a usr/lib mv libtest.so lib gcc -o test_main_static test_main.o -L./usr/lib -L./lib -ltest gcc -o test_main_shared test_main.o -L./lib -L./usr/lib -ltest If don't install to same directory then it will have problems. yao > p. > > > > _______________________________________________ > Openembedded-core mailing list > Openembedded-core@lists.openembedded.org > http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
On Wed, 2012-08-08 at 09:24 -0400, Yao Zhao wrote: > I want both libz.a and libz.so* in /lib. > > I wrote a simple test case: > cat Makefile > all: > gcc -c -fPIC -DPIC -o test.o test.c -g > gcc -o libtest.so -shared test.o > gcc -c -o test_main.o test_main.c -g > ar rc libtest.a test.o > mv libtest.a usr/lib > mv libtest.so lib > gcc -o test_main_static test_main.o -L./usr/lib -L./lib -ltest > gcc -o test_main_shared test_main.o -L./lib -L./usr/lib -ltest > > If don't install to same directory then it will have problems. That testcase isn't terribly representative since you have libtest.so being the actual shared library. In the zlib case, since it has a proper SONAME, libz.so.1 and libz.so are distinct. p.
On 12-08-07 02:35 PM, Derek Buitenhuis wrote: > On 07/08/2012 2:30 PM, Yao Zhao wrote: >> zlib is not using autotools although it has configure. >> when install, oe_runmake will be make -e so Makefile will always use >> env's libdir which is the usr/libxx, we have to overwrite it when install. > Perhaps you don't need to specify during configure then? :shrug: That is true. But this makes Makefile clearer and for non oe distribution it is supposed to change here and will work. The hack in install part is for oe only. yao > - Derek > > _______________________________________________ > Openembedded-core mailing list > Openembedded-core@lists.openembedded.org > http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
On 12-08-08 09:25 AM, Phil Blundell wrote: > On Wed, 2012-08-08 at 09:24 -0400, Yao Zhao wrote: >> I want both libz.a and libz.so* in /lib. >> >> I wrote a simple test case: >> cat Makefile >> all: >> gcc -c -fPIC -DPIC -o test.o test.c -g >> gcc -o libtest.so -shared test.o >> gcc -c -o test_main.o test_main.c -g >> ar rc libtest.a test.o >> mv libtest.a usr/lib >> mv libtest.so lib >> gcc -o test_main_static test_main.o -L./usr/lib -L./lib -ltest >> gcc -o test_main_shared test_main.o -L./lib -L./usr/lib -ltest >> >> If don't install to same directory then it will have problems. > That testcase isn't terribly representative since you have libtest.so > being the actual shared library. In the zlib case, since it has a > proper SONAME, libz.so.1 and libz.so are distinct. Slightly modified: cat Makefile all: gcc -c -fPIC -DPIC -o test.o test.c -g gcc -o libtest.so.1.2 -Wl,-soname,libtest.so.1 -shared test.o gcc -c -o test_main.o test_main.c -g ar rc libtest.a test.o ln -s libtest.so.1.2 libtest.so.1 ln -s libtest.so.1.2 libtest.so mv libtest.a usr/lib mv libtest.so* lib gcc -o test_main_static test_main.o -L./usr/lib -L./lib -ltest gcc -o test_main_shared test_main.o -Llib -L./usr/lib -ltest yao > p. > > > > _______________________________________________ > Openembedded-core mailing list > Openembedded-core@lists.openembedded.org > http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Patch
diff --git a/meta/recipes-core/zlib/zlib_1.2.7.bb b/meta/recipes-core/zlib/zlib_1.2.7.bb index 803fec3..d351437 100644 --- a/meta/recipes-core/zlib/zlib_1.2.7.bb +++ b/meta/recipes-core/zlib/zlib_1.2.7.bb @@ -13,7 +13,8 @@ SRC_URI[md5sum] = "2ab442d169156f34c379c968f3f482dd" SRC_URI[sha256sum] = "49e2e9658dfb036900da6ea0267a737fa3c4eee6666776d378c79d52e9334934" do_configure (){ - ./configure --prefix=${prefix} --shared --libdir=${libdir} + #sharedlibdir sets to {libdir} if not set + ./configure --prefix=${prefix} --shared --libdir="${base_libdir}" } do_compile (){ @@ -21,7 +22,10 @@ do_compile (){ } do_install() { - oe_runmake DESTDIR=${D} install + #libz.a installs to libdir, overwrite the env libdir + #install pkgconfig to env libdir/pkgconfig + oe_runmake DESTDIR=${D} pkgconfigdir="${libdir}/pkgconfig" \ + libdir="${base_libdir}" install } BBCLASSEXTEND = "native nativesdk" diff --git a/meta/recipes-extended/cracklib/cracklib_2.8.19.bb b/meta/recipes-extended/cracklib/cracklib_2.8.19.bb index 2951396..aca6211 100644 --- a/meta/recipes-extended/cracklib/cracklib_2.8.19.bb +++ b/meta/recipes-extended/cracklib/cracklib_2.8.19.bb @@ -15,3 +15,5 @@ SRC_URI[md5sum] = "ca0ec168d9c6466612204e8dfb2df8a9" SRC_URI[sha256sum] = "7086b0ca23f875c9cd9ea2a993c262384b274dba9c4ea1da845ec8ac290748a9" inherit autotools gettext + +libdir = "${base_libdir}"
In order to fix the QA Issue for libpam which installed to /lib but reference /usr/libxx/libz and libcrack, install libz and libcrack to /lib. Signed-off-by: Yao Zhao <yao.zhao@windriver.com> --- meta/recipes-core/zlib/zlib_1.2.7.bb | 8 ++++++-- meta/recipes-extended/cracklib/cracklib_2.8.19.bb | 2 ++ 2 files changed, 8 insertions(+), 2 deletions(-)