Age | Commit message (Collapse) | Author | Files |
|
Cut and paste the pieces of build-aux/options-parser inline into the main
ltmain.sh code. This removes a performance degradation caused by the
repeated calls to func_quote_for_eval, the mechanism funclib uses
to construct the functions used for option parsing.
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
The libtool would be very slow if run "automake/autoconf --version", for
example, when compile xz-native (make -j1, only compile, no confiure or
install):
before patched: 19s
after patched: 11s
Use plain text to instead of running them.
NOTE: it is still a little slower than libtool 2.4.2 when compile
xz-native because of other parts:
make -j1: about 2s slower
make -j32: about 0.4s slower
If we run to do_install:
(PARALLEL_MAKE = "-j32")
libtool 2.4.2:
$ bitbake xz-native -cinstall && bitbake xz-native -ccleansstate && time bitbake xz-native -cinstall
real 0m21.092s
user 0m28.292s
sys 0m3.932s
libtool 2.4.5:
$ bitbake xz-native -cinstall && bitbake xz-native -ccleansstate && time bitbake xz-native -cinstall
real 0m21.380s
user 0m31.140s
sys 0m4.068s
About 0.3s, slightly different.
But when using /bin/bash as CONFIG_SHELL, the new libtool would be much slower:
real 0m23.106s
user 0m44.044s
sys 0m4.280s
About 2s slower, for the big package like cairo, it is more slower (about 6s),
unfortunately, /bin/bash is most default CONFIG_SHELL for the recipes since
configure checks first check bash.
Signed-off-by: Robert Yang <liezhi.yang@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
If for example you build on a machine with /bin/grep, then restore that sstate
onto a machine with /usr/bin/grep, things will fail. Simply don't bother
hardcoding paths.
This was lost during the libtool upgrade:
http://git.yoctoproject.org/cgit.cgi/poky/diff/meta/recipes-devtools/libtool/libtool/avoid_absolute_paths_for_general_utils.patch?id=d4e1862453b2a4c12400de0f43f08a9871a4de60
since the path to the files changed. This restores the previous behaviour.
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
* Upgrade:
- libtool-native
- libtool-cross
- nativesdk-libtool
- libtool
* Remove 2 patches:
- respect-fstack-protector.patch: already in the new source.
- avoid_absolute_paths_for_general_utils.patch: no general.m4sh any
more.
- Use inline-source to install libtoolize.
* Update other patches
* The LIC_FILES_CHKSUM is changed because of the indent, the contents
are the same.
* The libtool config files are put in libtool/build-aux now, it was
libtool/config in the past.
Signed-off-by: Robert Yang <liezhi.yang@windriver.com>
|
|
Resulted libtool contains references about paths from the build host
Below variables contains hard coded build paths from the host:
LTCC=
lt_sysroot=
sys_lib_search_path_spec=
LD=
CC=
compiler_lib_search_dirs=
predep_objects=
postdep_objects=
compiler_lib_search_path=
Signed-off-by: Shiqun Lin <Shiqun.Lin@windriver.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
|
|
When building upower from meta-oe, the following QA error occurred:
ERROR: QA Issue: package upower contains bad RPATH
It appears to have been caused by one of the cases fix-final-rpath.patch
is meant to address but missed. So this change fixes the additional case
that was causing upower to have the QA error.
Signed-off-by: Randy Witt <randy.e.witt@linux.intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
|
|
* Set CONFIG_SHELL="/bin/bash"
* Add bash to RDEPENDS_libtool
We had already set CONFIG_SHELL="/bin/bash" for libtool-native,
libtool-cross and nativesdk-libtool, now also set for target libtool, if
we don't set this, libtool would use /bin/sh, /bin/bash, /bin/ksh or
/bin/sh5 according to the host, and the build is undetermined, this
patch can fix the problem, libtool is a development tool, rdepends on
bash should not cause toubles (for example, the size of the image)
Have tried to set CONFIG_SHELL="/bin/sh" (/bin/sh -> dash), but there is
still a few bashsim in the output libtool.
Signed-off-by: Robert Yang <liezhi.yang@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
The class itself currently does nothing. The idea is to mark all recipes that
make use of the texinfo utilities. In the future, this class could be used to
suppress the generation/formatting of documentation for performance,
explicitly track dependencies on these utilities, and eliminate Yocto's
current dependency on the host system's texinfo utilities.
Signed-off-by: Max Eliaser <max.eliaser@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
We're seeing similar failures that we saw from libtool-native and libtool-cross
where /bin/sh changed from bash to dash on different machines after sstate
reusage. This patch fixes nativesdk to avoid the same issue.
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
Scenario:
a) libtool script is built on system with bash as /bin/sh
b) machine B installs sstate from build a)
c) machine B has dash as /bin/sh
In this scenario, the script fails to work properly since its expecting
/bin/sh to have bash like syntax and it no longer does have it.
This patch forces the configure process to use /bin/bash, not /bin/sh
and hence allows the scripts to work correctly when used from sstate.
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
Remove the unrecognized configure option '--with-sysroot' to avoid
build time warnings.
Signed-off-by: Chen Qi <Qi.Chen@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
We wipe out and regenerate all configure files so there is no point in
patching them.
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Signed-off-by: Saul Wold <sgw@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
If sed-native is built before these programs, hardcoded paths to sed-native
can end up in scripts and other parts of the system which may cause issues
if they are later used from sstate and sed-native is not installed.
To avoid this, this patch changes the global site configuration to
specify that plain "sed" is fine to be used. We need to spell this
out for gcc since it doesn't see the site files since we don't autoreconf
it. We can remove the values from libtool. We tell perl to use "/bin/sed"
since it requires a path and the system sed should be just fine for it.
[YOCTO #4971]
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Signed-off-by: Saul Wold <sgw@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
This patch updates libtool.m4 (and its output) to resolve a problem
with variable 'lt_sysroot' not being properly updated if the option
'--with[-libtool]-sysroot' is not provided when running the 'configure'
script for a package.
According to the help text ouput from 'configure':
--with-libtool-sysroot=DIR Search for dependent libraries within DIR
(or the compiler's sysrooot if not specified).
Due to mixed up cases in a switch statement, when checking if the option
was specified or not, wrong actions were taken resulting in an incorrect
sysroot and failures to properly locate e.g. .la files when using the
populated SDK toolchain.
For current upstream status see:
http://lists.gnu.org/archive/html/bug-libtool/2013-09/msg00005.html
Signed-off-by: Hans Beckerus <hans.beckerus at gmail.com>
Signed-off-by: Saul Wold <sgw@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
Rename nativesdk item to prefix vs suffix. Some minor changes for
getting it works after renamed:
* append patches dir 'libtool/' to FILESEXTRAPATHS
* update ${S}, append '${datadir}/libtool/*' to FILES_${PN}
Signed-off-by: Wenzong Fan <wenzong.fan@windriver.com>
Signed-off-by: Saul Wold <sgw@linux.intel.com>
|
|
If you never use sstate and always build everything from scratch you
will never see this problem. However, if you use sstate and build
directories that last a long time eventually you can end up with the
scenario where libtool gets a hard coded path in it for sed, and sed
may not exist. The reason you don't see this problem to often if you
generally build from scratch is that libtool builds before sed and
will pickup the host's /bin/sed.
The way to reproduce the issue is:
bitbake some_image
bitbake -c cleansstate libtool-native
bitbake sed-native
bitbake libtool-native
bitbake -c clean sed-native
bitbake ANY_PACKAGE_THAT_USES_LIBTOOL_NATIVE
In my case I used modphp, which doesn't exist in the oe-core. You will
end up with a strange looking error like:
| make[1]: *** [buckets/apr_buckets_alloc.lo] Error 1
| /opt/build/bitbake_build/tmp/sysroots/x86_64-linux/usr/bin/x86_64-linux-libtool: line 981: /opt/build/bitbake_build/tmp/sysroots/x86_64-linux//bin/sed: No such file or directory
The solution is to always use /bin/sed for libtool-native.
Signed-off-by: Jason Wessel <jason.wessel@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
Without this some software fails to build complaining it can't find these
utilities.
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
Remove manpage creation. It wasn't working because of help2man
missing when libtool is being built. This attempt to create
manpages without help2man turns from no-op to hard error with
automake-1.13.
Removed prefix-manpage-fix.patch as only code it touched is being
removed by new dont-depend-on-help2man.patch
Signed-off-by: Marko Lindqvist <cazfi74@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
If you:
bitbake sed-native
bitbake libtool-cross
then libtool-cross has SED="/path/to/sysroot/sed" which is incorrect. If that
is reused from sstate or sed-native is cleaned, the build will fail.
This patch simply sets sed to be "sed" since we're not on systems where
the sed from PATH is broken.
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
Use the built-in normalization function instead of the sed hack.
Signed-off-by: Andy Ross <andy.ross@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
Libtool may be passed link paths of the form "/usr/lib/../lib", which fool
its detection code into thinking it should be included as an RPATH in
the generated binary. Normalize before comparision.
Signed-off-by: Andy Ross <andy.ross@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
With the new order scheme, ${PN} needs to be in the middle
for the .m4 files to be packaged, otherwise the move the
-dev package which is wrong in this case.
Signed-off-by: Saul Wold <sgw@linux.intel.com>
|
|
linker should add -lssp to linker cmdline when
-fstack-protector therefore add this knowledge to libtool
otherwise packages will fail to link
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
While building libtool, the libtool script itself will be regenerated
because OE modifies a dependency[1]. With -jX, this operation (-->
removal, creation of non-x file, 'chmod a+x') can happen at a time when
the script is going to be executed. This can cause errors like:
| arm-linux-gnueabi-libtool: compile: ccache arm-linux-gnueabi-gcc ...
| ...
| /bin/sh ./config.status libtool
| ...
| arm-linux-gnueabi-libtool: compile: ccache arm-linux-gnueabi-gcc ...
| /bin/sh: ./arm-linux-gnueabi-libtool: Permission denied
| make[2]: *** [libltdl/libltdl_libltdl_la-lt__alloc.lo] Error 126
I am not sure whether the custom do_compile_prepend() is still needed.
For now only the issue above will be fixed by executing ./config.status
yet again.
[1] see 648290d5bf4d6ff50d3643bb7ad902dfc23aa702
Signed-off-by: Enrico Scholz <enrico.scholz@sigma-chemnitz.de>
|
|
The missing quote prohibits OE from packaging it correctly, leading to:
| * satisfy_dependencies_for: Cannot satisfy the following dependencies for task-gnome:
| * libltdl7 (>= 2.4.2) * libltdl7 (>= 2.4.2) * libltdl7 (>= 2.4.2) * libltdl7 (>= 2.4.2) * libltdl7 (>= 2.4.2) * libltdl7 (>= 2.4.2) * libltdl7 (>= 2.4.2) *
for incremental builds and binary feeds.
Signed-off-by: Koen Kooi <koen@dominion.thruhere.net>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
Signed-off-by: Saul Wold <sgw@linux.intel.com>
|
|
Signed-off-by: Saul Wold <sgw@linux.intel.com>
|
|
/usr/include/ltdl.h was in libtldl-dev, but not the headers it depends
on.
|
|
This fixes problems where hardcoded paths in the file were incorrect
during sstate reusage of the task output.
Signed-off-by: Saul Wold <sgw@linux.intel.com>
|
|
Rebased patches to the newer source code and deleted resolve-sysroot.patch
since its already applied upstream
merged libtool-2.4.2.inc & libtool.inc files
replaced PR with ${INC_PR}.0
Signed-off-by: Nitin A Kamble <nitin.a.kamble@intel.com>
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
There is no point in having "executable" binaries in the .libs
directory linked with different rpaths to the target which
could concivably be run on the build system when cross compiling.
This patch removes the extra rpaths ($compile_rpath) so that the
output from the "link" stage can be used on the target. We can then
avoid having to "relink" during the install stage.
This saves some build time (do_install is over 2 minutes faster for
pulseaudio).
This patch also removes an annoying "seems to be moved" warning
which is totally bogus in the sysroot case.
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
We should be using libtool-cross for cross compiling but
were not. This patch sets datadir so libtoolize ends up
containing correct paths. It then installs libtoolize.
The path ltmain.sh was installed to was incorrect and this is fixed.
We also now install all the libtool m4 macros and config files.
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
We've had the check for dash as /bin/sh for a long time. Dash has been
around long enough now that most major issues have been identified and
fixed from build perspective.
This patch fixes a bashism in the openjade-native recipe. It also
adjusts libtool so that the header at the script is used and not the
value of $SHELL. This is because many Makefiles change $SHELL so dash
can get used to execute what is otherwise configured as a bash shell
script. Since we don't need to execute scripts this way on any system I'm
aware of us building upon, the simplest fix is just to remove $SHELL.
With these two changes the dash check can be removed and we can allow
builds with dash as /bin/sh
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
[Note: I know I need to add the description of the libtool change above
into the prefix.patch]
|
|
libtool was being to aggressive in adding rpath to binaries. This
change stops it adding them if that path the default search path.
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
gcc: update upstream-status for patches
python: update upstream-status for patches
libtool: update upstream-status of patches
m4: update upstream status for patches
eglibc: remove unused patches
eglibc: update upstream status of patches
glibc: update upstream-status of patches & remove unused patches
Signed-off-by: Nitin A Kamble <nitin.a.kamble@intel.com>
|
|
python: update upstream-status for patches
binutils: update upstream-status for patches
gcc 4.5.1 4.6.0: update upstream-status for patches
autoconf: update upstream-status for patches
automake: update upstream-status for patches
bison: update upstream-status for patches
distcc: update upstream-status of patches
fstests: update upstream-status for patches
gdb: update upstream-status of patches
intltool: update upstream-status of patches
libtool: update upstream status of patches
linux-libc-headers: update upstream-status for patches
make: update upstream-status for patches
perl: update upstream-status for patches
python-pycurl: update upstream-status for patches
python-pygobject: update upstream status for patches
python-pyrex: update upstream-status for patches
quilt: update upstream-status of patches
tcl: update upstream-status for patches
gnu-config: update upstream-status for patches
gmp: update upstream-status for patches
Signed-off-by: Nitin A Kamble <nitin.a.kamble@intel.com>
|
|
License parser should use & not ,
Signed-off-by: Beth Flanagan <elizabeth.flanagan@intel.com>
|
|
addded a new patch:
libtool/avoid_absolute_paths_for_general_utils.patch
This fixes [BUGID #154]
This fixes [BUGID #734]
Signed-off-by: Nitin A Kamble <nitin.a.kamble@intel.com>
|
|
Original we used absolute path in sysroot-destdir for both native and
target recipes. This commit changes target recipes to use relative path
which is same as the image directory.
[sgw: merged with libtool sysroot work]
Signed-off-by: Dongxiao Xu <dongxiao.xu@intel.com>
Signed-off-by: Saul Wold <sgw@linux.intel.com>
|
|
Enabling sysroot support exposed a bug where the final library
had an RPATH encoded into it which still pointed to the sysroot.
This works around the issue until it gets sorted out upstream.
Fix suggested by Richard Purdie <richard.purdie@linuxfoundation.org>
Signed-off-by: Scott Garman <scott.a.garman@intel.com>
|
|
* Added OE patches by Khem Raj which enable sysroot support
and rename the command line option --with-sysroot to
--with-libtool-sysroot to avoid conflicts with binutils and
gcc
* Removed obsolete cross_compile.patch
* Changed SRC_URI_append to SRC_URI +=
* PR bump for all recipes
Signed-off-by: Scott Garman <scott.a.garman@intel.com>
|
|
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
[based on sections of a patch by Scott Garman extracted by Richard]
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
[BUGID #562] fixing:
1. Adjusted the content of various packages generated by libtool.
2. Added libtool-nativesdk into task-sdk-host.
Signed-off-by: Lianhao Lu <lianhao.lu@intel.com>
|
|
Add Summary information and update Descripts as necessary.
Signed-off-by: Mark Hatle <mark.hatle@windriver.com>
|
|
Signed-off-by: Saul Wold <sgw@linux.intel.com>
|
|
Taking out of this code from patch as the newer upstream code has fix,
and this patch is not needed.
cross-compile.patch:
-Index: libtool-2.2.10/libltdl/config/ltmain.m4sh
+Index: libtool-2.4/libltdl/config/ltmain.m4sh
===================================================================
---- libtool-2.2.10.orig/libltdl/config/ltmain.m4sh
-+++ libtool-2.2.10/libltdl/config/ltmain.m4sh
-@@ -5147,8 +5147,14 @@ func_mode_link ()
- absdir="$abs_ladir"
- libdir="$abs_ladir"
- else
-- dir="$libdir"
-- absdir="$libdir"
-+ # Adding 'libdir' from the .la file to our library search
paths
-+ # breaks crosscompilation horribly. We cheat here and don't
add
-+ # it, instead adding the path where we found the .la. -CL
-+ dir="$abs_ladir"
-+ absdir="$abs_ladir"
-+ libdir="$abs_ladir"
-+ #dir="$libdir"
-+ #absdir="$libdir"
- fi
- test "X$hardcode_automatic" = Xyes && avoidtemprpath=yes
- else
Signed-off-by: Nitin A Kamble <nitin.a.kamble@intel.com>
|
|
Having one monolithic packages directory makes it hard to find things
and is generally overwhelming. This commit splits it into several
logical sections roughly based on function, recipes.txt gives more
information about the classifications used.
The opportunity is also used to switch from "packages" to "recipes"
as used in OpenEmbedded as the term "packages" can be confusing to
people and has many different meanings.
Not all recipes have been classified yet, this is just a first pass
at separating things out. Some packages are moved to meta-extras as
they're no longer actively used or maintained.
Signed-off-by: Richard Purdie <rpurdie@linux.intel.com>
|