Saluki, Puppy Remastered

Under development: PCMCIA, wireless, etc.
Message
Author
User avatar
ttuuxxx
Posts: 11171
Joined: Sat 05 May 2007, 10:00
Location: Ontario Canada,Sydney Australia
Contact:

#61 Post by ttuuxxx »

technosaurus If the #1 most popular distro Ubuntu and then you have Debian, uses i386 then I think we should go that way. Plus new products like my surfboard pc I purchased like 2 weeks ago uses vortex86 http://murga-linux.com/puppy/viewtopic.php?t=59466
the vortex86 cpu is going to expanded into other pc's also, they already have a ipad clone version that uses it also, plus the edubook.
When I made up the VLC package in 4.0, The resources were way lower than Mplayer and Gxine. I built it as i386, where as Barry was building as i486. Don't forget the vlc had sdl and wxgtk , Here's a couple of user quotes from the VLC 8.6h page

Playing 'Lonesome Day Blues' from MP3 file on the hard disk. This notepad is a Toshiba Portege 3110CT with 128mb ram and a 300mhz processor (a PII).

Did comparison of gzine (with visualisation turned off) and VLC:

Gxine came out at 124% mem use and 38% CPU
VLC looked very good with 86% mem and 3% (sometimes 2%!) CPU usage. Unbelievable?

with some mpg video off a hard drive gxine 130%mem 98%cpu and VLC 112%mem and 89%cpu - but have to say the display at that point from VLC was roughly 3 times the size which makes a difference. plus not jerky like gxine.

VLC looks much better too Smile
I'm not too sure about your statement "Some areas where a higher architecture would be acceptable are encoders/decoders" The above is proof supporting the lower i386. Also The vlc package is double the Gxine size but takes way less resources, actually there were a few post that some people could play dvd's on there low spec pc's where they couldn't on Gxine because gxine was choppy.
ttuuxxx
http://audio.online-convert.com/ <-- excellent site
http://samples.mplayerhq.hu/A-codecs/ <-- Codec Test Files
http://html5games.com/ <-- excellent HTML5 games :)

User avatar
ttuuxxx
Posts: 11171
Joined: Sat 05 May 2007, 10:00
Location: Ontario Canada,Sydney Australia
Contact:

#62 Post by ttuuxxx »

Lets stay focussed on what puppy is and what it isn't, Puppy isn't Arch Linux -i686, Puppy is made for breathing new life into older pc's and also has supports bleeding edge technologies. But we still have many users using i486 pc's. heck most of my pc's other than the the surfboard are i686 dual-core, but I'm pretty much against the extra kernel bloat for the extra cores that have to be included by default for a minimal increase in speed that we have to force on all users to which most don't have more than 1 core cpu's.
ttuuxxx
http://audio.online-convert.com/ <-- excellent site
http://samples.mplayerhq.hu/A-codecs/ <-- Codec Test Files
http://html5games.com/ <-- excellent HTML5 games :)

User avatar
jemimah
Posts: 4307
Joined: Wed 26 Aug 2009, 19:56
Location: Tampa, FL
Contact:

#63 Post by jemimah »

Well is the mission to support just old computers, or all underpowered computers? I don't see how we get around either making compromises - or making multiple versions.

User avatar
ttuuxxx
Posts: 11171
Joined: Sat 05 May 2007, 10:00
Location: Ontario Canada,Sydney Australia
Contact:

#64 Post by ttuuxxx »

jemimah wrote:Well is the mission to support just old computers, or all underpowered computers? I don't see how we get around either making compromises - or making multiple versions.
naaa jemimah Puppy is usually well rounded as know, and I don't think its time to stop supporting older hardware, and some things keep bloating puppy up, like gnome libs or big fat kernels, larger Xorg versions. etc If we don't get handle on things and we let things fly like from 4.0 to 5.0 with a 50% increase in size. and keep on that path then puppy 6 should be 200MB, lol I know it won't ever be that bad maybe puppy 10 :)
Multiple versions is a pain, I think we should build puppy as i386, I only compile as i386 and do pretty well :) Or stick with Barry's default i486 but I'll still compile as i386 only. But noway should we go to 586 or 686, its not the time for that. We still get lots of users recycling older pc/laptops. There are lots of other distros who can handle 586,686 etc
My first pick is i386, i486 as second and last.
ttuuxxx
http://audio.online-convert.com/ <-- excellent site
http://samples.mplayerhq.hu/A-codecs/ <-- Codec Test Files
http://html5games.com/ <-- excellent HTML5 games :)

User avatar
jemimah
Posts: 4307
Joined: Wed 26 Aug 2009, 19:56
Location: Tampa, FL
Contact:

#65 Post by jemimah »

ttuuxxx wrote: naaa jemimah Puppy is usually well rounded as know, and I don't think its time to stop supporting older hardware, and some things keep bloating puppy up, like gnome libs or big fat kernels, larger Xorg versions. etc If we don't get handle on things and we let things fly like from 4.0 to 5.0
The latest crop of netbooks cannot be made to work on anything but a very recent Xorg and kernel. I won't argue over the compile arch - but if you expect to support more hardware over time - it's inevitable that the number and size of the drivers you need will grow. We can of course reduce the size by removing support for very old hardware. ;)

User avatar
ttuuxxx
Posts: 11171
Joined: Sat 05 May 2007, 10:00
Location: Ontario Canada,Sydney Australia
Contact:

#66 Post by ttuuxxx »

jemimah wrote:
ttuuxxx wrote: naaa jemimah Puppy is usually well rounded as know, and I don't think its time to stop supporting older hardware, and some things keep bloating puppy up, like gnome libs or big fat kernels, larger Xorg versions. etc If we don't get handle on things and we let things fly like from 4.0 to 5.0
The latest crop of netbooks cannot be made to work on anything but a very recent Xorg and kernel. I won't argue over the compile arch - but if you expect to support more hardware over time - it's inevitable that the number and size of the drivers you need will grow. We can of course reduce the size by removing support for very old hardware. ;)
I agree with Xorg and kernel, but I guess it could be reduced with only 1 cpu, and maybe a bit older kernel, There was something I read where the latest kernels have been growing 1000 lines of code a day!!!.
ttuuxxx
http://audio.online-convert.com/ <-- excellent site
http://samples.mplayerhq.hu/A-codecs/ <-- Codec Test Files
http://html5games.com/ <-- excellent HTML5 games :)

User avatar
technosaurus
Posts: 4853
Joined: Mon 19 May 2008, 01:24
Location: Blue Springs, MO
Contact:

#67 Post by technosaurus »

As far as getting off topic I would rather have this discussion during the planning phase and not have to rebuild everything later (ttuuxxx you've worked construction right - What's the saying? an hour during planning can save 10 later on - something like that)
ttuuxxx wrote:If the #1 most popular distro Ubuntu and then you have Debian, uses i386 then I think we should go that way. Plus new products like my surfboard pc I purchased like 2 weeks ago uses vortex86
I would agree at least for the underlying libraries except that:
"glibc no longer supports 386" ... are they both using eglibc now?
http://www.linuxfromscratch.org/lfs/vie ... glibc.html

the surfboard is 586 compatible (all vortex86 and dx and mx are - not the sx though)
cpufamily is 5 (aka 586) for all except the SX
flags are: fpu tsc cx8 (mmx only on the mx)

The SX is cpufamily 4 with no flags at all, but is generally targeted toward industrial applications.

My point is that the pentium has been around for over 15 years and most 486 computers will have hardware that is not supported in newer kernels (which glibc uses to compile against) so there should be a separate codebase to support 486 and below based on the older stable 2.6.16.62 or similar kernel and compiled with 486 and fpu emulation or use an older/different libc with 386 and fpu emulation. This should not be a problem to maintain if we use a build process as bigbass has mentioned.

regarding fpu and mmx not speeding up things: this is a result of the fpu and mmx sharing the same registers (poor design which causes one to flush the other and speed gains are lost, due partly to limitations of manufacturing at the time but mostly for win95/nt compatibility) combined with using libraries and programs written by different developers and/or just from being compiled for different architectures. This explains why people complain about a certain build being slower with -march=i686 - the underlying libraries are using the fpu and flushing the mmx from registers because the defined the fpu section of code rather than the mmx section when they were compiled.

To minimize this effect it is maybe better to set the build architecture to the maximum supported by the minimum desired platform specs from the get go and realize that changing them to a higher architecture is unlikely to be beneficial (with the exception of ffmpeg and programs using liboil like gstreamer which have workarounds and highly benefit from mmx for a continuous process like video encoding)

Perhaps a good compromise default config could be to use 386 with fpu emulation for the underlying libraries for the size benefit and so that there is no interference when building programs or specific libraries on top of them that can benefit from mmx and would never run comfortably on a 486 anyways.
Check out my [url=https://github.com/technosaurus]github repositories[/url]. I may eventually get around to updating my [url=http://bashismal.blogspot.com]blogspot[/url].

User avatar
jemimah
Posts: 4307
Joined: Wed 26 Aug 2009, 19:56
Location: Tampa, FL
Contact:

#68 Post by jemimah »

ttuuxxx wrote:
I agree with Xorg and kernel, but I guess it could be reduced with only 1 cpu, and maybe a bit older kernel, There was something I read where the latest kernels have been growing 1000 lines of code a day!!!.
ttuuxxx
My netbook is about a year old and the first kernel that really worked well on it was 2.6.33 (before that the drivers are nonexistant or extremely buggy). Removing hyper-threading support would be also be deal-breaker for most netbook owners (Plus I doubt it really would reduce the size of the kernel significantly).

I'm perfectly happy to keep making netbook forks - but my uneducated guess is that the netbook market is larger than the ancient computer market or will be soon as prices continue to drop. Moving forward seems important too!

User avatar
Lobster
Official Crustacean
Posts: 15522
Joined: Wed 04 May 2005, 06:06
Location: Paradox Realm
Contact:

#69 Post by Lobster »

I have tried running Puppy on an actual 486 and just yesterday on a Pentium II with 170MB ram.

Running on the 486 was an exercise in futility, more problems than solutions.
Never again.

The pentium II (running Lucid) would be acceptable to a lot of users. When Barry moved up to 486 compatibility compiling of the kernel that was a conservative move. If Ttuuxxx compiles programs for 386 that still makes sense as it is a reliable code base.
Puppy Raspup 8.2Final 8)
Puppy Links Page http://www.smokey01.com/bruceb/puppy.html :D

User avatar
ttuuxxx
Posts: 11171
Joined: Sat 05 May 2007, 10:00
Location: Ontario Canada,Sydney Australia
Contact:

#70 Post by ttuuxxx »

jemimah wrote:
ttuuxxx wrote:
I agree with Xorg and kernel, but I guess it could be reduced with only 1 cpu, and maybe a bit older kernel, There was something I read where the latest kernels have been growing 1000 lines of code a day!!!.
ttuuxxx
My netbook is about a year old and the first kernel that really worked well on it was 2.6.33 (before that the drivers are nonexistant or extremely buggy). Removing hyper-threading support would be also be deal-breaker for most netbook owners (Plus I doubt it really would reduce the size of the kernel significantly).

I'm perfectly happy to keep making netbook forks - but my uneducated guess is that the netbook market is larger than the ancient computer market or will be soon as prices continue to drop. Moving forward seems important too!
The difference is posted at ibiblio linux_kernel-2.6.29.6-tickless_smp-2-p4.pet <--23MB
linux_kernel-2.6.30.5-tickless_smp-7-p4.pet <--35MB
at one time 12MB compressed in puppy meant a lot, heck back a couple years ago we used to try to save 30kb and less on a app. Now we toss 12MB compressed out the door and release very large versions.
jemimah you do produce a great release and probably it would be in puppies main interest to have a specific version for netbooks/laptops. Would be nice if the kernel-2.6.29.6 was patched and only 1MB or less was added for what you need and then we could have both in one release.
ttuuxxx

http://distro.ibiblio.org/pub/linux/dis ... ages-woof/
http://audio.online-convert.com/ <-- excellent site
http://samples.mplayerhq.hu/A-codecs/ <-- Codec Test Files
http://html5games.com/ <-- excellent HTML5 games :)

User avatar
technosaurus
Posts: 4853
Joined: Mon 19 May 2008, 01:24
Location: Blue Springs, MO
Contact:

#71 Post by technosaurus »

Lobster wrote:Running on the 486 was an exercise in futility, more problems than solutions.
It doesn't have to be though - its just the wrong package selection and configuration. 486 systems should have most background processes turned off by default, a different package selection (predominantly gtk1 and/or fltk) and the install should default to full instead of frugal. Amigo has quite a large collection of gtk1 apps that I have built. For your next 486 foray try Pup'nGo with amigo's gtk1 patched rox-1.2.2 on a full install.
Check out my [url=https://github.com/technosaurus]github repositories[/url]. I may eventually get around to updating my [url=http://bashismal.blogspot.com]blogspot[/url].

User avatar
technosaurus
Posts: 4853
Joined: Mon 19 May 2008, 01:24
Location: Blue Springs, MO
Contact:

#72 Post by technosaurus »

ttuuxxx wrote: The difference is posted at ibiblio linux_kernel-2.6.29.6-tickless_smp-2-p4.pet <--23MB
linux_kernel-2.6.30.5-tickless_smp-7-p4.pet <--35MB
http://distro.ibiblio.org/pub/linux/dis ... ages-woof/
With the zdrv-cutter the size of the kernel package due to extra modules is less relevant since they don't need to be installed if we have the zdrv-cutter as an installation option. Does it actually make the modules themselves significantly bigger? ... because I think Barry referenced building extra modules for some kernels and not for others.
Check out my [url=https://github.com/technosaurus]github repositories[/url]. I may eventually get around to updating my [url=http://bashismal.blogspot.com]blogspot[/url].

User avatar
Patriot
Posts: 733
Joined: Thu 15 Jan 2009, 19:04

#73 Post by Patriot »

Hmmm .....

Just browsing thru ...
technosaurus wrote:"Some areas where a higher architecture would be acceptable are encoders/decoders"
This is an area which I agree with you. There are 2 spectrum ends of en/decoders. The lower end and the higher end. The lower ends like mp3s are already highly optimized to benefit from an fpu and that is not even mmx. A i486dx-66 can do mp3s without choking on itself. The higher ends and more complicated pure software en/decoders like h264 (which is gaining more and more prominence each day) needs at least a p3-800 with fast sub-systems to barely scrape through doing 480p. A properly optimized and efficient decoders with proper arch support works best in this area. (I still haven't found a decoder that can beat CoreAVC. Heck, it's still the fastest even when wrapper-wrapped in linux).
technosaurus wrote:I would agree at least for the underlying libraries except that:
"glibc no longer supports 386" ... are they both using eglibc now?
http://www.linuxfromscratch.org/lfs/vie ... glibc.html
:lol: I just have to dig up something that I stumbled upon sometime ago that basically says, "one needs i486 emulation in kernel to run on actual i386 hardware" ... please read at http://people.debian.org/~joey/pr/3.1/i386.html

Frankly, I'd go for a generic i586 kernel meself and do a max'ed out fully optimized custom machine tuned kernel whenever necessary. Sure, I like the old k2.6.21.7 for the simple reason of being surrounded by antique/classic hardwares. Yeah, I still have a i386DX-20mhz board with 8MB (70ns) FP RAM SIMMs (that's 70nanoseconds Fast Page RAM Single Inline Memory Modules for those wondering). Sure, it still boots up fine but no one's gonna make me boot linux on it (unless you're paying me for a demo, haha). Yeah, I also have a couple i486DX2-66mhz board with 16MB (60ns) EDO RAM ... One of it is running Freesco right now ... Puppy? Don't think so, it's gonna choke-n-sputter if I put puppy on it ...

So, I guess that the most logical and rational base hardware suitable for puppy testing is a pentium 133 with at least 64MB RAM. Yeah, I have in my collection the complete range from iP75 right up to iP233mmx ... But I'd prefer to run at least a Cyrix mII-300 or a K6-2/400 with 128MB RAM for base h/w puppy testing ...

I was interested with the xcore86 SoC when edubook came out ... but not anymore after it became clear to me why it's sluggish even at 1Ghz. A similar ARM SoC at 1Ghz would be running circles around it ...

Anyway, techno, what's the point of "arguing" about which arch to base on? I'm sure you're more than qualified to decide the cut-off point for h/w support (just don't forget to set a reasonable acpi bios cut-off date, ok?). Stretching support for older hardware is fine but there should be a limit to it. All those ancient/antique/classic hardwares have their places but it doesn't seem to make sense to me to force the latest and greatest linux (apps/kernel) down their throat. I'm happy to plonk in a k2.6.21.7 on these old classics and I have no qualms doing a custom config kernel, libs and apps if there's a need for the latest h/w.

techno, you just do what you think and feel is right, whether its i486, i586, tickless, smp, nosmp, hyperthreading or whatever. However, if I may make a suggestion, offering a couple of official kernel to cater for uniproc/smp/ht can be beneficial in the long run ...


Rgds

User avatar
ttuuxxx
Posts: 11171
Joined: Sat 05 May 2007, 10:00
Location: Ontario Canada,Sydney Australia
Contact:

#74 Post by ttuuxxx »

ok I'll make it very simple, puppy 5 was bloated in my eyes and I never downloaded it, If puppy 6 goes beyond i486, well that will make 2 versions I won't participate in. There won't be a third, I'll either stick with 2.14X or move on to another distro, Or start one up.
ttuuxxx
http://audio.online-convert.com/ <-- excellent site
http://samples.mplayerhq.hu/A-codecs/ <-- Codec Test Files
http://html5games.com/ <-- excellent HTML5 games :)

User avatar
Iguleder
Posts: 2026
Joined: Tue 11 Aug 2009, 09:36
Location: Israel, somewhere in the beautiful desert
Contact:

#75 Post by Iguleder »

We can't have support for both older hardware and newer hardware. I'm on jemimah's side :)

SMP is a MUST for all netbooks and all PCs since ... 2006-7 or so. You can't tell people "you spent all your precious money on a PC with 6 cores and hyperthreading, so you've got 12 cores, but I let you use only one" ... give the user a free copy of Windows 98 in a DVD case with a red ribbon and forget it :lol:

The only way to go is 2 "main" puppies or the way things work now, one main Puppy for newer hardware and new packages and community puplets for those who don't get along with it.

i386 is a very bad choice because many packages don't know it, notably glibc. i486 or i686 are more suitable. I use i486 for my own distro and don't see any drop in performance.

Also, a SMP kernel is a must. Two menu entries, one with SMP and another with nosmp pretty much solve this problem. Also, there's kexec, we can compile two kernels, one minimal kernel with SMP support that starts the normal kernel and adds nosmp if you have only one processor. Just an idea.

A top ten distro can't be some legacy operating system built around packages dating back to 2005/6/7. Newer hardware like touch screens and netbook simply won't work. Having two branches, one with the latest and greatest packages and another with old packages is the only way to go.

Of course, some may say they want a GTK 1 or FLTK Puppy, but let's face it: that thing can't be the official Puppy. We're in 2010. Time to face it and drop i386 support and support for all hardware that can't boot any mini-distro of the current generation.

I say it's time to move on to i586 or i686 or i486 with multimedia packages for i686. Newest X, newest kernel, newest GTK, newest applications except some rollbacks where needed. Superb hardware support for average computers, laptops and netbooks. Support for old hardware is a good feature, but once ancient hardware support harms the user experience under average hardware, it's better to give up on it. Completely. No dial-up, no i386, no legacy packages from late 90's or early 2000's.
[url=http://dimakrasner.com/]My homepage[/url]
[url=https://github.com/dimkr]My GitHub profile[/url]

User avatar
ttuuxxx
Posts: 11171
Joined: Sat 05 May 2007, 10:00
Location: Ontario Canada,Sydney Australia
Contact:

#76 Post by ttuuxxx »

fine then, If you add up the number of post from the past 3 users and multiply it by 3 they would have less number of post then I have.
Really I guess it boils down to who coordinates puppy 6.
Lets have a poll, Ummmm if you want track records, puppy 5 group effort packages is http://distro.ibiblio.org/pub/linux/dis ... ges-lucid/
and well my personal packages for 2.14X .14x is
http://www.wisdom-seekers.com/puppy214x.html
Really I'm done with it.
ttuuxxx
http://audio.online-convert.com/ <-- excellent site
http://samples.mplayerhq.hu/A-codecs/ <-- Codec Test Files
http://html5games.com/ <-- excellent HTML5 games :)

User avatar
clarf
Posts: 613
Joined: Wed 13 Jun 2007, 19:22
Location: The old Lone Wolf

#77 Post by clarf »

I feel culpable to start this debate, but I agree with techo the time to decide the right approach is in the planning phase.

Many thanks for share your knowledge, I fully take you words (you have the experience and knowledge about it). Then, i386 is still a valid compilation option that reduce effectively package size in non performance critical applications and brings support to non conventional (Intel, ADM) processors (I remember some thread in this forum talking about intel process patents that are expiring right now.)

technosaurus, about compile specific libraries and applications on top that could benefit from optimizations, just arise the packaging problems of Puppy, there´s no one central distribution place and not even a standard way to do compile or reference dependencies, not even a globalized rule to say what specific libraries should be compiled for a specific architecture. Soon or late we´ll have to set some standards here.

ttuuxxx VLC compilation seems to run faster in and old PC (the main target of Puppy distibution), but I think that you will get the opposed results in a new machine with all the optimization enabled. I´ll like to make the same test in a newer PC with a package compiled for and advanced architecture, I think in that case VLC will work even faster (surely not too much) than the i386 compilation (obviously compared with the i386 compilation in the same new computer).

I agree ttuuxxx, we don´t have to forget Puppy essential. But, sadly recent Puppy version had doubled the machine requirements lately, as the memory consumption and size has been increased to, so the return to life to old systems is something that had been slowly passed apart. And the other thing is the competition with newer Linux Distributions, in the past Puppy was in the same level that DSL, at that time I tested Puppy and I get involved, now the fight is against bigger rivals. I steel loves to play with my ancient hardware but I feel comfortable using old Puppy versions on them, with the same old applications.

I also agree about common normal Puppy users don´t need the kernel bloat to support more than one core (Although I think the size difference is small). In this case I believe it depends from the final user needs, if he need additional horsepower for heavy task like video post processing or like in my case mount big Relation DatabasE or Enterpise Applications, the user surely will choose another distribution or just a Puppie adjusted for that, Fatdog64 comes to my mind. But young people or computer starters with newer hardware needs support too.

We can´t just maintain two Official branches?.
Last edited by clarf on Sat 11 Sep 2010, 15:57, edited 1 time in total.

big_bass
Posts: 1740
Joined: Mon 13 Aug 2007, 12:21

#78 Post by big_bass »

Hey Jeff (ttuuxxx)
If puppy 6 goes beyond i486, well that will make 2 versions I won't participate in
Jeff there are a few options to make everyone feel comfortable
and give you more flexibility to chose what is best for you

here's an example of how
sharing work on different bases will work
anything can be shared if a build script is made and even better with patches


this is just a small a snip of how a slackware build script allows you more freedom to share work

Code: Select all

if [ "$ARCH" = "i486" ]; then
  SLKCFLAGS="-O2 -march=i486 -mtune=i686"
elif [ "$ARCH" = "i686" ]; then
  SLKCFLAGS="-O2 -march=i686 -mtune=i686"
elif [ "$ARCH" = "x86_64" ]; then
  SLKCFLAGS="-O2 -fPIC"
fi

set -e
just by having a build script it can be easily reproduced
on any base. Patches could be added and build scripts could be fined tuned for smaller packages by having the special config opitions that we need
for a light distro


so what I am suggesting here is taking a more professional
solution to package builds by starting out with build scripts

they are easy to edit and keep updated

Joe

User avatar
Iguleder
Posts: 2026
Joined: Tue 11 Aug 2009, 09:36
Location: Israel, somewhere in the beautiful desert
Contact:

#79 Post by Iguleder »

ttuuxxx wrote:fine then, If you add up the number of post from the past 3 users and multiply it by 3 they would have less number of post then I have.
Really I guess it boils down to who coordinates puppy 6.
You could coordinate it even without a single post in this topic, ttuuxxx. But don't forget you can't do this on your own. If you want to be a leader, you need people to follow you and trust you.

One-man efforts die quickly and quietly. The latter also applies to selfish and egocentric people.

I know it doesn't matter much, I won't follow you.
clarf wrote:We can´t just maintain two Official branches?.
Both a question mark and a full stop, that's a sign from God probably :lol:
clarf is right, why can't we have two branches? Why is it so bad to express some pulralism and democracy within the community?

Umm ... what about three branches (normal, retro, and ttuuxxx)? :wink:
[url=http://dimakrasner.com/]My homepage[/url]
[url=https://github.com/dimkr]My GitHub profile[/url]

linuxcbon
Posts: 1312
Joined: Thu 09 Aug 2007, 22:54

#80 Post by linuxcbon »

I think i386 is good enough.
See http://linuxreviews.org/howtos/compiling/safe-cflags/

Code: Select all

CHOST="i386-pc-linux-gnu"
CFLAGS="-march=i386 -O3 -pipe -fomit-frame-pointer"
CXXFLAGS="-march=i386 -O3 -pipe -fomit-frame-pointer"

Post Reply