Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 82470 - MailX won't compile amd64
Summary: MailX won't compile amd64
Status: RESOLVED FIXED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: New packages (show other bugs)
Hardware: AMD64 All
: High normal (vote)
Assignee: AMD64 Project
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2005-02-18 09:02 UTC by Aaron Rusnak
Modified: 2005-03-05 12:01 UTC (History)
1 user (show)

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


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Aaron Rusnak 2005-02-18 09:02:43 UTC
gcc -D_BSD_SOURCE -DDEBIAN -g -Wall -IEXT -march=k8 -O2 -pipe -fomit-frame-pointer -c EXT/vis.c -o EXT/vis.o
gcc -s -o mail version.o aux.o cmd1.o cmd2.o cmd3.o cmdtab.o collect.o edit.o fio.o getname.o head.o v7.local.o lex.o list.o main.o names.o popen.o quit.o send.o strings.o temp.o tty.o vars.o EXT/strlcat.o EXT/strlcpy.o EXT/vis.o -llockfile
/usr/lib/gcc/x86_64-pc-linux-gnu/3.4.3/../../../../x86_64-pc-linux-gnu/bin/ld: cannot find -llockfile
collect2: ld returned 1 exit status
make: *** [mail] Error 1

!!! ERROR: mail-client/mailx-8.1.2.20040524-r1 failed.
!!! Function src_compile, Line 36, Exitcode 2
!!! (no error message)
!!! If you need support, post the topmost build error, NOT this status message.

emerge info:

Portage 2.0.51-r15 (default-linux/amd64/2005.0, gcc-3.4.3, glibc-2.3.4.20041102-r0, 2.6.10-gentoo-r7 x86_64)
=================================================================
System uname: 2.6.10-gentoo-r7 x86_64 AMD Athlon(tm) 64 Processor 3200+
Gentoo Base System version 1.6.9
Python:              dev-lang/python-2.3.4-r1 [2.3.4 (#1, Feb 15 2005, 17:46:33)]
distcc 2.18.3 x86_64-pc-linux-gnu (protocols 1 and 2) (default port 3632) [disabled]
ccache version 2.3 [enabled]
dev-lang/python:     2.3.4-r1
sys-devel/autoconf:  2.13, 2.59-r6
sys-devel/automake:  1.8.5-r3, 1.5, 1.7.9-r1, 1.6.3, 1.4_p6, 1.9.4
sys-devel/binutils:  2.15.92.0.2-r1
sys-devel/libtool:   1.5.10-r4
virtual/os-headers:  2.6.8.1-r4
ACCEPT_KEYWORDS="amd64"
AUTOCLEAN="yes"
CFLAGS="-march=k8 -O2 -pipe -fomit-frame-pointer"
CHOST="x86_64-pc-linux-gnu"
CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3.4/env /usr/kde/3.4/share/config /usr/kde/3.4/shutdown /usr/kde/3/share/config /usr/lib/X11/xkb /usr/share/config /var/qmail/control"
CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d"
CXXFLAGS="-march=k8 -O2 -pipe -fomit-frame-pointer"
DISTDIR="/usr/portage/distfiles"
FEATURES="autoaddcvs autoconfig ccache distlocks"
GENTOO_MIRRORS="ftp://ftp.ucsb.edu/pub/mirrors/linux/gentoo/"
MAKEOPTS="-j2"
PKGDIR="/usr/portage/packages"
PORTAGE_TMPDIR="/var/tmp"
PORTDIR="/usr/portage"
PORTDIR_OVERLAY="/usr/local/portage"
SYNC="rsync://rsync.gentoo.org/gentoo-portage"
USE="amd64 X acpi alsa arts berkdb bitmap-fonts ccache cdparanoia cdr crypt cups curl dvd dvdr encode ethereal f77 fam flac foomaticdb fortran gif gimpprint gtk gtk2 hpijs imagemagick jp2 jpeg kde lzw lzw-tiff motif ncurses nls nptl nptlonly nvidia offensive ogg oggvorbis opengl oss perl pic png postfix prelink python qt readline samba slp spell ssl svg tcpd tiff truetype truetype-fonts type1-fonts usb userlocales xine xinerama xml2 xorg xpm xrandr xv zlib"
Unset:  ASFLAGS, CBUILD, CTARGET, LANG, LC_ALL, LDFLAGS
Comment 1 Tuan Van (RETIRED) gentoo-dev 2005-02-18 09:38:08 UTC
amd64 specific, reassign.
Comment 2 Aaron Rusnak 2005-02-19 16:31:48 UTC
Well, i think i've figured it out. net-libs/liblockfile-1.0.3-r1 is a dependency of mailx. When that package is merged, the /usr/lib64 symlink gets replaced with some file, which file calls a "current ar archive", and since that symlink gets replaced with that file, /usr/lib64/liblockfile.so.1.0
 /usr/lib64/liblockfile.so -> liblockfile.so.1.0 either don't get created or are merged into that strange /usr/lib64 file that gets created from the ebuild or whatever. Here is the output of merging liblockfile-1.0.3-r1:

>>> Completed installing liblockfile-1.03-r1 into /var/tmp/portage/liblockfile-1.03-r1/image/

>>> Merging net-libs/liblockfile-1.03-r1 to /
--- /usr/
--- /usr/bin/
>>> /usr/bin/dotlockfile
--- /usr/include/
>>> /usr/include/lockfile.h
>>> /usr/include/maillock.h
--- /usr/lib/
--- /usr/share/
--- /usr/share/man/
--- /usr/share/man/man1/
>>> /usr/share/man/man1/dotlockfile.1.gz
--- /usr/share/man/man3/
>>> /usr/share/man/man3/maillock.3.gz
>>> /usr/share/man/man3/lockfile_create.3.gz
>>> /usr/lib64
>>> Regenerating /etc/ld.so.cache...
 * Caching service dependencies ...                                          [ ok ]
>>> net-libs/liblockfile-1.03-r1 merged.

After that, I have to unmerge liblockfile-1.03-r1, rm the /usr/lib64 file, and re-create the symlink to /usr/lib64 --> /usr/lib. If I unmask liblockfile-1.03-r2, and emerge it, all is well it seems : 

>>> Merging net-libs/liblockfile-1.03-r2 to /
--- /usr/
--- /usr/bin/
>>> /usr/bin/dotlockfile
--- /usr/include/
>>> /usr/include/lockfile.h
>>> /usr/include/maillock.h
--- /usr/lib64/
>>> /usr/lib64/liblockfile.so.1.0
>>> /usr/lib64/liblockfile.so -> liblockfile.so.1.0
--- /usr/share/
--- /usr/share/man/
--- /usr/share/man/man1/
>>> /usr/share/man/man1/dotlockfile.1.gz
--- /usr/share/man/man3/
>>> /usr/share/man/man3/maillock.3.gz
>>> /usr/share/man/man3/lockfile_create.3.gz
>>> Regenerating /etc/ld.so.cache...
 * Caching service dependencies ...                                          [ ok ]
>>> net-libs/liblockfile-1.03-r2 merged.

and mailx compiles and installs and works fine. I didn't install liblockfile-1.03-r1 in the first place because I am running a mostly stable system, and since it was only a dep of mailx, I just let it install the stable 1.03-r1 that portage wanted to install. I guess you could mark this as fixed, but I seem to have introduced another but. I've been talking about it at http://bugs.gentoo.org/show_bug.cgi?id=82304 because I was following a different bug as liblockfile-1.03-r1 seemed to render my system unusable because of overwriting the /usr/lib64 symlink. Should I open up a new bug? or wait to see what happens at bug 82304?
Comment 3 Simon Stelling (RETIRED) gentoo-dev 2005-03-05 11:56:48 UTC
Aaron, thanks a lot for pointing that out. could you open a new bug and set the severity to blocker? this is really a critical bug. please also CC amd64@gentoo.org

tia
Comment 4 Simon Stelling (RETIRED) gentoo-dev 2005-03-05 12:00:25 UTC
ok, forget my last comment:

KEYWORDS="x86 ppc sparc alpha hppa ia64 -amd64 ~mips ppc64"

it's already "fixed"
Comment 5 Simon Stelling (RETIRED) gentoo-dev 2005-03-05 12:01:26 UTC
grml, forget RESOLVED FIXED