16.10.2012 18:17, Yves Blusseau пишет: > Le 16/10/2012 16:22, Andrew a écrit : >> 16.10.2012 17:12, Yves Blusseau пишет: >>> Le 16/10/2012 15:52, Andrew a écrit : >>>> 16.10.2012 13:22, Yves Blusseau пишет: >>>>> Hi all, >>>>> i think we have a problem with 64bits target. >>>>> The problem is that package create shared libraries in /usr/lib64 >>>>> instead of >>>>> /usr/lib. >>>>> Also pkgconfig files contain path to /usr/lib64. >>>>> So we need to find a way to package this libraries. >>>>> A good example is openssl. >>>>> To compile/install properly i have activate the extglob shell >>>>> option >>>>> ([1]http://www.linuxjournal.com/content/bash-extended-globbing) >>>>> in >>>>> buildtool.mk: >>>>> [2]SHELL:=/bin/bash -O extglob >>>>> - -chmod -R 755 $(TARGET_DIR)/usr/lib/* >>>>> - -$(BT_STRIP) $(BT_STRIP_LIBOPTS) >>>>> $(TARGET_DIR)/usr/lib/*.so >>>>> - -$(BT_STRIP) $(BT_STRIP_LIBOPTS) >>>>> $(TARGET_DIR)/usr/lib/engines/*.so >>>>> + -chmod -R 755 $(TARGET_DIR)/usr/lib*(64)/* >>>>> + -$(BT_STRIP) $(BT_STRIP_LIBOPTS) >>>>> $(TARGET_DIR)/usr/lib*(64)/*.so >>>>> + -$(BT_STRIP) $(BT_STRIP_LIBOPTS) >>>>> $(TARGET_DIR)/usr/lib*(64)/engines/*.so >>>>> So the libraries are installed properly (some are in /usr/lib >>>>> other in >>>>> /usr/lib64). >>>>> The problem now is the packaging: >>>>> <File> >>>>> Filename = usr/lib/libssl.so.1.0.0 >>>>> Source = usr/lib/libssl.so.1.0.0 >>>>> Type = binary >>>>> Permissions = 755 >>>>> </File> >>>>> <File> >>>>> Filename = usr/lib/libssl.so.0 >>>>> Target = usr/lib/libssl.so.1.0.0 >>>>> Type = link >>>>> Permissions = 755 >>>>> </File> >>>>> <File> >>>>> Filename = usr/lib/libssl.so >>>>> Target = usr/lib/libssl.so.0 >>>>> Type = link >>>>> Permissions = 755 >>>>> </File> >>>>> One idea that come in my mind is to create a variable (example >>>>> libarch) that >>>>> will have the value 'lib' in 32bits and 'lib64' in 64bits mode. >>>>> So the packaging configuration file will be: >>>>> <File> >>>>> Filename = usr/$libarch/libssl.so.1.0.0 >>>>> Source = usr/$libarch/libssl.so.1.0.0 >>>>> Type = binary >>>>> Permissions = 755 >>>>> </File> >>>>> <File> >>>>> Filename = usr/$libarch/libssl.so.0 >>>>> Target = usr/$libarch/libssl.so.1.0.0 >>>>> Type = link >>>>> Permissions = 755 >>>>> </File> >>>>> <File> >>>>> Filename = usr/$libarch/libssl.so >>>>> Target = usr/$libarch/libssl.so.0 >>>>> Type = link >>>>> Permissions = 755 >>>>> </File> >>>>> What do you think about this ? >>>>> Do you think it's a good solution ? >>>>> Do you have another better name for the variable (instead of >>>>> libarch) ? >>>>> We can also have a variable (we need to find a name) i call it >>>>> foo that will >>>>> be empty in 32 bits mode and will have the value '64' in 64 bits >>>>> mode. >>>>> So the path will be like: Filename = >>>>> usr/lib$(foo)/libssl.so.1.0.0 >>>>> What do you prefer if you think it's the good way ? >>>>> Also we need to find where and how the value will be set. The >>>>> best will be >>>>> in the make/toolchain/*.mk file but they are not use during >>>>> packaging. >>>>> To resolv this we can use a config file specific to a toolchain >>>>> and that is >>>>> include by the global configfile: conf/buildtool.conf >>>>> So in conf/buildtool.conf we will have: >>>>> ?include conf/$(Toolchain)-vars.cfg >>>>> and in conf/i486-unknown-linux-uclibc-vars.cfg >>>>> <EnVars> >>>>> libarch=lib >>>>> </EnvVars> >>>>> and in conf/x86_64-unknown-linux-uclibc-vars.cfg >>>>> <EnvVars> >>>>> libarch=lib64 >>>>> </EnvVars> >>>>> If we go in this way, i need to update the perl module so we >>>>> can use >>>>> variable in included filenames. >>>>> Regards, >>>>> Yves >>>>> >>>>> References >>>>> >>>>> 1. http://www.linuxjournal.com/content/bash-extended-globbing >>>>> 2. SHELL:=/bin/bash >>>> Hi. >>>> Maybe it'll be enough to make symlink usr/lib64 -> usr/lib in the >>>> staging dir? >>> Perhaps it's the best, but are some binaries can't use hardcoded path to >>> libraries ? >>> If you don't think, it's the best option. >>> So we can create the link usr/lib64 -> usr/lib in any case (even in a >>> non 64bits toolchain). >>> >>> Yves >>> >> I think that there'll be no problems. libraries are linked at runtime bu >> uClibc ld64-uClibc, and can be placed anywhere. Specific libraries (like >> pppd's ones) are placed always in same place independent of arch. >> > It's works ! > I have compiled bash, busybox and openssh with the x86_64 toolchain and > install them into the staging dir. Then i chroot to staging dir and bash > and ssh commands works like a charm (they find their libraries). > > What i do to compile/install the packages is: > 1) created a link in the staging directory $staging_dir/usr/lib64 -> > staging_dir/usr/lib > 2) created a link in the build directory: $buildir/$package/usr/lib64 -> > $buildir/$package/usr/lib so when the package is installed all the 64 > bits libraries are put in the lib directory > > For 1) we can do it automaticaly by buildtool.pl when the staging > directory is created > For 2) we need to add a ln command to add the link in every package that > can create file under /usr/lib64 > > Are you ok with this ? > > Yves > Hi. Do we actually need to do anything in build directory? I think that it'll be enough to make symlink into staging dir, and all files that are placed into /usr/lib64 will be placed into /usr/lib.
------------------------------------------------------------------------------ Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev _______________________________________________ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel