Bugzilla Bug 193111

When trying to 'emerge -avuD world', windowmaker is supposed to upgrade from
0.92.0-r3 to -r4. The -r4 build fails at configure on my system. See attached
config.log.



Reproducible: Always

Steps to Reproduce:
1. emerge -avuD world, or emerge "=x11-wm/windowmaker-0.92.0-r4"


Actual Results:  
checking for C compiler default output file name... 
configure: error: C compiler cannot create executables
See `config.log' for more details.

Created an attachment (id=131326) [details]
config.log

And your `emerge --info`?

can you also post the output of "gcc-config -l"? I think emerge --info does
this, but id also like to see what different profiles of gcc you have. Thanks.

lian mopar # emerge --info
Portage 2.1.3.9 (default-linux/amd64/2007.0/desktop, gcc-4.1.2, glibc-2.5-r4,
2.6.22-gentoo-r6 x86_64)
=================================================================
System uname: 2.6.22-gentoo-r6 x86_64 Dual Core AMD Opteron(tm) Processor 185
Timestamp of tree: Wed, 19 Sep 2007 18:00:01 +0000
app-shells/bash:     3.2_p17
dev-java/java-config: 1.3.7, 2.0.33-r1
dev-lang/python:     2.4.4-r4, 2.5.1-r2
dev-python/pycrypto: 2.0.1-r6
sys-apps/baselayout: 1.12.9-r2
sys-apps/sandbox:    1.2.17
sys-devel/autoconf:  2.13, 2.61
sys-devel/automake:  1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r2, 1.10
sys-devel/binutils:  2.17-r1
sys-devel/gcc-config: 1.3.16
sys-devel/libtool:   1.5.24
virtual/os-headers:  2.6.21
ACCEPT_KEYWORDS="amd64"
CBUILD="x86_64-pc-linux-gnu"
CFLAGS="-march=opteron -pipe -O2"
CHOST="x86_64-pc-linux-gnu"
CONFIG_PROTECT="/etc /usr/kde/3.5/env /usr/kde/3.5/share/config
/usr/kde/3.5/shutdown /usr/share/X11/xkb /usr/share/config
/usr/share/texmf/dvipdfm/config/ /usr/share/texmf/dvips/config/
/usr/share/texmf/tex/generic/config/ /usr/share/texmf/tex/platex/config/
/usr/share/texmf/xdvi/"
CONFIG_PROTECT_MASK="/etc/env.d /etc/env.d/java/ /etc/gconf
/etc/php/apache2-php5/ext-active/ /etc/php/cgi-php5/ext-active/
/etc/php/cli-php5/ext-active/ /etc/revdep-rebuild /etc/terminfo
/etc/udev/rules.d"
CXXFLAGS="-march=opteron -pipe -O2"
DISTDIR="/usr/portage/distfiles"
FEATURES="buildpkg ccache distlocks fixpackages metadata-transfer sandbox
sfperms strict unmerge-orphans userfetch userpriv usersandbox"
GENTOO_MIRRORS="http://open-systems.ufl.edu/mirrors/gentoo
http://194.117.143.70 http://194.117.143.69
http://ftp.snt.utwente.nl/pub/os/linux/gentoo http://ftp.heanet.ie/pub/gentoo/"
LANG="en_US.utf8"
MAKEOPTS="-j2"
PKGDIR="/usr/portage/packages"
PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress
--force --whole-file --delete --delete-after --stats --timeout=180
--exclude=/distfiles --exclude=/local --exclude=/packages
--filter=H_**/files/digest-*"
PORTAGE_TMPDIR="/var/tmp"
PORTDIR="/usr/portage"
PORTDIR_OVERLAY="/usr/portage/local/layman/berkano /usr/local/portage"
SYNC="rsync://rsync.gentoo.org/gentoo-portage"
USE="3dnow 3dnowext X X509 a52 aac acl acpi aiglx alsa amd64 apache2 asf avi
bash-completion berkdb bitmap-fonts bzip2 cairo cdnow cdparanoia cdr cli
cpdflib cracklib crypt cups curl dba dbus dri dts dv dvb dvd dvdr dvdread eds
emacs emboss encode evo exif expat extrafilters faac faad fam fame ffmpeg fftw
firefox flac font-server fortran gd gdbm gif gimp gimpprint glitz gnome gnustep
gpac gphoto2 gpm gs gstreamer gtk gtkhtml hal iconv ieee1394 imagemagick ipv6
isdnlog jabber joystick jpeg kde kerberos ldap libnotify lirc live lzo mad
matroska mhash midi mikmod mjpeg mmx mmx2 mng mono mozilla mp3 mpeg mpeg4
mudflap musicbrainz mysql mythtv ncurses nptl nptlonly nss nvidia objc
offensive ogg oggvorbis openal opengl openmp oss pam pcre pda pdf pdfkit pdflib
perl pgstreamer php plotutils png pppd ptk2 python qt qt3 qt3support qt4
quicktime quotes readline recode reflection rtc scanner sdk sdl sensord session
smp speex spell spl sse sse2 ssl startup-notification svg tcpd tetex theora
threads tidy tiff transcode truetype truetype-fonts type1-fonts udev unicode
usb v4l2 vcd videos vorbis win32codec x264 xanim xine xml xorg xosd xpm xprint
xv xvid xvmc yv12 zlib" ALSA_CARDS="emu10k1" ALSA_PCM_PLUGINS="adpcm alaw asym
copy dmix dshare dsnoop empty extplug file hooks iec958 ioplug ladspa lfloat
linear meter mulaw multi null plug rate route share shm softvol" ELIBC="glibc"
INPUT_DEVICES="keyboard evdev mouse joystick wacom" KERNEL="linux"
LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses
text" LIRC_DEVICES="hauppauge" USERLAND="GNU" VIDEO_CARDS="nv"
Unset:  CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LC_ALL, LDFLAGS, LINGUAS,
PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS

lian mopar # gcc-config -l
 [1] x86_64-pc-linux-gnu-4.1.2 *

What happens when you try to compile a simple C hello world program with gcc?
Does it work?

Can you try that, and post the results,

also, can you do a revdep-rebuild and env-update and paste the contents of your
/etc/ld.so.conf

Can you also trying merging another package that uses C source code and the gcc
compiler and let us know the outcome? Thanks.

(In reply to comment #6)
> What happens when you try to compile a simple C hello world program with gcc?
> Does it work?
> 
> Can you try that, and post the results,

Yes it works. No errors.
A simple 'gcc hello.c' results in a functional a.out.

> also, can you do a revdep-rebuild and env-update and paste the contents of
> your /etc/ld.so.conf

revdep-rebuild has been run several times since I first ran into this problem
(several days ago). It finds no inconsistencies at this time.

# cat /etc/ld.so.conf
# ld.so.conf autogenerated by env-update; make all changes to
# contents of /etc/env.d directory
/usr/local/lib
//usr/lib32/opengl/nvidia/lib
//usr/lib64/opengl/nvidia/lib
/lib
/usr/lib
/lib64
/usr/lib64
/usr/local/lib64
/lib32
/usr/lib32
/usr/local/lib32
/usr/x86_64-pc-linux-gnu/lib
/usr/lib/gcc/x86_64-pc-linux-gnu/4.1.2
/usr/lib/gcc/x86_64-pc-linux-gnu/4.1.2/32
/usr/lib64/nspr
/usr/lib64/nss
/usr/lib32/openmotif-2.2
/opt/blackdown-jdk-1.4.2.03/jre/lib/amd64/
/opt/blackdown-jdk-1.4.2.03/jre/lib/amd64/native_threads/
/opt/blackdown-jdk-1.4.2.03/jre/lib/amd64/classic/
/opt/blackdown-jdk-1.4.2.03/jre/lib/amd64/server/
/usr/lib/qt4
/usr/lib64/qt4
/usr/lib32/qt4
/usr/kde/3.5/lib
/usr/kde/3.5/lib64
/usr/kde/3.5/lib32
/usr/qt/3/lib
/usr/qt/3/lib64
/usr/qt/3/lib32
/usr/games/lib
/usr/games/lib32
/usr/lib64/fltk-1.1
/usr/lib/libffi
/usr/lib/libstdc++-v3/

> Can you also trying merging another package that uses C source code and the gcc
> compiler and let us know the outcome?

When I first ran into this issue on my system, windowmaker was buried in a long
list of packages to be updated by 'emerge -avuD world'. All of the packages
before it built without issue. It then appeared as the first in the list to be
updated, so any 'emerge -avuD world' bombs out before anything else can be
built, but I have emerged all of the other packages explicitly without issue,
so that this ebuild of windowmaker is the only thing that appears when trying
to emerge world.

> Thanks.

No. Thank you...

Its kinda funny that everything else built but this package, and I'm quite sure
I followed all of the directions for upgrading gcc (which I did some months
ago, with numerous world emerges since), but I am going through each step
again, including 'emerge -eav system', then world, just to make sure everything
it as it should be. As you can imagine, it will be a while before I can report
back...

By looking at a null LIBTOOL variable, maybe something is wrong with the
libtool configuration. Can you try merging sys-devel/libtool again?

It should look something like this:
LIBTOOL='$(SHELL) $(top_builddir)/libtool'

(In reply to comment #8)
> By looking at a null LIBTOOL variable, maybe something is wrong with the
> libtool configuration. Can you try merging sys-devel/libtool again?
> 
> It should look something like this:
> LIBTOOL='$(SHELL) $(top_builddir)/libtool'
> 

I think you're on to something (like I would know).

After the "emerge -eav system", which included libtool, the ebuild of
windowmaker still failed in the same manner. The config.log still showed
LIBTOOL=''.

But, if I untarred the original source package, and ran the same configure
command that the ebuild generated, it steps through configure just fine, and
the config.log shows "LIBTOOL='$(SHELL) $(top_builddir)/libtool'".

So then I manually applied the patches from the ebuild and reran the same
configure. Again, it configures fine.

Next, I ran 'emerge windowmaker' and Ctrl-C'd it after the patches, but before
"Running aclocal ..." finished. Went to the work directory, and again, it
configured fine.

I then let 'emerge windowmaker' run until failure, then went to the work
directory and ran configure, still using the ebuild-generated configure
options. Again, it configures fine manually.

So, maybe LIBTOOL (and other things?) are getting lost somewhere in these
emerge  steps?
 * Running aclocal ...                                                    [ ok
]
 * Running autoconf ...                                                   [ ok
]
 * Running autoheader ...                                                 [ ok
]
 * Running automake --add-missing --copy ...                              [ ok
]
 * Running elibtoolize in: WindowMaker-0.92.0
 *   Applying install-sh-1.5.patch ...
 *   Applying portage-1.5.10.patch ...
 *   Applying sed-1.5.6.patch ...
>>> Source unpacked.
>>> Compiling source in /var/tmp/portage/x11-wm/windowmaker-0.92.0-r4/work/WindowMaker-0.92.0 ...
 * econf: updating WindowMaker-0.92.0/config.guess with
/usr/share/gnuconfig/config.guess
 * econf: updating WindowMaker-0.92.0/config.sub with
/usr/share/gnuconfig/config.sub


I am sure I am just muddying the waters, as I obviously don't know what I'm
doing, but -r3 still builds fine, and I did notice a difference in that -r3
results in 

Window Maker was configured as follows:

Installation path prefix            : /usr
Installation path for binaries      : /usr/bin
Installation path for WPrefs.app    : /usr/GNUstep/Local/Applications
Supported graphic format libraries  : XPM PNG JPEG GIF TIFF builtin-PPM
Use assembly routines for wrlib     : yes
Use inline MMX(tm) x86 assembly     : yes
Antialiased text support in WINGs   : yes
Xinerama extension support          : no
Translated message files to install : None

while the manual running of the ebuild-generated configure in the work
directory, although it succeeds, results in:

Installation path prefix            : /usr
Installation path for binaries      : /usr/bin
Installation path for WPrefs.app    : /Applications
Supported graphic format libraries  : XPM PNG JPEG GIF TIFF builtin-PPM
Use assembly routines for wrlib     : no
Use inline MMX(tm) x86 assembly     : no
Antialiased text support in WINGs   : yes
Xinerama extension support          : no
Translated message files to install : None

I don't know if the loss of assembly support means anything...

I wasn't exactly clear. The last part where assembly support is lost was from
running the ebuild-generated configure command in the work directory of -r4.

configure:3074: x86_64-pc-linux-gnu-gcc -march=opteron -pipe -O2   -Wl,-rpath=
-L conftest.c  >&5

i dont know where GNUSTEP_SYSTEM_LIBRARIES gets set, but it isnt by the
toolchain

I don't know what the exact cause was, especially since -r3 built fine, but I
went ahead and unmerged all gnustep packages, and emerged just
gnustep-make-2.0.1.

-r4 now builds on my system without problem.

Before I installed gnustep-make, I had removed gnustep from USE (in make.conf).
When this was done, an 'emerge windowmaker' failed to build, saying that
gnustep-make was not installed, but it didn't try to pull it in as a
dependency. Adding gnustep back to USE, 'emerge windowmaker' then pulled in
gnustep-make.

So, it appears that the windowmaker -r4 ebuild requires gnustep-make (of some
relatively recent version) whether or not the gnustep USE flag is set, but
won't automatically pull it in unless the gnustep flag is set.

In addition, if I revert back to gnustep-make-1.12.0-r1 or 1.13.0,
windowmaker-0.92.0-r4 again fails to build as originally described.

Maybe the ebuild should be changed to require gnustep-make-2.0.1 regardless of
whether the gnustep USE flag is set or not? Only on amd64? Only on my machine?

Thanks all.

windowmaker-0.92.0-r4 fixed, gnustep-make depend bumped to 2.0, and fixed a
gnustep-specific call that was not in a "if USE=gnustep" block. Thanks for the
report!

As for GNUSTEP_SYSTEM_LIBRARIES, it it set when gnustep-make is available on
the system, this was probably caused by an old version on your system. As the
depend is now at least 2.0, this is also fixed

Closing as everything is fixed now