| View previous topic :: View next topic |
| Author |
Message |
twiggy
n00b
Joined: 25 Nov 2003
Posts: 65
Location: Sweden
|
 Posted: Mon Oct 18, 2004 7:23 pm Post subject: |
 |
|
| Hackeron wrote: | | twiggy wrote: | http://217.209.205.126/goawaybaselayout.html
I hope this could be of any use for some of you  |
How does this speed anything up exactly? |
Reduces the bootup time alot. It might not be what you want but it is without a doubt in the speed category.
_________________
Bite my shiny metal ass! |
|
| Back to top |
|
 |
Hackeron
Guru
Joined: 01 Nov 2002
Posts: 307
|
| Posted: Mon Oct 18, 2004 7:39 pm Post subject: |
|
|
| twiggy wrote: | | Reduces the bootup time alot. It might not be what you want but it is without a doubt in the speed category. |
Well, I just tried it on a spare machine that I use for distro testing, and I dont notice any speed up what so ever. Maybe its there, especially if you have many services, but then again you already have parallel startup in baselayout and there's ofcourse tips on this thread to make startup as fast as possible. Try them!
Even if there is a slight gain in speed if using sysvinit with those scripts instead of baselayout (no gain in speed here), I dont see how anyone would compromise baselayout's usability for it.
The init system in gentoo is one of my favorite things about the distribution. Look at fedora's sysv implementation - services marked started when they're not is just one of the examples of the many things wrong with it - and they have a far more advanced configuration than crux  |
|
| Back to top |
|
|
twiggy
n00b
Joined: 25 Nov 2003
Posts: 65
Location: Sweden
|
| Posted: Mon Oct 18, 2004 7:43 pm Post subject: |
|
|
It's all about taste
Baselayout might be useable but i just hate it. Mostly because the output is so freaking ugly and i like to keep things simple.. It's certainly not something everyone should use but it's perfect for me..
_________________
Bite my shiny metal ass! |
|
| Back to top |
|
|
Hackeron
Guru
Joined: 01 Nov 2002
Posts: 307
|
| Posted: Mon Oct 18, 2004 7:46 pm Post subject: |
|
|
| twiggy wrote: | It's all about taste
Baselayout might be useable but i just hate it. Mostly because the output is so freaking ugly and i like to keep things simple.. It's certainly not something everyone should use but it's perfect for me.. |
Ofcourse, very valuable howto! , I just think it deserves its own thread on the documentation forum!
Afterall, gentoo is about choice |
|
| Back to top |
|
|
twiggy
n00b
Joined: 25 Nov 2003
Posts: 65
Location: Sweden
|
| Posted: Mon Oct 18, 2004 7:55 pm Post subject: |
|
|
| Hackeron wrote: | | twiggy wrote: | It's all about taste
Baselayout might be useable but i just hate it. Mostly because the output is so freaking ugly and i like to keep things simple.. It's certainly not something everyone should use but it's perfect for me.. |
Ofcourse, very valuable howto! , I just think it deserves its own thread on the documentation forum!
Afterall, gentoo is about choice |
https://forums.gentoo.org/viewtopic.php?p=1665175#1665175
If you'd like to say hello or whatever
_________________
Bite my shiny metal ass! |
|
| Back to top |
|
|
bruciemoose
n00b
Joined: 22 Sep 2004
Posts: 19
Location: Llanfair TH, North Wales
|
| Posted: Wed Oct 20, 2004 2:23 pm Post subject: hdparm in boot not default |
|
|
I'm a newbie to Gentoo, but I would have thought that hdparm would be best run as soon as possible. Looking at /etc/init.d/hdparm the dependency shows:
| Code: | depend() {
before bootmisc
}
|
Since bootmisc is in the "boot" runlevel, I would assume that it would be best to run hdparm in "boot" and not "default"?
Andrew |
|
| Back to top |
|
|
asph
l33t
Joined: 25 Aug 2003
Posts: 741
Location: Barcelona, Spain
|
| Posted: Wed Oct 20, 2004 3:35 pm Post subject: |
|
|
bruciemoose: if you want to run hdparm the soon as possible put it on the boot runlevel (which is executed before the default one)
twiggy: the baselayout tweaks look amazing, but also it seems dangerous when you lose all the improvements/fixes/changes made in the new baselayouts gentoo releases.. maybe i would go with modyfing it, instead of unmerging it all 
_________________
gentoo sex is updatedb; locate; talk; date; cd; strip; look; touch; finger; unzip; uptime; gawk; head; emerge --oneshot condom; mount; fsck; gasp; more; yes; yes; yes; more; umount; emerge -C condom; make clean; sleep |
|
| Back to top |
|
|
twiggy
n00b
Joined: 25 Nov 2003
Posts: 65
Location: Sweden
|
| Posted: Wed Oct 20, 2004 5:07 pm Post subject: |
|
|
| mvila wrote: | bruciemoose: if you want to run hdparm the soon as possible put it on the boot runlevel (which is executed before the default one)
twiggy: the baselayout tweaks look amazing, but also it seems dangerous when you lose all the improvements/fixes/changes made in the new baselayouts gentoo releases.. maybe i would go with modyfing it, instead of unmerging it all |
I tweaked baselayout a bit before but it's a lot easier to get the things like you want it by starting from scratch.. the only real "downside" i can see is you really can't tell if all the initscripts gets up and running or if it fails but i really don't care that much and it's problably not so hard do fix that.. 
_________________
Bite my shiny metal ass! |
|
| Back to top |
|
|
Kurse
Apprentice
Joined: 31 Aug 2004
Posts: 169
Location: Midwest, USA
|
| Posted: Wed Oct 20, 2004 5:33 pm Post subject: |
|
|
| wrc1944 wrote: | Keffin,
Thanks for the input. Seeing as how you have not actually tried this, could you elaborate a little on your basis for thinking they are compatible, or point me to some info (other than the forum threads)?
I recently installed Yoper on one of my boxes, and it has prelink out of the box, and I must say Yoper is very snappy for a precompiled rpm distro. Therefore, I prelinked one of my Gentoo installations to see if made any difference. I have to say I can barely notice any, and maybe I'm imagining any perceived improvement.
Then I read about LDFLAGS, and it seemed like something to try, thus my question about prelink & LDFLAGS. Can anyone confirm that I remove prelink before trying LDFLAGS, or doesn't it really matter? |
My system is prelinked, and I do use LDFLAGS as well. I havent had any negative impact that I can see, and I do notice a speed improvement with some applications |
|
| Back to top |
|
|
pennedinil
Tux's lil' helper
Joined: 08 Aug 2003
Posts: 95
|
| Posted: Thu Oct 21, 2004 11:23 am Post subject: |
|
|
My Experiences with LDFLAGS
I thought I'd add this to the post. Perhaps someone can confirm/correct my problems.
In the hopes of maximizing speed and optimizing my system, I added the following to make.conf -
| Code: |
CFLAGS="-O2 -pipe -march=pentium4 -fomit-frame-pointer"
CFLAGS=" -maccumulate-outgoing-args -ftracer" #<-- additional opts
CFLAGS+=" -mmmx -msse -msse2" #<-- for the extra registers
CFLAGS+=" -mfpmath=sse" #<-- for my math libs
LDFLAGS="-Wl,-O1 -Wl,--enable-new-dtags -Wl,--sort-common -Wl,-s"
CFLAGS="$CFLAGS $LDFLAGS" #<-- gives lots of gcc warnings but works
CXXFLAGS="$CFLAGS -fvisibility-inlines-hidden"
|
I felt adding LDFLAGS to CFLAGS would force those packages that do not otherwise use LDFLAGS to do so.
I'm using hardened toolchain, with gcc-3.4.2 with the latest glibc libs, system compiled from the ground up.
One of the strangeness I noticed was that some of the executables now had the suffix "*.c.20.combine". This was especially noticable in the star & cdrtools packages. Other packages exhibiting this behavior are pkgconfig, gdb and xterm. I had to manually go into the PORTAGE_TMPDIR and rename the files for the application to complete the merge.
Other applications also give similar problems, I can't remember exactly which ones, but the fix usually involved me having to manually rename files or move them around in PORTAGE_TMPDIR.
Another problem I noticed was when kdelibs failed to compile. After a lot of backtracking, I found that the problem was with the jpeg package. With LDFLAGS in CFLAGS, libjpeg.so is not created. Which is very odd. [Perhaps this sould be in a bug report.]
All said and done, I feel my system is now a lot more responsive. E.g., konqueror opens immediately instead of the normal 2-3 second delay.
So my questions here are -
1) anyone else try the above?
2) if so (or even otherwise) anyone else notice anything similar with cdrtools?
3) what about the jpeg package?
4) if you haven't tried this, would anyone else be willing to confirm the above, just so I know it's not specific to my system?
Thanks.
And BTW pretty good HOWTO, somet things I really like, others I'm not yet ready to embrace. |
|
| Back to top |
|
|
twiggy
n00b
Joined: 25 Nov 2003
Posts: 65
Location: Sweden
|
| Posted: Thu Oct 21, 2004 2:51 pm Post subject: |
|
|
mvila:
In the updated version of my guide and i've removed the part where you remove baselayout so that can't cause any problems and otherwise the init stuff works like in the old guide..
_________________
Bite my shiny metal ass! |
|
| Back to top |
|
|
xces
Guru
Joined: 11 Oct 2002
Posts: 515
|
| Posted: Thu Oct 21, 2004 4:00 pm Post subject: |
|
|
@pennedinil:
| Code: | | CFLAGS="-O2 -pipe -march=pentium4 -fomit-frame-pointer" |
| man gcc wrote: | -fomit-frame-pointer
Don't keep the frame pointer in a register for functions that don't
need one. This avoids the instructions to save, set up and restore
frame pointers; it also makes an extra register available in many
functions. It also makes debugging impossible on some machines.
[...]
Enabled at levels -O, -O2, -O3, -Os |
-fomit-frame-pointer is already activated, when you use -O2.
| Code: | | CFLAGS=" -maccumulate-outgoing-args -ftracer" #<-- additional opts |
You are lacking a '+' here, aren't you? The compiler-flags you added here both make the size of the generated code bigger, so you should have a quite fast harddisk to compensate this.
| Code: | | CFLAGS+=" -mmmx -msse -msse2" #<-- for the extra registers |
All three flags/features are already activated when using -march=pentium4. |
|
| Back to top |
|
|
pennedinil
Tux's lil' helper
Joined: 08 Aug 2003
Posts: 95
|
| Posted: Sat Oct 23, 2004 4:29 pm Post subject: |
|
|
You're right about the missing + in my CFLAGS. Typo when I typed out the post.
I saw something similar about -fomit-frame-pointer somewhere, that it's activated with -O2. But I've also seen something to the converse. So just to be safe, I leave it in.
And I've seen something similar with regard to -mmmx -msse -msse2, that they are not activated by default with -march=pentium4, so again, just to be on the safe side...
It's more than possible the x86-P4 relevant flags above are activated with -march, and perhaps what I read was in reference to -mcpu.
And yes, I do have more than enough disk space. Compared to the amount of space the portage tree takes up (packages, distfiles, tempfiles, ebuilds, ccache), which adds up to about 30GB (yes, I don't clean house often!) the added size of the executables is something I'm very much willing to live with.
This still doesn't answer my other questions though...
Thanks. |
|
| Back to top |
|
|
M@rijn
Tux's lil' helper
Joined: 28 Jan 2004
Posts: 145
Location: Zierikzee (The Netherlands)
|
| Posted: Sat Oct 23, 2004 7:46 pm Post subject: |
|
|
Here a little question, how can i set prelink as een startup service, so he starts up with the system?
_________________
Gentoo is just an Aston Martin, "Power, beauty and soul" |
|
| Back to top |
|
|
pleusicles
n00b
Joined: 26 May 2004
Posts: 44
|
| Posted: Sat Oct 23, 2004 9:33 pm Post subject: |
|
|
| M@rijn wrote: | | Here a little question, how can i set prelink as een startup service, so he starts up with the system? |
You can't (and don't have to). After prelinkink, the effect will last as long as binaries aren't changed. But you will need to re-run prelink when emerging new versions. You may, however, make a cron job which does that regularly for you. |
|
| Back to top |
|
|
ahorn
Guru
Joined: 01 Nov 2004
Posts: 366
Location: Ol' europe
|
| Posted: Mon Nov 01, 2004 8:14 pm Post subject: |
|
|
Hi there,
got some tiny problems by compiling glibc with nptl and prelink with normal use flags
| Code: |
[blocks B ] sys-kernel/linux-headers (from pkg sys-kernel/linux26-headers-2.6.8.1-r1)
[ebuild N ] sys-kernel/linux-headers-2.4.22 -build 28,836 kB
[ebuild N ] sys-kernel/linux26-headers-2.6.8.1-r1 -build 34,793 kB
[ebuild R ] sys-libs/glibc-2.3.4.20040808-r1 -build -debug -erandom -hardened -makecheck -multilib +nls +nptl* -pic -userlocales 0 kB
|
| Code: |
[blocks B ] dev-libs/libelf (from pkg dev-libs/elfutils-0.94-r1)
[blocks B ] dev-libs/libelf (from pkg sys-devel/prelink-20040707)
[ebuild N ] dev-libs/elfutils-0.94-r1
[ebuild N ] sys-devel/prelink-20040707
|
both blocks are still there with ~x86! i use 2.6.9-r4-love1
can you give me any explanation how i can manage this? the other tweaks works well. for amd users i recommend to use athcool. a nice tool, cools the cpu by increase the powersaving feature so you can oc them more
_________________
Too many connections. Please try again later. |
|
| Back to top |
|
|
bob1977
Guru
Joined: 16 Mar 2004
Posts: 387
|
| Posted: Mon Nov 01, 2004 9:38 pm Post subject: |
|
|
For glibc, I think you have to inject linux26-headers somewhere. Try to search in forums for glibc and nptl.
For prelink, you must unmerge libef and then you will emerge prelink. Finally you type: prelink -avmR. Wait for 20 minutes and it's done. I've just installed it and I'm going to test the new performances.
See you later. |
|
| Back to top |
|
|
ahorn
Guru
Joined: 01 Nov 2004
Posts: 366
Location: Ol' europe
|
| Posted: Tue Nov 02, 2004 11:40 am Post subject: |
|
|
thanks for the tip at prelink
| Code: |
checking for C compiler default output file name... configure: error: C compiler cannot create executables
See `config.log' for more details.
!!! ERROR: dev-libs/elfutils-0.94-r1 failed.
|
i'm going to unpack gcc glibc binaries to fix this prob. maybe i've got broken linux-headers or i need libelf to let gcc work
@nptl: --inject is deprecated by portage, i guess. and i don't wanna mess with glibc by doing handstuff. is there not an easy routine to get nptl working?
_________________
Too many connections. Please try again later.
Last edited by ahorn on Tue Nov 02, 2004 1:07 pm; edited 1 time in total |
|
| Back to top |
|
|
iainvt
Guru
Joined: 12 Sep 2004
Posts: 462
Location: UK
|
| Posted: Tue Nov 02, 2004 12:40 pm Post subject: |
|
|
fantastic tips man
_________________
iain |
|
| Back to top |
|
|
baeksu
l33t
Joined: 26 Sep 2004
Posts: 609
Location: Seoul, Korea
|
| Posted: Tue Nov 02, 2004 3:34 pm Post subject: |
|
|
Tried adding xdm (i.e. gdm) to my boot run-level, works with no problems.
| Quote: | acpid | battery default
alsasound | battery default
aumix |
bootmisc | boot
checkfs | boot
checkroot | boot
clock | boot
consolefont | boot
cpufreqd |
crypto-loop |
cupsd |
domainname |
esound |
famd |
gkrellmd |
gpm |
hdparm |
hostname | boot
hotplug |
iptables |
keymaps | boot
local | battery default nonetwork
localmount | boot
metalog | battery default
mit-krb5kadmind |
mit-krb5kdc |
modules | boot
mpd |
net.eth0 |
net.lo | boot
net.ppp0 |
net.wlan0 |
netmount |
nscd |
numlock |
portmap |
rmnologin | boot
rsyncd |
serial | boot
slmodem |
speedfreq | default
splash |
sshd |
urandom | boot
xdm | battery boot
xfs |
xprint |
|
I'm not familiar with the runlevels or depenencies, however. Xdm kicks in at the end of the boot levels, and as I have little on my default level, the speed increase is not very huge. Still, X starts a little earlier than before.
On a another note, there's some discussion on using the suspend/hibernate to speed up starting the computers.
https://forums.gentoo.org/viewtopic.php?p=1679415#1679415
I haven't had time to try it myself yet, but will do as soon as I get around installing the suspend scripts.
_________________
Gnome:
1. A legendary being.
2. A never ending quest to make unix friendly to people who don't want unix and excruciating for those that do. |
|
| Back to top |
|
|
nat
Apprentice
Joined: 04 Sep 2002
Posts: 205
|
| Posted: Wed Nov 03, 2004 1:17 pm Post subject: Re: [HOWTO] Flying with gentoo |
|
|
| Quote: | In this section I just wanted to mention some things that can help us.
First of all, if you have two harddisks it is better to put the swap partition on the second disk (having the root partition in the first one) as this will improve the read/write times.
|
Wouldn't it be better to have 2 swap partitions, one on every IDE bus? Linux is supposed to automatically RAID swap, so using 1 swap on every disk (on different IDE busses) would almost double the swap speed in theory.
Correct me if I am wrong. I have not tested...
And about CFLAGS, I suspect that bigger C++ applications (like KDE) will go faster with -Os instead of -O3. That is also theory, but if the main bottle neck is the disk, it is probably true. I believe this might be noticeable on slower boxes. |
|
| Back to top |
|
|
nat
Apprentice
Joined: 04 Sep 2002
Posts: 205
|
| Posted: Wed Nov 03, 2004 6:51 pm Post subject: |
|
|
| JanErik wrote: | One more interesting thing could be nscd, or Name Service Cache Daemon. Should give faster web since it doesn't have to do a DNS lookup for visited URLs.
|
Since I am maintaing a DNS proxy I had to compare nscd with dnrd.
| Code: | ncopa@nc ~/src/stressdns $ sudo /etc/init.d/nscd start
* Starting Name Service Cache Daemon ... [ ok ]
ncopa@nc ~/src/stressdns $ ./stressdns more10k_a
Number of parallell lookups: 1
26247: 9986 of 10000 lookups was successful. Time: 8.770 seconds
ncopa@nc ~/src/stressdns $ ./stressdns more10k_a
Number of parallell lookups: 1
26248: 9986 of 10000 lookups was successful. Time: 1.297 seconds
ncopa@nc ~/src/stressdns $ ./stressdns more10k_a
Number of parallell lookups: 1
26249: 9986 of 10000 lookups was successful. Time: 1.225 seconds
ncopa@nc ~/src/stressdns $ ./stressdns more10k_a
Number of parallell lookups: 1
26250: 9986 of 10000 lookups was successful. Time: 1.168 seconds
ncopa@nc ~/src/stressdns $ ./stressdns more10k_a
Number of parallell lookups: 1
26251: 9986 of 10000 lookups was successful. Time: 1.529 seconds
ncopa@nc ~/src/stressdns $ ./stressdns more10k_a
Number of parallell lookups: 1
26252: 9986 of 10000 lookups was successful. Time: 1.334 seconds
ncopa@nc ~/src/stressdns $ ./stressdns more10k_a
Number of parallell lookups: 1
26253: 9986 of 10000 lookups was successful. Time: 1.803 seconds
ncopa@nc ~/src/stressdns $ ./stressdns more10k_a
Number of parallell lookups: 1
26254: 9986 of 10000 lookups was successful. Time: 1.346 seconds
|
stressdns is a small utility I wrote to test a bunch of gethostbyname calls. In this example I did lookups of 10000 names from a squid log.
The first run is slow (8.7 seconds) because the cache is empty. The next runs are fast.
I started modified /etc/conf.d/dnrd to point to y DNS servers, modified /etc/resolv.conf to point to 127.0.0.1 and started dnrd.
| Code: | ncopa@nc ~/src/stressdns $ sudo /etc/init.d/dnrd start
* Starting dnrd ... [ ok ]
ncopa@nc ~/src/stressdns $ sudo vim /etc/resolv.conf
ncopa@nc ~/src/stressdns $ ./stressdns more10k_a
Number of parallell lookups: 1
26439: 9986 of 10000 lookups was successful. Time: 2.330 seconds
ncopa@nc ~/src/stressdns $ ./stressdns more10k_a
Number of parallell lookups: 1
26440: 9986 of 10000 lookups was successful. Time: 0.838 seconds
ncopa@nc ~/src/stressdns $ ./stressdns more10k_a
Number of parallell lookups: 1
26441: 9986 of 10000 lookups was successful. Time: 0.854 seconds
ncopa@nc ~/src/stressdns $ ./stressdns more10k_a
Number of parallell lookups: 1
26442: 9986 of 10000 lookups was successful. Time: 0.841 seconds
ncopa@nc ~/src/stressdns $ ./stressdns more10k_a
Number of parallell lookups: 1
26443: 9986 of 10000 lookups was successful. Time: 0.830 seconds
ncopa@nc ~/src/stressdns $ ./stressdns more10k_a
Number of parallell lookups: 1
26444: 9986 of 10000 lookups was successful. Time: 0.838 seconds
ncopa@nc ~/src/stressdns $ ./stressdns more10k_a
Number of parallell lookups: 1
26445: 9986 of 10000 lookups was successful. Time: 0.834 seconds
|
Without nscd and dnrd:
| Code: | ncopa@nc ~/src/stressdns $ ./stressdns more10k_a
Number of parallell lookups: 1
26405: 9986 of 10000 lookups was successful. Time: 6.391 seconds
ncopa@nc ~/src/stressdns $ ./stressdns more10k_a
Number of parallell lookups: 1
26406: 9986 of 10000 lookups was successful. Time: 5.365 seconds
ncopa@nc ~/src/stressdns $ ./stressdns more10k_a
Number of parallell lookups: 1
26407: 9986 of 10000 lookups was successful. Time: 5.212 seconds
ncopa@nc ~/src/stressdns $ ./stressdns more10k_a
Number of parallell lookups: 1
26408: 9986 of 10000 lookups was successful. Time: 5.463 seconds
|
(pretty fast lookups anyway because I run a bind on a P4 with gigabit....)
Conclusion is: dnrd is the fastest here. You will ofcourse not note any difference unless you do some really heavy DNS intesive things, but dnrd adds security by randomizing the UDP source ports.
So I recommend dnrd (http://dnrd.sourceforge.net) instead of nscd.
Unfortunally it is not in the portage tree yet, even if an ebuild have been around for a long time.
https://bugs.gentoo.org/show_bug.cgi?id=56378 |
|
| Back to top |
|
|
Dana Merrick
Tux's lil' helper
Joined: 24 Jul 2004
Posts: 84
Location: Trinity College
|
| Posted: Wed Nov 03, 2004 10:04 pm Post subject: |
|
|
| baeksu wrote: | Tried adding xdm (i.e. gdm) to my boot run-level, works with no problems.
...I'm not familiar with the runlevels or depenencies, however. Xdm kicks in at the end of the boot levels, and as I have little on my default level, the speed increase is not very huge. Still, X starts a little earlier than before. |
I did the same thing, and it's a subtle improvement.
Does anyone know what the deps are for xdm?
I feel that it could be booting faster than it is, but I'm not sure what else I need to start...
(Edited to fix quote tags  )
_________________
I'm proud of my life, and the things that I have done,
proud of myself, and the loner I've become.
you're free to whine; it will not get you far,
I do just fine, my car and my guitar.
-Say Anything |
|
| Back to top |
|
|
rhill
Retired Dev
Joined: 22 Oct 2004
Posts: 1629
Location: sk.ca
|
| Posted: Thu Nov 04, 2004 6:01 am Post subject: |
|
|
| xces wrote: |
| man gcc wrote: | -fomit-frame-pointer
Don't keep the frame pointer in a register for functions that don't
need one. This avoids the instructions to save, set up and restore
frame pointers; it also makes an extra register available in many
functions. It also makes debugging impossible on some machines.
Enabled at levels -O, -O2, -O3, -Os |
-fomit-frame-pointer is already activated, when you use -O2. |
but if you look further up, it states:
| man gcc wrote: | | -O also turns on -fomit-frame-pointer on machines where doing so does not interfere with debugging. |
the x86 architecture is definitely one of the ones where it makes debugging impossible, and so it is not activated at any -O level unless it's stated specifically.
i wish i had a better reference, (of course you can't find these things when you need them)
but this recent post backs it up:
http://lists.gnu.org/archive/html/gcl-devel/2004-06/msg00005.html
| Quote: | Test configuration 1.
With optimisation set to "-g -O3" (that is, without -fomit-frame-pointers)
maxima ignore-errors -- NO
"universe.lisp" -- NO |
| Quote: | Test configuration 2.
With optimisation set to "-g -O3 -fomit-frame-pointers":
maxima ignore-errors -- NO
"universe.lisp" -- FAIL |
--de. |
|
| Back to top |
|
|
HardenCoonor
n00b
Joined: 19 Feb 2004
Posts: 54
|
| Posted: Thu Nov 04, 2004 8:56 am Post subject: |
|
|
| Quote: | | LDFLAGS="-Wl,-O1 -Wl,--enable-new-dtags -Wl,--sort-common -Wl,-s" |
I think with binutils-2.15.92.0-* -Wl,--enable-new-dtags is obsolete, as it is most probably activated by default, there is a patch included in the binutils-patch-tar.bz2.
Has anyone tried -fdata-sections and/or -ffunction-sections in his/her CFLAGS and -gc-sections in LDFLAGS? |
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
Documentation, Tips & Tricks
