summaryrefslogtreecommitdiffstats
path: root/package/Makefile.in
Commit message (Collapse)AuthorAgeFilesLines
* toolchain: add user defined target LDFLAGS optionsBaruch Siach2011-07-251-0/+1
| | | | | | | | | | | | | | | | | Allow the user to specify additional options for the target LDFLAGS. I use this to pass the -te500v2 option to the linker, when using the CodeSourcery toolchain for PowerPC. This chooses the correct CRT for e500 hard float. Otherwise I get errors like undefined reference to `_save32gpr_31' undefined reference to `_rest32gpr_31_x' at final link time. [Peter: fixup, use qstrip] Signed-off-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
* package/autotools: add --{enable,disable}-{shared,static} automaticallyThomas Petazzoni2011-06-121-0/+6
| | | | | | | | | | | | | | | | | | | | | For target packages, depending on BR2_PREFER_STATIC_LIB, add the correct combination of --{enable,disable}-{shared,static} flags to ./configure calls. * When BR2_PREFER_STATIC_LIB is enabled, we pass --enable-static --disable-shared. * When BR2_PREFER_STATIC_LIB is disabled, we pass --enable-static --enable-shared. We enable static libraries since they can still be useful to statically link applications against some libraries (sometimes it is useful for size reasons). Static libraries are anyway only installed in the STAGING_DIR, so it doesn't increase in any way the size of the TARGET_DIR. For host packages, always pass --enable-shared and --disable-static. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
* Get rid of unneeded CFLAGSPeter Korsgaard2011-05-051-36/+5
| | | | | | | | Now that we use a wrapper for external toolchains (and internal ones default to the correct setting), we no longer need to explicitly pass sysroot/march/mtune/mabi/floating point mode in TARGET_CFLAGS. Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
* Add toolchain wrapper for external toolchainsPeter Korsgaard2011-05-051-11/+1
| | | | | | | | | | | | | | | | Add a simple toolchain wrapper for external toolchains, which forces the correct sysroot/march/mtune/floating point options needed to use it with buildroot. With this in place the external toolchain behaves similar to the internal ones, and the special handling can be removed. This also means that the toolchain is usable outside buildroot without having to pass any special compiler flags. Also adjust the downloadable external toolchain support to install under HOST_DIR so it can be used after the temporary build files are removed. Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
* package/Makefile.in: ensure libtool doesn't search host dirs for librariesPeter Korsgaard2011-05-031-0/+1
| | | | | | | | | | | | | | | Commit 7e3e8ec040b (CFLAGS/LDFLAGS: don't add -I / -L args for STAGING_DIR) exposed a lingering libtool problem. Unless instructed otherwise (using -L) libtool will search its built in system path for libraries, and use those instead if found. The default search path is '/usr/lib, /lib, /usr/local/lib', which is no good for cross compilation. Fix it by setting the system search path to the empty string, effectively disabling this feature. Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
* package/Makefile.in: CFLAGS/LDFLAGS: don't add -I / -L args for STAGING_DIRPeter Korsgaard2011-04-291-5/+0
| | | | | | | | | Now that we use sysroot for all toolchains, the explicit -I / -L arguments in CFLAGS / LDFLAGS aren't needed anymore (And having them makes the build quite noisy for certain packages as STAGING_DIR/include normally doesn't exist). Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
* external toolchain: Only prefix path if specifiedSonic Zhang2011-03-281-0/+4
| | | | | | | | | | Only prefix the external toolchain calls with its absolute path if BR2_TOOLCHAIN_EXTERNAL_PATH is set, otherwise just assume it will be available in the path. Signed-off-by: Sonic Zhang <sonic.zhang@analog.com> Acked-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
* pkg-config: add usr/share/pkgconfig to search path as wellPeter Korsgaard2011-03-271-1/+1
| | | | | | | | A few packages (like xlib_xtrans) install their .pc files here, and upstream pkg-config defaults to searching both /usr/lib/pkgconfig and /usr/share/pkgconfig, so add it as well. Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
* pkg-config: add --with-sysroot option for compiled in default sysroot settingPeter Korsgaard2011-01-301-2/+1
| | | | | | | | | | | | | Similar to the --with-pc-path option. It works just like the existing PKG_CONFIG_SYSROOT_DIR environment variable, but compiled in. The environment variable overrides this default setting if set. This way we don't need to pass PKG_CONFIG_SYSROOT_DIR in the environment when building for the target, and it is easier to reuse pkg-config outside BR (E.G. for the SDK) without having to setup special environment variables. Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
* Add CMAKETARGETS infrastructure for CMake packagesBjørn Forsman2011-01-261-0/+1
| | | | | | | | | | | The CMAKETARGETS infrastructure makes adding CMake-based packages to Buildroot easy. It uses the same set of variables as the autotools infrastructure, except for autoreconf and libtool stuff which is not needed. Usage: just call CMAKETARGETS instead of AUTOTARGETS. Signed-off-by: Bjørn Forsman <bjorn.forsman@gmail.com> Acked-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
* Makefile: generate CMake toolchain-file in $(O)Bjørn Forsman2011-01-261-0/+8
| | | | | | | | | | A CMake toolchain-file makes it easy to develop CMake-based packages outside of Buildroot. Just give the toolchain-file to CMake via the -DCMAKE_TOOLCHAIN_FILE=... option. Signed-off-by: Bjørn Forsman <bjorn.forsman@gmail.com> Acked-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
* Use 'sysroot' rather than 'sys-root' for the sysroot/staging_dirPeter Korsgaard2011-01-261-1/+1
| | | | | | | | | | As pointed out on the list, using sysroot rather than sys-root is less confusing, as this is how it is referred to in the GCC manual. So rather than changing BR, patch ct-ng to use sysroot instead. The next ct-ng release will use 'sysroot' as well by default. Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
* crosstool-ng: install toolchain into HOST_DIR like the internal toolchainPeter Korsgaard2011-01-251-3/+1
| | | | | | | Simplifies code and helps us when we add SDK support in the future. With this we no longer need to copy headers/libraries to STAGING_DIR either. Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
* package/Makefile.in: Fix LIBC calculation for internal ct-ng toolchainsPeter Korsgaard2011-01-251-3/+1
| | | | | | Use uclibc for internal ct-ng toolchains configured with uClibc as well. Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
* Use sys-root rather than sysroot for the sysroot/staging_dirPeter Korsgaard2011-01-251-1/+1
| | | | | | | The name of the sysroot directory is arbitrary, but as ct-ng uses sys-root, let's use that as well for consistency. Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
* binutils: make it a proper packageGustavo Zacarias2011-01-021-1/+1
| | | | | | | | | | | | | | | | | | | | | | | * Convert binutils to a proper autotargets package * Add version 2.21 and drop version 2.17 * Hook up packaged binutils for target gcc * Build tools are on HOST_DIR now so change it * Move cross/host gcc to HOST_DIR * Drop kludge from commit 3c77bab2eeace3ee675bd745ca335fa3dd1630bb This is fixed in the next commit "gcc: install copies of libgcc, libstdc++ and libgcj to the sysroot" - tested for arm & x86_64 targets. * TARGET_CROSS now pointed to HOST_DIR too [Peter: Config.in tweaks] Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar> Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
* package: drop sparc64 bitsGustavo Zacarias2010-12-291-5/+0
| | | | | | | Remove VIS optimization, it's for sparc64 and it's gone. Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar> Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
* toolchain: move sysroot to host dirGustavo Zacarias2010-12-281-26/+28
| | | | | | | | * Drop the BR2_STAGING_DIR option * Hardcode STAGING_DIR to $(HOST_DIR)/usr/TUPLE/sysroot Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar> Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
* sstrip: make it a proper packageGustavo Zacarias2010-12-281-1/+1
| | | | | | | | | | | * Convert sstrip to a proper gentargets package * Use openwrt svn version, it's basically the same one we used * Change the hooks from old toolchain/sstrip to new package/sstrip * Drop the old toolchain/sstrip directory * sstrip for the target is now in Package -> Development Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar> Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
* toolchain: rework C++ optionsThomas Petazzoni2010-12-131-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | Instead of having BR2_GCC_CROSS_CXX and BR2_INSTALL_LIBSTDCPP, with BR2_GCC_CROSS_CXX not being visible (and therefore being useless), let's just keep BR2_INSTALL_LIBSTDCPP to enable C++ in the toolchain and install C++ libraries on the target. We also take that opportunity to make BR2_INSTALL_LIBSTDCPP an hidden option, which is selected by an option in Buildroot toolchain support or an option in External toolchain support, just as we did for other toolchain features. Some work definitely remains to be done : - The name BR2_INSTALL_LIBSTDCPP is ugly, but we keep it for the moment in order to avoid changing all packages. - We should clarify the other language-related options (Fortran, Java, Objective-C, etc.). Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Reviewed-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr> Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
* toolchain: add support for external toolchain profiles and downloadThomas Petazzoni2010-12-131-5/+5
| | | | | | | | | | | | | | | | | | | Instead of letting the user define all the details of his external toolchain, we define a set of profiles for well-known external toolchains (CodeSourcery ones only at the moment, can easily be extended with other toolchains). Once a profile has been choosen, the user is offered the choice of either letting Buildroot download and install the external toolchain, or (as before) to tell Buildroot where the toolchain is installed on the system. We of course provide a "custom profile", through which the user can configure Buildroot to use a custom external toolchain for which no profile is available. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
* ccache: rework ccache managementThomas Petazzoni2010-12-081-1/+9
| | | | | | | | | | | | | | * ccache is now a normal package (both for the host and the target). * ccache option is now part of the "Build options" menu. It will automatically build ccache for the host before building anything, and will use it to cache builds for both host compilations and target compilations. * bump ccache to 3.1.3 Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
* Makefile: introduce KSTRIPCMD to strip kernel modulesGustavo Zacarias2010-11-301-5/+4
| | | | | | | | | | | | | | | When sstrip is selected it tries to strip kernel modules too. Unfortunately this fails with a "unrecognized program segment header size" error thus interrupting the build process. We introduce a new $(KSTRIPCMD) strip command for this, being a regular strip when sstrip is selected and an empty stub when not stripping. At the same time get rid of the REMOVE_SECTION_* variables, as they are only used once. Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar> Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
* package/Makefile.in: Add OBJDUMP=$(TARGET_OBJDUMP) to TARGET_CONFIGURE_OPTSMarcelo Roberto Jimenez2010-11-271-0/+1
| | | | | | | | | Closes #2857 The OBJDUMP was missing from TARGET_CONFIGURE_OPTS, this patch adds it to the proper place in package/Makefile.in. Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
* Optimize (-O2) host binaries by defaultPeter Korsgaard2010-10-291-0/+1
| | | | | | | | | Default HOST_CFLAGS to -O2, so host tools (like the cross compiler) are built with optimization by default. Based on a patch by Will Newton <will.newton@gmail.com>. Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
* toolchain: do not require full pathMike Frysinger2010-10-161-0/+4
| | | | | | | If the toolchain can be found via $PATH, then requiring the full path to it is unnecessary. Signed-off-by: Mike Frysinger <vapier@gentoo.org>
* toolchain: add new toolchain backend: crosstool-NGYann E. MORIN2010-10-011-0/+2
| | | | | | [Peter: indent Config.in, shuffle make targets around] Signed-off-by: Yann E. MORIN <yann.morin.1998@anciens.enib.fr> Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
* sed: get rid of host-sed variantPeter Korsgaard2010-09-301-0/+1
| | | | | | | | And all the infrastructure surrounding it. A broken sed implementation is quite rare nowadays, as seen by the fact that the current host-sed support has been broken for a while, so just get rid of it. Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
* Fix computation of REAL_GNU_TARGET_NAMEThomas Petazzoni2010-07-291-1/+10
| | | | | | | | | | | | | | | | | | | | | | | | The current computation of REAL_GNU_TARGET_NAME is incorrect for non-ARM glibc platforms because it generates something such as mipsel-unknown-linux- as the REAL_GNU_TARGET_NAME. So we correct this by : * Adding "gnu" in the suffix when glibc is used, so that in the previous case we will have mipsel-unknown-linux-gnu * Improving the ARM_EABI code to correctly append "eabi" when glibc is selected, so that we have arm-unknown-linux-gnueabi, and to append "gnueabi" when uclibc is selected, so that we have arm-unknown-linux-uclibcgnueabi. The little trick here is that LIBC and ABI aren't completely orthogonal on ARM. This fixes problems such as : checking host system type... Invalid configuration `mipsel-unknown-linux-': machine `mipsel-unknown-linux' not recognized Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
* Remove unused X11_PREFIX optionThomas Petazzoni2010-07-281-4/+0
| | | | Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
* Makefile: fix ldconfig selection for internal toolchainsPeter Korsgaard2010-07-261-6/+0
| | | | | | | | | | | | Commit ed0d45fdd (Choose host/target ldconfig based on availability) added a runtime check for a cross-ldconfig being available. Unfortunately this checks runs too early (at package/Makefile.in parsing time), so it always fails when using an internal toolchain as ldconfig isn't built yet. Fix it by moving the check to the only place it is used (target-finalize). Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
* Choose host/target ldconfig based on availabilityMalte Starostik2010-07-181-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | Decide whether to use the host or target ldconfig based on an availability check instead of internal/external toolchain selection. An external toolchain may very well provide an ldconfig while the host's one may fail. External toolchain generated by Gentoo crossdev: $ LC_ALL=C i686-pc-linux-uclibc-ldconfig -r output/target/; echo $? i686-pc-linux-uclibc-ldconfig: skipping /usr/lib: No such file or directory 0 vs. the host (x86_64-pc-linux-gnu) version: $ LC_ALL=C /sbin/ldconfig -r output/target/; echo $? /sbin/ldconfig: Can't open configuration file output/target/etc/ld.so.conf: No such file or directory /sbin/ldconfig: Can't open cache file /var/cache/ldconfig/aux-cache : No such file or directory 1 Signed-off-by: Malte Starostik <m-starostik@versanet.de> Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
* Merge TARGET_CONFIGURE_ENV into TARGET_CONFIGURE_OPTSThomas Petazzoni2010-07-071-6/+4
| | | | | | | | | | | TARGET_CONFIGURE_ENV defines CFLAGS, LDFLAGS, CXXFLAGS and FCFLAGS, separatly from all other variables that are part of TARGET_CONFIGURE_OPTS. This is useless and not consistent with the HOST_CONFIGURE_ variables, therefore we merge TARGET_CONFIGURE_ENV into TARGET_CONFIGURE_OPTS and fix the few users of TARGET_CONFIGURE_ENV. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
* Remove $(TOOLCHAIN_DIR)/bin and $(STAGING_DIR)/{usr/bin,bin} from the PATHThomas Petazzoni2010-07-071-4/+3
| | | | | | | | | | | These shouldn't be needed. Even when the cross-compiler is in $(STAGING_DIR)/usr/bin, we anyway use an absolute path for TARGET_CC, TARGET_LD and al. Not having $(STAGING_DIR)/{usr/bin,bin} in the PATH will avoid having Buildroot trying to run target binaries. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
* Remove *_FOR_TARGET variables from TARGET_CONFIGURE_OPTSThomas Petazzoni2010-07-071-5/+0
| | | | | | Those variables are not standard. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
* Cleanup TARGET_CONFIGURE_OPTSThomas Petazzoni2010-07-071-20/+25
| | | | | | | | | | | | The definition of CC, LD, GCC, CPP, CXX and FC shouldn't contain the CFLAGS/LDFLAGS/CXXFLAGS, those should be passed through the appropriate variables. However, the --sysroot option is a particular case here: it needs to be part of the CC/LD/GCC/etc. definitions otherwise libtool strips it from the CFLAGS/LDFLAGS. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
* Rework sysroot option handlingThomas Petazzoni2010-07-071-13/+3
| | | | | | | | | | | | The external toolchain and internal toolchain cases both need to use the --sysroot option, and they have almost identical LDFLAGS/CFLAGS/CXXFLAGS definition, so we can factorize these definitions. Moreover, the --isysroot option is implied by --sysroot so there's no need to specify both. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
* Separate flags from commands in HOST_CONFIGURE_OPTSThomas Petazzoni2010-07-071-4/+6
| | | | | | | Just as we did for LD/LDFLAGS, pass CFLAGS and CXXFLAGS in their own variables. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
* Remove unneeded variables in HOST_CONFIGURE_OPTSThomas Petazzoni2010-07-071-26/+0
| | | | | | | When building packages for the host, the *_FOR_BUILD and *_FOR_TARGET variables are not needed. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
* Solve the host tools relying on host libraries problemThomas Petazzoni2010-07-071-2/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We build host tools installed in $(HOST_DIR)/usr/bin, and some of them rely on host libraries in $(HOST_DIR)/usr/lib. So when these host tools are executed, they need to find the host libraries, which are not installed in a default location. In c1b6242fdcf2cff7ebf09fec4cc1be58963e8427 we tried to use LD_LIBRARY_PATH when building target packages to solve this problem. Unfortunately, LD_LIBRARY_PATH is not only used to find libraries at run-time, but also at compile time. So it leads the build of some packages, such as icu, to fail. Therefore, in 0d1830b07db4ebfd14e77a258de6fb391e57e960, we reverted the LD_LIBRARY_PATH idea. The other option to solve this problem was to hardcode a RPATH value in the host binaries that would reference the location of host libraries. We added this -Wl,-rpath option to HOST_CFLAGS in 6b939d40f6a29a43277566adc9d4312d49cb3abf. Unfortunately, this caused problems when building binutils, as reported in bug 1789 so this change was reverted in e1a7d916e9eeaa215551740de40c055130d6c073. Then, we tried to use -Wl,-rpath in HOST_LDFLAGS, but it was causing problems with fakeroot not recognizing 'ld' as the GNU linker, since the -Wl,-rpath cannot be understood by 'ld' directly, only by 'gcc'. This commit is a new attempt at using HOST_LDFLAGS, but in this case we modified the definition of HOST_LD to *not* contain HOST_LDFLAGS. LDFLAGS are being set separatly. It solved the fakeroot issue and was tested against nearly 300 packages of Buildroot. For more details on this story, see http://lists.busybox.net/pipermail/buildroot/2010-June/035580.html http://lists.busybox.net/pipermail/buildroot/2010-June/035581.html http://lists.busybox.net/pipermail/buildroot/2010-June/035586.html http://lists.busybox.net/pipermail/buildroot/2010-June/035609.html https://bugs.busybox.net/show_bug.cgi?id=1789 Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
* ext-toolchain: Fix ARCH_SYSROOT detectionThomas Petazzoni2010-07-061-2/+2
| | | | | | | | | | | | | | | | | | | | | | For the detection of the ARCH_SYSROOT_DIR (which contains the C library variant specific to the compiler flags), we used to pass only the -march argument instead of the full TARGET_CFLAGS. This was done because TARGET_CFLAGS contains --sysroot, and we don't want to tell here the compiler which sysroot to use, because we're specifically asking the compiler where the *normal* arch sysroot directory is. Unfortunately, there are some multilib variants that aren't decided only based on -march, but also on -msoft-float or other compiler flags. Therefore, we take the opposite approach: pass the full TARGET_CFLAGS, from which we have stripped the --sysroot option. For example, this allows a PowerPC CodeSourcery toolchain, on which we're using the soft-float multilib variant, to work properly as an external toolchain. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Reviewed-by: Yann E. MORIN <yann.morin.1998@anciens.enib.fr> Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
* toolchain: remove gcc 4.1.2 and non-sysroot supportPeter Korsgaard2010-06-151-2/+0
| | | | Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
* Revert "Add -rpath option for host package compilation"Peter Korsgaard2010-05-301-5/+0
| | | | | | | | | | | | Closes #1789 This reverts commit 6b939d40f6a29a43277566adc9d4312d49cb3abf. The problem this commit tries to fix is valid, but the fix unfortunately seems to cause worse problems on certain distributions/setups, so revert for now. Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
* Merge branch 'misc-fixes2' of git://git.busybox.net/~tpetazzoni/git/buildrootPeter Korsgaard2010-05-081-0/+6
|\
| * Add staging libraries directories to -L in external caseThomas Petazzoni2010-05-061-0/+1
| | | | | | | | | | | | | | | | In order to solve issues of libtool trying to link target components against host libraries, it seems that specifying -L$(STAGING_DIR)/lib and -L$(STAGING_DIR)/usr/lib works. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
| * Add -rpath option for host package compilationThomas Petazzoni2010-05-061-0/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In c1b6242fdcf2cff7ebf09fec4cc1be58963e8427, we added $(HOST_DIR)/usr/lib to LD_LIBRARY_PATH when building target packages, because the build of target packages sometimes require host tools installed in $(HOST_DIR)/usr/bin which themselves require host libaries installed in $(HOST_DIR)/usr/lib. Unfortunately, this solution didn't work, as libtool then tried to link target binaries against host libraries. So $(HOST_DIR)/usr/lib got removed from LD_LIBRARY_PATH in 0d1830b07db4ebfd14e77a258de6fb391e57e960. However, this meant that we went back to the previous situation, in which host tools used during compilation of target components might require host libraries. An example : make[2]: Entering directory `/home/test/buildroot/output.ctng-arm-eglibc-2010-05-04-12-41-00/build/xfont_font-adobe-100dpi-1.0.1' /home/test/buildroot/output.ctng-arm-eglibc-2010-05-04-12-41-00/host/usr/bin/mkfontdir /home/test/buildroot/output.ctng-arm-eglibc-2010-05-04-12-41-00/target/usr/share/fonts/X11/100dpi /home/test/buildroot/output.ctng-arm-eglibc-2010-05-04-12-41-00/host/usr/bin/mkfontscale: error while loading shared libraries: libfontenc.so.1: cannot open shared object file: No such file or directory Therefore, we try another solution: make sure that host binaries are linked with an -rpath option, so that $(HOST_DIR)/usr/lib doesn't need to be in LD_LIBRARY_PATH for them to find their libraries. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
* | Fix the computation of REAL_GNU_TARGET_NAMEThomas Petazzoni2010-05-061-1/+1
|/ | | | | | | | | | | | | | When the selected C library is glibc, the C library shouldn't be mentionned in REAL_GNU_TARGET_NAME. In other words: arm-unknown-linux-uclibcgnueabi must be used for uClibc arm-unknown-linux-gnueabi must be used for glibc This fixes the build of GDB on the target, as reported by Quotient Remainder <quotientvremainder@gmail.com>. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
* package: Add $(HOST_DIR)/usr/lib to LD_LIBRARY_PATH for host but not targetLionel Landwerlin2010-05-031-3/+4
| | | | | | | | | | | | | | | | | Some packages like icu requires to be compiled against the host system first to be able to compile against the target. This is due to the usage of self generated binaries by the package to build itself. When the generated tools also depends on generated libraries it is required to add the path to these libraries in the library path (LD_LIBRARY_PATH) especially for the configure step. Adding $(HOST_DIR)/usr/lib to LD_LIBRARY_PATH for target compilation might break the link step by mixing host libraries and target binaries. Signed-off-by: Lionel Landwerlin <llandwerlin@gmail.com> Acked-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
* Remove BR2_GNU_TARGET_SUFFIX and compute GNU_TARGET_NAMEThomas Petazzoni2010-05-031-4/+17
| | | | | | | | Instead of asking the user about the GNU target suffix, just compute it automatically from the other configuration options. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
* Get rid of the code computing ROOTFS_SUFFIXThomas Petazzoni2010-05-031-8/+0
| | | | | Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
generated by cgit v1.2.3 (git 2.39.1) at 2024-11-05 05:25:35 +0000