[gentoo-user] Build problems due to invalid libtool arguments

[gentoo-user] Build problems due to invalid libtool arguments

[Alex Schuster]

Hi there!

I'm currently upgrading my little sister's PC from an x86 Sempron to an
x86_64 AMDS A6 processor. So Gentoo is being installed from scratch.

But some packages fail to build. I filed a bug [1] for
media-libs/libggi-2.2.2, but a similar problem is happening for
pygtksourceview now, and I do not find a simple workaround.

The problem is that in the libtool linking phase the arguments "/usr/bin
/usr/sbin /bin /sbin" are given along the libraries and library paths. I
have no idea why this happens, and how to solve this. Something must be
wrong on my system. But what? For libggi, emerging with USE=-aalib sort
of solved this. But I have no idea what to do about pygtksourceview. As
all gthe KDE stuff seems to depend on this, I cannot continue

Here's the end of the build log. Look at the line I marked with a (***).

libtool: link: echo "{ global:" > .libs/libggi.ver
libtool: link: cat ./EXPSYMS | sed -e "s/\(.*\)/\1;/" >> .libs/libggi.ver
libtool: link: echo "local: *; };" >> .libs/libggi.ver
libtool: link: x86_64-pc-linux-gnu-gcc -shared  .libs/builtins.o
.libs/colormap.o .libs/db.o .libs/dl.o .libs/events.o .libs/ext.o
.libs/gc.o .libs/init.o .libs/internal.o .libs/mode.o .libs/probe.o
.libs/stubs.o .libs/swar.o .libs/unix.o .libs/visual.o
-Wl,--whole-archive ../display/auto/.libs/libauto.a
../default/stubs/.libs/libstubs.a
../default/pseudo_stubs/.libs/libpseudo_stubs.a
../default/color/.libs/libcolor.a ../default/text_16/.libs/libtext_16.a
../default/text_32/.libs/libtext_32.a
../default/linear_1/.libs/liblinear_1.a
../default/linear_16/.libs/liblinear_16.a
../default/linear_1_r/.libs/liblinear_1_r.a
../default/linear_2/.libs/liblinear_2.a
../default/linear_24/.libs/liblinear_24.a
../default/linear_32/.libs/liblinear_32.a
../default/linear_4/.libs/liblinear_4.a
../default/linear_4_r/.libs/liblinear_4_r.a
../default/linear_8/.libs/liblinear_8.a
../default/planar/.libs/libplanar.a ../default/ilbm/.libs/libilbm.a
../default/iplanar_2p/.libs/libiplanar_2p.a
../default/fbdev/mga/2164w/.libs/libm2164w.a
../default/fbdev/mga/g400/.libs/libmga_g400.a
../default/fbdev/ati/mach64/.libs/libmach64.a
../display/aa/.libs/libaa.a ../display/fbdev/.libs/libfbdev.a
../display/file/.libs/libfile.a ../display/ipc/.libs/libipc.a
../display/linvtsw/.libs/liblinvtsw.a
../display/mansync/.libs/libmansync.a
../display/memory/.libs/libmemory.a
../display/monotext/.libs/libmonotext.a
../display/multi/.libs/libmulti.a ../display/palemu/.libs/libpalemu.a
../display/sub/.libs/libsub.a ../display/tele/.libs/libtele.a
../display/terminfo/.libs/libterminfo.a ../display/tile/.libs/libtile.a
../display/trueemu/.libs/libtrueemu.a ../display/vcsa/.libs/libvcsa.a
../display/X/.libs/libx.a
../display/X/helper/dbe/.libs/libhelper_x_dbe.a
../display/X/helper/dga/.libs/libhelper_x_dga.a
../display/X/helper/evi/.libs/libhelper_x_evi.a
../display/X/helper/shm/.libs/libhelper_x_shm.a
../display/X/helper/vidmode/.libs/libhelper_x_vidmode.a
-Wl,--no-whole-archive  -L/usr/lib /usr/lib64/libaa.so /usr/bin    (***)
/usr/sbin /bin /sbin -lm -lncurses -lXxf86vm /usr/lib64/libgii.so
-L/usr/lib64 -lX11 -lXxf86dga -lXext /usr/lib64/libgg.so -ldl -lpthread
-lc  -march=native -msse -msse2 -msse3 -m3dnow -Wl,-O1 -Wl,--as-needed
-Wl,-soname -Wl,libggi.so.2 -Wl,-version-script -Wl,.libs/libggi.ver -o
.libs/libggi.so.2.0.2
/usr/bin: file not recognized: Is a directory


leela / # emerge --info libggi
/usr/lib64/portage/pym/portage/package/ebuild/config.py:353:
UserWarning: 'cache.metadata_overlay.database' is deprecated:
/etc/portage/modules
  (user_auxdbmodule, modules_file))
Portage 2.2.0_alpha83 (default/linux/amd64/10.0/desktop/kde, gcc-4.5.3,
glibc-2.13-r4, 3.0.13-std241-amd64 x86_64)
=================================================================
                        System Settings
=================================================================
System uname:
Linux-3.0.13-std241-amd64-x86_64-AMD_A6-3500_APU_with_Radeon-tm-_HD_Graphics-with-gentoo-2.0.3
Timestamp of tree: Sun, 25 Dec 2011 22:15:01 +0000
app-shells/bash:          4.1_p9
dev-java/java-config:     2.1.11-r3
dev-lang/python:          2.7.2-r3, 3.1.4-r3
dev-util/cmake:           2.8.6-r4
dev-util/pkgconfig:       0.26
sys-apps/baselayout:      2.0.3
sys-apps/openrc:          0.9.4
sys-apps/sandbox:         2.5
sys-devel/autoconf:       2.13, 2.68
sys-devel/automake:       1.11.1
sys-devel/binutils:       2.21.1-r1
sys-devel/gcc:            4.5.3-r1
sys-devel/gcc-config:     1.4.1-r1
sys-devel/libtool:        2.4-r1
sys-devel/make:           3.82-r1
sys-kernel/linux-headers: 2.6.39 (virtual/os-headers)
sys-libs/glibc:           2.13-r4
Repositories: gentoo zugaina local
Installed sets:
ACCEPT_KEYWORDS="amd64"
ACCEPT_LICENSE="* -@EULA"
CBUILD="x86_64-pc-linux-gnu"
CFLAGS="-march=native -msse -msse2 -msse3 -m3dnow -pipe"
CHOST="x86_64-pc-linux-gnu"
CONFIG_PROTECT="/etc /usr/share/config /usr/share/gnupg/qualified.txt
/usr/share/openvpn/easy-rsa"
CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/env.d
/etc/env.d/java/ /etc/fonts/fonts.conf /etc/gconf /etc/gentoo-release
/etc/revdep-rebuild /etc/sandbox.d /etc/terminfo /usr/share/X11/xkb"
CXXFLAGS="-march=native -msse -msse2 -msse3 -m3dnow -pipe"
DISTDIR="/var/portage/distfiles"
EMERGE_DEFAULT_OPTS="--with-bdeps y --keep-going --load-average=3.5"
FEATURES="assume-digests binpkg-logs buildsyspkg collision-protect
distlocks ebuild-locks fixlafiles news parallel-fetch preserve-libs
protect-owned sandbox sfperms strict unknown-features-warn unmerge-logs
unmerge-orphans userfetch userpriv usersandbox"
FFLAGS=""
GENTOO_MIRRORS="rsync://mirror.netcologne.de/gentoo/
ftp://ftp.snt.utwente.nl/pub/os/linux/gentoo
http://91.121.124.139/gentoo-distfiles/
http://ftp-stud.hs-esslingen.de/pub/Mirrors/gentoo/"
LANG="en_US.UTF-8"
LDFLAGS="-Wl,-O1 -Wl,--as-needed"
LINGUAS="de"
MAKEOPTS="-j4"
PKGDIR="/var/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/portage/tmp"
PORTDIR="/var/portage/tree"
PORTDIR_OVERLAY="/var/portage/layman/zugaina /var/portage/local"
SYNC="rsync://rsync.europe.gentoo.org/gentoo-portage"
USE="3dnow X a52 aac aalib acl acpi aim alsa amd64 apm audiofile
bash-completion berkdb bluetooth branding bzip2 cairo cdda cddb cdr cli
consolekit cracklib crypt cups cxx dbus declarative dga dio dri dts dvd
dvdr dvdread emboss encode exif fam fbcon ffmpeg firefox flac foomaticdb
ftp gd gdbm gdu ggi gif gimp gphoto2 gpm gtk handbook iconv imagemagick
imlib ipv6 jabber java javascript jpeg jpeg2k kde kipi lame lcms ldap
libnotify lm_sensors mad mikmod mime mmx mng modules motif mozbranding
mp3 mp4 mpeg mplayer msn mudflap multilib musicbrainz ncurses nls nptl
nptlonly nsplugin ogg openal opengl openmp oss pam pango pcre pdf phonon
plasma png policykit ppds pppd qt3support qt4 quicktime readline recode
samba scanner sdl semantic-desktop session sid sndfile sox speex spell
sse sse2 ssl startup-notification svg sysfs tcpd tiff truetype udev
unicode usb v4l videos visualization vorbis wma wmf x264 xcb xcomposite
xine xinerama xml xorg xscreensaver xulrunner xv xvid zlib"
ALSA_CARDS="es1371" 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 cache cgi
cgid dav dav_fs dav_lock deflate dir disk_cache env expires ext_filter
file_cache filter headers include info log_config logio mem_cache mime
mime_magic negotiation rewrite setenvif speling status unique_id userdir
usertrack vhost_alias" CALLIGRA_FEATURES="kexi words flow plan stage
tables krita karbon braindump" CAMERAS="ptp2" COLLECTD_PLUGINS="df
interface irq load memory rrdtool swap syslog" ELIBC="glibc"
GPSD_PROTOCOLS="ashtech aivdm earthmate evermore fv18 garmin garmintxt
gpsclock itrax mtk3301 nmea ntrip navcom oceanserver oldstyle oncore
rtcm104v2 rtcm104v3 sirf superstar2 timing tsip tripmate tnt ubx"
INPUT_DEVICES="keyboard mouse" KERNEL="linux" LCD_DEVICES="bayrad cfontz
cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LINGUAS="de"
PHP_TARGETS="php5-3" RUBY_TARGETS="ruby18" USERLAND="GNU"
VIDEO_CARDS="radeon" 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, INSTALL_MASK, LC_ALL,
PORTAGE_BUNZIP2_COMMAND, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS,
PORTAGE_RSYNC_EXTRA_OPTS

=================================================================
                        Package Settings
=================================================================

media-libs/libggi-2.2.2 was built with the following:
USE="X (consolekit) fbcon mmx (multilib) (policykit) (-3dfx) -aalib
-debug -directfb (-svga) (-vis)"

Any ideas about this?

[1] http://bugs.gentoo.org/show_bug.cgi?id=396083

	Wonko

Re: [gentoo-user] Build problems due to invalid libtool arguments

[Alex Schuster]

I wrote:

> The problem is that in the libtool linking phase the arguments "/usr/bin
> /usr/sbin /bin /sbin" are given along the libraries and library paths. I
> have no idea why this happens, and how to solve this. Something must be
> wrong on my system. But what? For libggi, emerging with USE=-aalib sort
> of solved this. But I have no idea what to do about pygtksourceview. As
> all gthe KDE stuff seems to depend on this, I cannot continue

I found a workaround, after looking more closely to the emerge -t
output. pygtksourceview is needed when git is built only with the gtk
USE flag. So I can continue, but it just happened again with
dev-db/libiodbc, whatever this is, and whatever this may depend on.
There is something wrong on this system, and I have no idea where to look.

	Wonko

Re: [gentoo-user] Build problems due to invalid libtool arguments

[Pandu Poluan]

[-- Attachment #1: Type: text/plain, Size: 942 bytes --]

On Dec 27, 2011 6:01 AM, "Alex Schuster" <wonko@wonkology.org> wrote:
>
> I wrote:
>
> > The problem is that in the libtool linking phase the arguments "/usr/bin
> > /usr/sbin /bin /sbin" are given along the libraries and library paths. I
> > have no idea why this happens, and how to solve this. Something must be
> > wrong on my system. But what? For libggi, emerging with USE=-aalib sort
> > of solved this. But I have no idea what to do about pygtksourceview. As
> > all gthe KDE stuff seems to depend on this, I cannot continue
>
> I found a workaround, after looking more closely to the emerge -t
> output. pygtksourceview is needed when git is built only with the gtk
> USE flag. So I can continue, but it just happened again with
> dev-db/libiodbc, whatever this is, and whatever this may depend on.
> There is something wrong on this system, and I have no idea where to look.
>

Have you tried revdep-rebuild? python-updater?

Rgds,

[-- Attachment #2: Type: text/html, Size: 1168 bytes --]

Re: [gentoo-user] Build problems due to invalid libtool arguments

[Alex Schuster]

Pandu Poluan writes:

> On Dec 27, 2011 6:01 AM, "Alex Schuster" <wonko@wonkology.org
> <mailto:wonko@wonkology.org>> wrote:
>>
>> I wrote:
>>
>> > The problem is that in the libtool linking phase the arguments "/usr/bin
>> > /usr/sbin /bin /sbin" are given along the libraries and library paths. I
>> > have no idea why this happens, and how to solve this. Something must be
>> > wrong on my system. But what? For libggi, emerging with USE=-aalib sort
>> > of solved this. But I have no idea what to do about pygtksourceview. As
>> > all gthe KDE stuff seems to depend on this, I cannot continue

The problem seems to happen deep in the libtool script in the build
directory, where a variable deplibs is set to "/sbin /bin /usr/sbin
/usr/bin/usr/lib64/libaa.so ...", but I do not yet know why and where in
those 7700 lines of code that happens, a 'libtool=' occurs 121 times
there. Gotta go to bed for now

> Have you tried revdep-rebuild? python-updater?

No. When I do, all is consistent, and python-updater does not find much,
mostly things that are not even installed yet.

Now I try another of those things that are supposed to fix all kind of
weird problems, emerge -e @world. I changed the CFLAGS a little, and I
had forgotten to add sse2 to the USE flags, so I just build everything
again this night. But I don't expect this to help with my problem.

	Wonko

Re: [gentoo-user] Build problems due to invalid libtool arguments

[Walter Dnes]

On Mon, Dec 26, 2011 at 07:23:27PM +0100, Alex Schuster wrote
> Hi there!
> 
> I'm currently upgrading my little sister's PC from an x86 Sempron to an
> x86_64 AMDS A6 processor. So Gentoo is being installed from scratch.
> 
> But some packages fail to build. I filed a bug [1] for
> media-libs/libggi-2.2.2, but a similar problem is happening for
> pygtksourceview now, and I do not find a simple workaround.
> 
> The problem is that in the libtool linking phase the arguments "/usr/bin
> /usr/sbin /bin /sbin" are given along the libraries and library paths. I
> have no idea why this happens, and how to solve this. Something must be
> wrong on my system. But what? For libggi, emerging with USE=-aalib sort
> of solved this. But I have no idea what to do about pygtksourceview. As
> all gthe KDE stuff seems to depend on this, I cannot continue

  I notice that you have 'MAKEOPTS="-j4"'.  You wouldn't believe how
many problems you can solve by changing to 'MAKEOPTS="-j1"'.  Yes, the
build process may take a bit longer, but the final executable runs just
as fast.  Change to 'MAKEOPTS="-j1"' and see what happens.

  The concept of parallel jobs is nice in theory, and you can *USUALLY*
get away with it.  The problem is that if a job tries to use an
intermediate file before it's fully created, or if the "destructor"
(file deletion) does it's thing before the scratch file has been used,
things get very fouled up.  My attitude is that the first time you spend
hours trying to trace down a non-replicatable bug, you will lose more
time than you "save" by speeding up builds with 'MAKEOPTS="-j4"'.

-- 
Walter Dnes <waltdnes@waltdnes.org>

Re: [gentoo-user] Build problems due to invalid libtool arguments

[Alex Schuster]

Walter Dnes writes:

> On Mon, Dec 26, 2011 at 07:23:27PM +0100, Alex Schuster wrote

>> The problem is that in the libtool linking phase the arguments "/usr/bin
>> /usr/sbin /bin /sbin" are given along the libraries and library paths. I
>> have no idea why this happens, and how to solve this. Something must be
>> wrong on my system. But what? For libggi, emerging with USE=-aalib sort
>> of solved this. But I have no idea what to do about pygtksourceview. As
>> all gthe KDE stuff seems to depend on this, I cannot continue
> 
>   I notice that you have 'MAKEOPTS="-j4"'.  You wouldn't believe how
> many problems you can solve by changing to 'MAKEOPTS="-j1"'.  Yes, the
> build process may take a bit longer, but the final executable runs just
> as fast.  Change to 'MAKEOPTS="-j1"' and see what happens.

Good idea, I also had some weird side effects from that in the past.
Although not that reproducible. I see this with libggi, libiodbc,
gtksourceview and gettext, at least.

I still get the same error. And the emerge -e also did not clean things up.

My next idea would be to compare the build logs on that and on my own
machine, maybe I spot a difference. Or to analyze the libtool script
deeper. Before I give up and install Ubuntu...

	Wonko

[gentoo-user] Re: Build problems due to invalid libtool arguments

[James]

Alex Schuster <wonko <at> wonkology.org> writes:


> > as fast.  Change to 'MAKEOPTS="-j1"' and see what happens.

 +1


> I still get the same error. And the emerge -e also did not clean things up.

Yep. Sometimes on setting up a new system, I lower the bar on what I install,
resync the system and a day or 2 later, complete the install.


My little catch all, after hacking at the system is:

env-update && source /etc/profile && etc-update && eix-update

Run it often and resync every 12 hours too.

Also check your profile.


On lib tool, see if you have this script and run it:

fix_libtool_files.sh 3.3.4

Not sure where I found that puppy, but hopefully it fixes your
issues with libtool.


Just shots in the dark, YMMV!


James

Re: [gentoo-user] Build problems due to invalid libtool arguments

[Michael Mol]

Walter Dnes wrote:
> On Mon, Dec 26, 2011 at 07:23:27PM +0100, Alex Schuster wrote
>    I notice that you have 'MAKEOPTS="-j4"'.  You wouldn't believe how
> many problems you can solve by changing to 'MAKEOPTS="-j1"'.  Yes, the
> build process may take a bit longer, but the final executable runs just
> as fast.  Change to 'MAKEOPTS="-j1"' and see what happens.
>
>    The concept of parallel jobs is nice in theory, and you can *USUALLY*
> get away with it.  The problem is that if a job tries to use an
> intermediate file before it's fully created, or if the "destructor"
> (file deletion) does it's thing before the scratch file has been used,
> things get very fouled up.  My attitude is that the first time you spend
> hours trying to trace down a non-replicatable bug, you will lose more
> time than you "save" by speeding up builds with 'MAKEOPTS="-j4"'.

While I agree poking the MAKEOPTS is a good idea, I'd like to point out 
my own experience with parallel builds.

IME, running with emerge "--keep-going", and then running "emerge 
--resume --keep-going" once or twice *afterward* typically solves any 
problem I had on my first pass. I suspect unspecified dependencies are 
usually to blame.

Re: [gentoo-user] Build problems due to invalid libtool arguments

[Dale]

Michael Mol wrote:
> Walter Dnes wrote:
>> On Mon, Dec 26, 2011 at 07:23:27PM +0100, Alex Schuster wrote
>>    I notice that you have 'MAKEOPTS="-j4"'.  You wouldn't believe how
>> many problems you can solve by changing to 'MAKEOPTS="-j1"'.  Yes, the
>> build process may take a bit longer, but the final executable runs just
>> as fast.  Change to 'MAKEOPTS="-j1"' and see what happens.
>>
>>    The concept of parallel jobs is nice in theory, and you can *USUALLY*
>> get away with it.  The problem is that if a job tries to use an
>> intermediate file before it's fully created, or if the "destructor"
>> (file deletion) does it's thing before the scratch file has been used,
>> things get very fouled up.  My attitude is that the first time you spend
>> hours trying to trace down a non-replicatable bug, you will lose more
>> time than you "save" by speeding up builds with 'MAKEOPTS="-j4"'.
>
> While I agree poking the MAKEOPTS is a good idea, I'd like to point 
> out my own experience with parallel builds.
>
> IME, running with emerge "--keep-going", and then running "emerge 
> --resume --keep-going" once or twice *afterward* typically solves any 
> problem I had on my first pass. I suspect unspecified dependencies are 
> usually to blame.
>
>

That's my experience too.  It is even rare that I run into that.  I 
would imagine that some builds are more complex than others so if it 
does fail, trying it with -j1 would make sense.  It's better than 
waiting for a fix that may not happen for a while at least.

I think the parallel options on both fronts is getting better.

Dale

:-)  :-)

-- 
I am only responsible for what I said ... Not for what you understood or how you interpreted my words!

Miss the compile output?  Hint:
EMERGE_DEFAULT_OPTS="--quiet-build=n"

[solved] Re: [gentoo-user] Build problems due to invalid libtool arguments

[Alex Schuster]

I wrote:

> The problem is that in the libtool linking phase the arguments "/usr/bin
> /usr/sbin /bin /sbin" are given along the libraries and library paths. I
> have no idea why this happens, and how to solve this. Something must be
> wrong on my system. But what? For libggi, emerging with USE=-aalib sort
> of solved this. But I have no idea what to do about pygtksourceview. As
> all gthe KDE stuff seems to depend on this, I cannot continue

And the solution is <ta-daaah>: unset path

I am using systemrescuecd, which sets a 'path' environment variable.
This variable is being used in the libtool script, without being cleared
first.

Makes me feel a little stupid. I filed a bug report for a package that
built without problems on my other system. I looked a bugs.gentoo.org,
but did not search the web much for keywords like 'libtool' and
'/usr/bin /usr/sbin /bin /sbin', which would have found a few mentions
of this problem. And I wasted too much time debugging and trying to
understand the libtool script.

I filed a bug for autoconf:
https://bugs.gentoo.org/show_bug.cgi?id=396213

	Wonko

Re: [gentoo-user] Re: Build problems due to invalid libtool arguments

[Sebastian Beßler]

[-- Attachment #1: Type: text/plain, Size: 508 bytes --]



On 27.12.2011 15:21, James wrote:

> env-update && source /etc/profile && etc-update && eix-update
> 
> Run it often and resync every 12 hours too.

I thought you should only sync once every 24 hours to limit network
costs and stress for the mirrors.

From the motd of todays sync:

"Please note: common gentoo-netiquette says you should not sync more
than once a day.  Users who abuse the rsync.gentoo.org rotation
may be added to a temporary ban list."

Greetings

Sebastian Beßler


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 900 bytes --]

Re: [gentoo-user] Re: Build problems due to invalid libtool arguments

[Pandu Poluan]

On Thu, Dec 29, 2011 at 15:56, Sebastian Beßler
<sebastian@darkmetatron.de> wrote:
>
>
> On 27.12.2011 15:21, James wrote:
>
>> env-update && source /etc/profile && etc-update && eix-update
>>
>> Run it often and resync every 12 hours too.
>
> I thought you should only sync once every 24 hours to limit network
> costs and stress for the mirrors.
>
> From the motd of todays sync:
>
> "Please note: common gentoo-netiquette says you should not sync more
> than once a day.  Users who abuse the rsync.gentoo.org rotation
> may be added to a temporary ban list."
>

AFAIK, that limitation is enforced for rsync.gentoo.org only.

I personally use a non *.gentoo.org servers for syncing. Much much
MUCH faster for me, by a factor of 2 or 3.

Rgds,
-- 
FdS Pandu E Poluan
~ IT Optimizer ~

 • LOPSA Member #15248
 • Blog : http://pepoluan.tumblr.com
 • Linked-In : http://id.linkedin.com/in/pepoluan

Re: [gentoo-user] Re: Build problems due to invalid libtool arguments

[Dale]

Pandu Poluan wrote:
> On Thu, Dec 29, 2011 at 15:56, Sebastian Beßler
> <sebastian@darkmetatron.de>  wrote:
>>
>> On 27.12.2011 15:21, James wrote:
>>
>>> env-update&&  source /etc/profile&&  etc-update&&  eix-update
>>>
>>> Run it often and resync every 12 hours too.
>> I thought you should only sync once every 24 hours to limit network
>> costs and stress for the mirrors.
>>
>>  From the motd of todays sync:
>>
>> "Please note: common gentoo-netiquette says you should not sync more
>> than once a day.  Users who abuse the rsync.gentoo.org rotation
>> may be added to a temporary ban list."
>>
> AFAIK, that limitation is enforced for rsync.gentoo.org only.
>
> I personally use a non *.gentoo.org servers for syncing. Much much
> MUCH faster for me, by a factor of 2 or 3.
>
> Rgds,


There used to be a server that allowed unlimited syncs.  As far as I 
know, that was the only one and it changed from unlimited to once a day 
a year or so ago.  Unless the MOTD says it is unlimited then I would 
think it is once a day.  Once a day has been the rule ever since I 
started using Gentoo.  Unless there is a problem with the tree, I don't 
understand why anyone, except a dev maybe, would need to sync twice a 
day.  Heck, I sometimes go two or three days and still have nothing to 
update.

Dale

:-)  :-)

-- 
I am only responsible for what I said ... Not for what you understood or how you interpreted my words!

Miss the compile output?  Hint:
EMERGE_DEFAULT_OPTS="--quiet-build=n"