Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 310465 - sys-devel/crossdev: freebsd version encoding in CTARGET does not play well with actual package versions
Summary: sys-devel/crossdev: freebsd version encoding in CTARGET does not play well wi...
Status: RESOLVED OBSOLETE
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: [OLD] Development (show other bugs)
Hardware: AMD64 Linux
: High normal (vote)
Assignee: Gentoo/BSD Team
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: crossdev-bugs
  Show dependency tree
 
Reported: 2010-03-21 00:26 UTC by Henning Rogge
Modified: 2019-10-11 17:41 UTC (History)
1 user (show)

See Also:
Package list:
Runtime testing required: ---


Attachments
Complete build log of initial 'stopped' emerge (freebsd-lib-8.0.build.log,57.72 KB, text/plain)
2010-03-21 00:29 UTC, Henning Rogge
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Henning Rogge 2010-03-21 00:26:14 UTC
When updating my freebsd crosscompiling toolchain portage ends the ebuild XX with the following error:

i686-gentoo-freebsd7.2-gcc  -march=core2 -O2 -pipe -fno-strict-aliasing -isystem /usr/i686-gentoo-freebsd7.2/usr/include -isystem /var/tmp/portage/cross-i686-gentoo-freebsd7.2/freebsd-lib-8.0/work/lib/libutil -isystem /var/tmp/portage/cross-i686-gentoo-freebsd7.2/freebsd-lib-8.0/work/lib/msun/i387 -B /var/tmp/portage/cross-i686-gentoo-freebsd7.2/freebsd-lib-8.0/work/lib/csu/i386-elf  -DHAVE_CONFIG_H -I/var/tmp/portage/cross-i686-gentoo-freebsd7.2/freebsd-lib-8.0/work/gnu/lib/libssp  -I/var/tmp/portage/cross-i686-gentoo-freebsd7.2/freebsd-lib-8.0/work/gnu/lib/libssp/../../../contrib/gcclibs/libssp  -I/var/tmp/portage/cross-i686-gentoo-freebsd7.2/freebsd-lib-8.0/work/gnu/lib/libssp/../../../contrib/gcclibs/include -std=gnu99  -c /var/tmp/portage/cross-i686-gentoo-freebsd7.2/freebsd-lib-8.0/work/gnu/lib/libssp/../../../contrib/gcclibs/libssp/gets-chk.c
/var/tmp/portage/cross-i686-gentoo-freebsd7.2/freebsd-lib-8.0/work/gnu/lib/libssp/../../../contrib/gcclibs/libssp/gets-chk.c:37:21: error: ssp/ssp.h: No such file or directory

Reproducible: Always

Steps to Reproduce:
1. emerge =cross-i686-gentoo-freebsd7.2/freebsd-lib-8.0

Actual Results:  
Stop.
pmake: stopped in /var/tmp/portage/cross-i686-gentoo-freebsd7.2/freebsd-lib-8.0/work/gnu/lib/libssp
 * ERROR: cross-i686-gentoo-freebsd7.2/freebsd-lib-8.0 failed:
 *   make libssp failed
Comment 1 Henning Rogge 2010-03-21 00:29:33 UTC
Created attachment 224461 [details]
Complete build log of initial 'stopped' emerge
Comment 2 Henning Rogge 2010-03-23 11:45:37 UTC
I forget to add that the ebuild was generated by the gentoo sys-devel/crossdev script. If you need additional data about the crossdev settings, just tell me what I have to add to this bug.
Comment 3 Jeroen Roovers (RETIRED) gentoo-dev 2010-03-24 07:16:05 UTC
Actually we need all the crossdev settings you used, particularly --b, --g, --k and --l.
Comment 4 Samuli Suominen (RETIRED) gentoo-dev 2010-03-24 14:37:47 UTC
Reopen with data requested in Comment #3. Thanks.
Comment 5 Henning Rogge 2010-03-24 15:06:44 UTC
Are these settings somewhere stored ? I set up this crosscompile enviroment last year, so I don't know the settings anymore. At the moment the enviroment runs fine by masking freebsd-lib-8.0. But of course that is no sollution.

Maybe this can help:
List of portage ebuilds used by the crosscompile enviroment.
henning@core2 /usr/local/portage/henning/cross-i686-gentoo-freebsd7.2 $ ls -l
insgesamt 0
lrwxrwxrwx 1 root root 31 21. Dez 01:46 binutils -> /usr/portage/sys-devel/binutils
lrwxrwxrwx 1 root root 36 21. Dez 01:46 freebsd-lib -> /usr/portage/sys-freebsd/freebsd-lib
lrwxrwxrwx 1 root root 26 21. Dez 01:46 gcc -> /usr/portage/sys-devel/gcc
lrwxrwxrwx 1 root root 26 21. Dez 01:46 gdb -> /usr/portage/sys-devel/gdb
lrwxrwxrwx 1 root root 29 21. Dez 01:46 insight -> /usr/portage/dev-util/insight

exact version of the installed packages:
henning@core2 /usr/local/portage/henning/cross-i686-gentoo-freebsd7.2 $ eix cross-i686-gentoo-freebsd7.2/*
[I] cross-i686-gentoo-freebsd7.2/binutils [1]
     Available versions:  (i686-gentoo-freebsd7.2) 2.16.1-r3 *2.16.91.0.6 *2.18-r3 ~2.18-r4 (~)2.19.1-r1 **2.19.51.0.13 **2.19.51.0.14 (~)2.20-r1 (~)2.20.1 **2.20.51.0.1 **2.20.51.0.2 **2.20.51.0.3 **2.20.51.0.4 **2.20.51.0.5 **2.20.51.0.6                       
        {gold multislot multitarget nls test vanilla}
     Installed versions:  2.20.1(i686-gentoo-freebsd7.2)(18:40:03 22.03.2010)(nls -multislot -multitarget -test -vanilla)
     Homepage:            http://sources.redhat.com/binutils/
     Description:         Tools necessary to build programs

[I] cross-i686-gentoo-freebsd7.2/freebsd-lib [1]
     Available versions:  (~*)7.2-r1 [m](~*)8.0 {atm bluetooth bootstrap build crosscompile_opts_headers-only hesiod ipv6 kerberos netware profile ssl usb}                                                                                                           
     Installed versions:  7.2-r1(18:54:27 22.03.2010)(bluetooth ipv6 ssl usb -atm -bootstrap -build -crosscompile_opts_headers-only -hesiod -kerberos -netware -profile)
     Homepage:            http://www.freebsd.org/
     Description:         FreeBSD's base system libraries

[I] cross-i686-gentoo-freebsd7.2/gcc [1]
     Available versions:  
        (i686-gentoo-freebsd7.2-2.95)   *2.95.3-r9 ~*2.95.3-r10!s
        (3.1)   *3.1.1-r2
        (i686-gentoo-freebsd7.2-3.2)    **3.2.2!s
        (3.2)   *3.2.3-r4
        (i686-gentoo-freebsd7.2-3.3)    ~3.3.6-r1!s
        (i686-gentoo-freebsd7.2-3.4)    3.4.6-r2!s
        (i686-gentoo-freebsd7.2-4.0)    ~*4.0.4!s
        (i686-gentoo-freebsd7.2-4.1)    4.1.2!s
        (i686-gentoo-freebsd7.2-4.2)    (~)4.2.4-r1!s
        (i686-gentoo-freebsd7.2-4.3)    4.3.2-r3!s (~)4.3.2-r4!s (~)4.3.3-r2!s 4.3.4!s
        (i686-gentoo-freebsd7.2-4.4)    (~)4.4.1!s (~)4.4.2!s (~)4.4.3!s
        {altivec bootstrap boundschecking build d doc fixed-point fortran gcj graphite gtk hardened ip28 ip32r10k java libffi mudflap multilib multislot n32 n64 nls nocxx nopie nossp nptl objc objc++ objc-gc openmp static test vanilla}                           
     Installed versions:  4.4.3(i686-gentoo-freebsd7.2-4.4)!s(18:50:37 22.03.2010)(fortran multilib nls nptl -altivec -bootstrap -build -doc -fixed-point -gcj -graphite -gtk -hardened -libffi -mudflap -multislot -n32 -n64 -nocxx -objc -objc++ -objc-gc -openmp -test -vanilla)                                                                                                                      
     Homepage:            http://gcc.gnu.org/
     Description:         The GNU Compiler Collection. Includes C/C++, java compilers, pie+ssp extensions, Haj Ten Brugge runtime bounds checking
Comment 6 Jeroen Roovers (RETIRED) gentoo-dev 2010-03-24 19:41:45 UTC
(In reply to comment #5)
> Are these settings somewhere stored ? I set up this crosscompile enviroment
> last year, so I don't know the settings anymore. At the moment the enviroment
> runs fine by masking freebsd-lib-8.0. But of course that is no sollution.

You can store them in
 /etc/portage/crossdev/arch-vendor-kernel-libc/{B,G,K,L}VER

where each of those files stores the exact version you want to use. The next run of crossdev on that same target should adhere to those versions.

> Maybe this can help:

No, that didn't help.
Comment 7 Henning Rogge 2010-03-27 10:44:49 UTC
If there is no way to reconstruct the settings of the crossdev script from the installed packages/files, the bug has to be closed again. I don't know the settings, I had to experiment for a few days before I got a running configuration because the examples on the webpages were a little bit outdated (they are for an older freebsd version).
Comment 8 Javier Villavicencio (RETIRED) gentoo-dev 2010-03-28 20:14:25 UTC
Hello,

I didn't work on crossdev compatibility originally, but I don't think you can crossdev-upgrade in this way. 

For starters, did crossdev installs freebsd-lib-8.0 first with the "crosscompile_opts_headers-only" useflag set?

Looking at the ebuild and your error log, it suggests that the ssp headers didn't get installed, which are part of the libc headers that get installed while creating the crossdev environment if I'm not mistaken.

I think you need to run, again:
crossdev -s4 --gcc 4.4.3 --libc '8.0*' --target i686-gentoo-freebsd8.0 --with-headers

To get the cross compile environment for i686-gentoo-freebsd8.0 created from scratch, and build the rest from there.

Basically, that error happens because on FreeBSD-8.0 the -fstack-protector flag for gcc is enabled by default, now that it's properly supported, but it requires the ssp headers and a libssp_nonshared.a static library to exist before being able to compile the libc, so, inside the ebuild, it's a two-step install/configure of the ssp-headers+libssp, libc-headers+libc. And this is mitigated by crossdev by first installing the headers and then compiling the library against those headers, if I understood how this works correctly.

Please let us know if you find further stoppers by doing this.
Comment 9 Henning Rogge 2010-03-29 15:43:34 UTC
Hmm... maybe we have a misunderstanding. I have NOT used the crossdev script anymore since I set up my FreeBSD enviroment last year. The new library that breaks the build just comes during a normal "emerge -uDN world" portage update.

Might this be the reason for the build breakage ?
Comment 10 Javier Villavicencio (RETIRED) gentoo-dev 2010-03-29 17:04:17 UTC
> Might this be the reason for the build breakage ?

Yep, that's most likely why. Say that you get normal upgrades on a normal linux crossdev environment for glibc and such, they won't change your CTARGET, so your crossdev environment remains the same.
Now, on FreeBSD, each release version is a different CHOST, and thus, to "upgrade" to the new CHOST, the entire toolchain has to be rebuilt, which in the crossdev case, would mean running the script again, for this brand new CTARGET.

Basically, you can't get a cross-i686-gentoo-freebsd8.0 environment upgrading from cross-i686-gentoo-freebsd7.2.

I'd think this happens because we cannot place the same dependency restrictions that we place on profiles/releases/freebsd-{7.2,8.0}/package.mask on the ebuilds generated by crossdev, so when it finds a new version it gets pulled regardless of the mask?
Comment 11 Henning Rogge 2010-03-30 19:35:07 UTC
I restored portage world update by putting this into my /etc/portage/package.mask file:

=cross-i686-gentoo-freebsd7.2/freebsd-lib-8.0
=sys-freebsd/freebsd-mk-defs-8.0

Maybe the crossdev script should put something similar into the masking file to prevent a cross-version update by portage ?
Comment 12 Javier Villavicencio (RETIRED) gentoo-dev 2010-04-01 08:39:32 UTC
I'm not the best one to ask that ^_^

@toolchain: ping?
Comment 13 SpanKY gentoo-dev 2010-04-02 08:49:36 UTC
i dont relish the idea of crossdev doing weird things based on specific package atoms ... is there really no other option ?
Comment 14 Henning Rogge 2010-04-02 09:07:34 UTC
I don't know.

The problem is that the crossdev script is creating a custom overlay by linking whole directories of the original portage tree. As soon as new packages appear in the original tree, they appear in the crossdev-overlay too and portage wants to update them.
Comment 15 SpanKY gentoo-dev 2010-04-02 18:28:33 UTC
i know what crossdev does since i wrote it.  i'm asking the BSD team for better ideas than having crossdev write custom masks.
Comment 16 Henning Rogge 2010-04-02 20:37:52 UTC
The script (and the crosscompiling enviroment it sets up) is really a great help for me. Testing if our routing agent still compiles for win32 or bsd was always a pain before I discovered it.
Comment 17 Javier Villavicencio (RETIRED) gentoo-dev 2010-04-03 04:15:06 UTC
(In reply to comment #13)
> i dont relish the idea of crossdev doing weird things based on specific package
> atoms ... is there really no other option ?
> 

To clarify, you mean that the ebuilds (mk-defs, libs, the two that allow for this to happen) block the upgrade themselves under crossdev?

Or for this upgrade path to work? (each new version has a different CHOST it shouldn't I'd think)
Comment 18 SpanKY gentoo-dev 2010-10-10 09:53:57 UTC
does this craziness of target version encoding apply only to freebsd ?  or do all *bsd's do this wacky s**t ?
Comment 19 Michał Górny archtester Gentoo Infrastructure gentoo-dev Security 2019-10-11 17:41:30 UTC
*-fbsd is gone.