Mdadm has hardcoded compilator - gcc. I've checked mdadm-3.0 and 3.1.4, probably all version has the same issue. Reproducible: Always emerge --info Portage 2.1.9 (default/linux/amd64/10.0/desktop, gcc-4.4.4, glibc-2.12.1-r1, 2.6.35-zen2 x86_64) ================================================================= System uname: Linux-2.6.35-zen2-x86_64-Intel-R-_Celeron-R-_CPU_E1500_@_2.20GHz-with-gentoo-2.0.1 Timestamp of tree: Mon, 06 Sep 2010 06:00:01 +0000 ccache version 2.4 [enabled] app-shells/bash: 4.1_p7 dev-lang/python: 2.6.5-r3, 3.1.2-r4 dev-util/ccache: 2.4-r8 dev-util/cmake: 2.8.1-r2 sys-apps/baselayout: 2.0.1 sys-apps/openrc: 0.6.3 sys-apps/sandbox: 2.3-r1 sys-devel/autoconf: 2.13, 2.65-r1 sys-devel/automake: 1.8.5-r4, 1.9.6-r3, 1.10.3, 1.11.1 sys-devel/binutils: 2.20.1-r1 sys-devel/gcc: 4.4.4-r1 sys-devel/gcc-config: 1.4.1 sys-devel/libtool: 2.2.10 sys-devel/make: 3.81-r2 virtual/os-headers: 2.6.35 (sys-kernel/linux-headers) ACCEPT_KEYWORDS="amd64 ~amd64" ACCEPT_LICENSE="* -@EULA AdobeFlash-10.1 PUEL Q3AEULA skype-eula dlj-1.1" CBUILD="x86_64-pc-linux-gnu" CFLAGS="-O2 -march=native -pipe" CHOST="x86_64-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/share/X11/xkb /usr/share/config" CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/env.d /etc/eselect/postgresql /etc/fonts/fonts.conf /etc/gconf /etc/gentoo-release /etc/portage /etc/revdep-rebuild /etc/sandbox.d /etc/terminfo" CXXFLAGS="-O2 -march=native -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="assume-digests ccache collision-protect distlocks fixlafiles fixpackages news parallel-fetch protect-owned sandbox sfperms strict unknown-features-warn unmerge-logs unmerge-orphans userfetch" GENTOO_MIRRORS="http://distfiles.gentoo.org" LANG="pl_PL" LC_ALL="pl_PL.utf8" LDFLAGS="-Wl,-O1 -Wl,--as-needed" LINGUAS="pl en es es_ES" MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_CONFIGROOT="/" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --stats --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage /usr/local/portage/layman/sunrise /usr/local/portage/miro-overlay/portage /usr/local/portage/miro-overlay/in_sunrise /usr/local/portage/miro-overlay/staging" SYNC="rsync://192.168.138.254/gentoo-portage" USE="64bit X a52 aac acl acpi alsa amd64 async bash-completion bfq bittorrent branding bzip2 cairo caps cdr chroot cli consolekit cracklib crypt cups cxx dbus dmx dri dts dvd dvdr emboss encode exif fam firefox flac fortran ftp gd gif gpm graphite gstreamer hal iconv idn iproute2 ipv6 ithreads jpeg kde lcms libnotify lightning logrotate mad mikmod mmap mmx mmxext mng modules mp3 mp4 mpeg mudflap multilib ncurses network-cron nls nptl nptlonly nsplugin nspluginwrapper objc ogg opengl openmp openssl optimization optimized-qmake pam pango pch pcre pdf perl phonon png ppds pppd python qt3support qt4 readline reflection samba sdl semantic-desktop session sharedmem smp spell spl sse sse2 sse3 ssl ssse3 startup-notification svg sysfs threads threadsafe tiff tools truetype unicode urandom usb vim vim-pager vim-syntax vim-with-x vorbis x264 xattr xcb xinerama xml xorg xulrunner xv xvid zip zlib" ALSA_CARDS="ali5451 als4000 atiixp atiixp-modem bt87x ca0106 cmipci emu10k1x ens1370 ens1371 es1938 es1968 fm801 hda-intel intel8x0 intel8x0m maestro3 trident usb-audio via82xx via82xx-modem ymfpci" ALSA_PCM_PLUGINS="adpcm alaw asym copy dmix dshare dsnoop empty extplug file hooks iec958 ioplug ladspa lfloat linear meter mmap_emul mulaw multi null plug rate route share shm softvol" APACHE2_MODULES="actions alias auth_basic authn_alias authn_anon authn_dbm authn_default authn_file authz_dbm authz_default authz_groupfile authz_host authz_owner authz_user autoindex cgid dav deflate dir env expires ext_filter filter headers include info log_config logio mime mime_magic negotiation rewrite setenvif speling status unique_id usertrack vhost_alias" APACHE2_MPMS="worker" ELIBC="glibc" INPUT_DEVICES="keyboard mouse" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LINGUAS="pl en es es_ES" RUBY_TARGETS="ruby18" USERLAND="GNU" VIDEO_CARDS="intel nvidia" XTABLES_ADDONS="quota2 psd pknock lscan length2 ipv4options ipset ipp2p iface geoip fuzzy condition tee tarpit sysrq steal rawnat logmark ipmark dhcpmac delude chaos account" Unset: CPPFLAGS, CTARGET, EMERGE_DEFAULT_OPTS, FFLAGS, INSTALL_MASK, PORTAGE_BUNZIP2_COMMAND, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS
post an actual build log as an attachment showing the problem in ~arch
Created attachment 246296 [details] build.log
Created attachment 246298 [details] enviroment
Created attachment 246299 [details] emerge --info
I've attached new emerge --info, this thre attachments was created on another host than previous.
mdadm doesnt invoke the C++ compiler, so CXX is irrelevant. the ebuild already makes sure that $CHOST is respected, so that covers the majority of cases (like cross-compiling).
Created attachment 258297 [details, diff] mdadm-3.1.4.ebuild-CC-CFLAGS-tests.patch This patch fixes the complaint about CC being ignored. The CROSS_COMPILE var fixes most cross-compilation cases, but it doesn't cover portage-multilib people who need to use ${CC} ${CFLAGS}, where CFLAGS=-m32 gets them 32-bit instead of CC=i686-pc-linux-gnu-gcc. Thus, I am also attaching a patch which adds ${CFLAGS} to the linking stage for mdadm and mdmon which fixes compilation on portage-multilib. Also, I noticed that tests got compiled but never run. Thus, I added code to compile the tests with CC (the tests were not even compiled with CROSS_COMPILE before this patch). However, these tests require root access to be run... and running tests which fiddle around with md devices through loop devices as the tests claim to do seems a little potentially dangerous to me, so I added a RESTRICT=tests line. This fixes the extraneous compilation. Sorry to put all of these fixes together, but it'd be a pain to separate them out. I can fork out src_test() to another bug if really necessary... but I think that the CFLAGS patch is closely tied enough to CC to be fixed here.
Created attachment 258298 [details, diff] mdadm-3.1.4-cflags.patch
Nathan, are do CFLAGS really matter when linking only? What flag would make a difference that doesn't actually belong into LDFLAGS?
(In reply to comment #9) > Nathan, are do CFLAGS really matter when linking only? What flag would make a > difference that doesn't actually belong into LDFLAGS? During compilation, the linker is only to be accessed indirectly through the compiler driver, such as gcc or g++. There are options that the compiler driver understands which apply to all situations where the compiler driver is called. One example of such an option, depended upon by portage-multilib, is CFLAGS=-m32. During the linking phase, this causes gcc to send -melf_i386 to the linker instead of letting the linker use its default of -melf_x86_64 (using the amd64 platform as an example). CFLAGS=-m32 doesn't only apply to the linking stage -- it's also used by gcc when calling (I think) cc1 so that 32-bit object files are created. Thus, there is no reason to set LDFLAGS=-m32 because the -m32 flag isn't specific to linking. I suppose that there could be other flags with a similar scenario, but I'll admit that respecting CFLAGS during linking is a little specific to portage-multilib.
people are often lazy and stick flags that select multilib options in CFLAGS but not LDFLAGS
Nathan, thanks for that explanation. It looks like this bugs is a combination of three requests with patch proposals: - respect CC variable - respect CFLAGS even when linking - integrate src_test() into ebuild SpanKY, to which of those patches do you object? Shall we split the bug somehow?
(In reply to comment #11) > people are often lazy and stick flags that select multilib options in CFLAGS > but not LDFLAGS Does this mean that you suggest that we populate LDFLAGS with the "-m32" just like we populate the CFLAGS variable? I would prefer not to do this, as it is already the convention of POSIX make, automake, and many proprietary buildsystems to pass CFLAGS to CCLD when linking. Avoiding redundant flags may just be a question of aesthetics, I suppose...
i didnt say i objected to any patch (i didnt look at any) the CFLAGS patch is fine, but the ebuild patch doesnt look quite right. you implement src_test just to RESTRICT it ? if you're going to duplicate the `emake` args, then make a dedicated function: mdadm_emake() { emake ..vars... "$@" ; } also, drop the comment in the src_compile
CFLAGS at link time is up for debate. default make rules doesnt do it. so yes, if you want to avoid having to patch a large number of random packages out there, it'd be better to stick all flags that have link time implications into LDFLAGS too. like -m32 or -mcpu=... or -fopenmp or ...
Created attachment 259750 [details, diff] mdadm-3.1.4.ebuild-CC-CFLAGS-tests.patch (In reply to comment #14) > the CFLAGS patch is fine, but the ebuild patch doesnt look quite right. you > implement src_test just to RESTRICT it ? if you're going to duplicate the > `emake` args, then make a dedicated function: Here's the dedicated function. I created the src_test function because with the current state of the function, the test binaries are built but not run. Thus, if there is a compilation error in there relating to CFLAGS or CC, that's likely to break. I restricted them because they look slightly invasive and I don't want to play around with them and possibly mess up my system. If someone else wants to fix it up, my src_test() function is better than the default src_test() function. (In reply to comment #15) > CFLAGS at link time is up for debate. default make rules doesnt do it. so > yes, if you want to avoid having to patch a large number of random packages out > there, it'd be better to stick all flags that have link time implications into > LDFLAGS too. like -m32 or -mcpu=... or -fopenmp or ... Yes, I was wrong about implicit make rules from the POSIX manpage... those rules don't ever take a .o file and link it. But, it seems useful to move things to use CFLAGS + LDFLAGS if there are flags such as -mcpu and -fopenmp which must be also specified during linker time. Most packages already do this... and with my patch on bug 351384 I'm starting to see cases where CFLAGS is forgotten -- even not during the linker phase.
i dislike the "${@}" style ... please drop the braces looking at the test script, it does create temp files and tries to find free loop devices to operate on, but it tweaks a few runtime parameters in /proc/ and then operates on all arrays. so it would probably be dangerous to execute on a system that actually has raids in use. if you didnt have any, then it probably is fine. so move & update the comment to the RESTRICT="test" line (and add quotes to that). then things should be fine for committing.
Created attachment 259757 [details, diff] updated patch against ebuild OK, I think that I've covered all of your suggestions. Thanks :-).
add this bug url to that patch and feel free to commit things
Created attachment 259763 [details, diff] patch against ebuild; with bug number on the epatch() line
added to cvs, thanks
Thanks for fix.
