Puppy Linux Discussion Forum

[live]

[amigo]

Yes, it does. 'march' is the bottom limit and 'mtune' is the upper limit, which gets set to i686 for ARCH=i486. These are the standard settings long used by most mainstream distros. So, you should be fine using the standard ARCH=i486 settings.

Sorry about the prefix stuff, I should have looked here at my build script for openssl to see if there were any abnormalities to the build. Turns out it is rather involved, so I'll attach my materials.

The file openssl.src2pkg.gz is a fake gz file, simply rename to remove the '.gz' suffix. That is then the build recipe for openssl. It will use a couple of patches included in the (real) archive named openssl-patches.tar.bz2. Simply place those two files alongside the openssl sources and run 'src2pkg -X' to use that recipe.

[live]

>Sorry about the prefix stuff
I'm very glad to learn and exchange. If at the same time it provides enhancement it's an additional benefit for everyone.

[amigo]

No, there are no hard-coded paths. It may have something to do with the aufs layering. That's a strange tar-1.13 error that I've never seen either. Do you get that with the failed geany build?

About sse, you may want to leave out the no-sse2 and see if that works for you -this is directly related to the march choice. As for generally trying to adjust march/mtune when compiling, this makes no sense unless you build a whole system using 'better' settings -starting with glibc itself. src2pkg itself defaults to using the most conservative and universal settings for obvious reasons. You can adjust any settings you like, as far as compiler options goes. Have a look at and near lines 258-259 for some of them. Actually the defaults there are not completely conservative -the -fomit-frame-pointer option is not good on some arches. And the -pipe option could even be causing the tar-1.13 or build errors.

You can find lots of pre-made recipes here:
http://distro.ibiblio.org/amigolinux/distro/kiss-4.0/SOURCE/
Again about openssl, its build system is a home-grown thing which works pretty different than most builds -that's why the build script has so many lines. geany, OTOH, is pretty normal. The point is that some sources require extra work to get what you want, whereas something like geany can usually be compiled without any recipe at all.

[live]

>That's a strange tar-1.13 error that I've never seen either. Do you get that with the failed geany build?
It's a reproducable path bug and here is the way:
If my path is:
mnt/sda7/ITC/SharedWinXp/Linux/Puppysave/pet/dev/src
build is OK (thought contrary to a build in /root/Downloads I have way more output lines in Terminal...).
My initial path contained a blank in the folder's name so was 'Puppy save' instead of now Puppysave and there it stops on error 1.
I tested with non US char (namley: ésrc) it's ok.

I have to investigate other things regarding last post, however some others:

1/ On line 32 & 33 of /etc/src2pkg/src2pkg.conf if I modify them as

[amigo]

"Notice -march=pentium4 -mtune=i686" I'll work on making it possible to get what you want there. The '--arch=??' option to src2pkg only sets the ARCH portion of the package name and does not directly affect the gcc options.

"Are the files in /usr/include sometimes used for linking/dependicies during build process?" Yes, of course, this is where development headers(include files) are located. They are not used at run-time.

"tar-1.13" So, the error occurs only and always when there is a space in the name? That can be fixed -but seeing this reminds me that for pets a normal version of tar could be used instead.

"build a whole system using 'better' settings" Since nearly everything on the system links to glibc, a small performance improvement can be had by compiling glibc to match your hardware -**but** re-compiling glibc implies re-compiling everything that gets linked to it. Further, very few sources/programs actually use 'enhanced' CPU features -the big exception is audio/video editing software and high-performance number-crunching software.

So, optimizing libraries and applications for better CPU features will usually get you no noticeable improvement. There is some noticeable improvement to be had by re-compiling the kernel to match your hardware.

[Puppus Dogfellow]

i've decided to try this even though i don't know what i'm doing....

gleaning/misreading that running

[live]

[Puppus Dogfellow]

[amigo]

The build for mixx is most likely failing because of missing the 'scons' program.
src2pkg can't do magic -there is too much variation in the methods used to configure and build software- as the scons example shows. src2pkg can sometimes create a correct package without any special options being passed at all. But there will always be packages which need special config options or scripted steps to build them.

I've used src2pkg to build more than 10,000 distinct sources and it allows enough flexibility to handle any sort of build -but a recipe or package-specific options are usually needed about 60% of the time. So don't be surprised or discouraged if it fails to do it automatically the first time. Many times, builds fail because of missing prerequisites.

[Puppus Dogfellow]

[live]

>amigo
All I meant, is what you said "src2pkg can't do magic" sometimes it works as is, some times not and gave some examples.

Sorry, if they were some misinterpretation.

[amigo]

You can find lots of build scripts with patches, etc, for a reference implementation here:
http://distro.ibiblio.org/amigolinux/distro/kiss-4.0/

There are also many, many older scripts here:
http://distro.ibiblio.org/amigolinux/download/

You can have src2pkg generate a build script for you with:
src2pkg -N -Q tarball-name
or:
src2pkg -A tarball-name

The build scripts are easily modifiable to do anything at all. And they provide a repeatable, upgradeable recipe for later use. Provided that all needed depends are already present, most sources can be successfully compiled, to your needs, by only adding whatever options the sources configure script needs -although src2pkg handles the routine options like --prefix, --libdir, etc, automatically.

[scsijon]

Very nice package amigo, that can save a lot of time for me with T290 building. There's about 5100 pets to create in all of the T2 V9.0 set and I was wondering how I was going to manage it all. I know I could just do those I need, but I would like to have all of them available.

Is there a simple way to :

-just point it at a directory and tell it to create pet's from all sources in that directory;

- output resultant pets to another named directory;

-error files to a third so I can just work on those with problems;

- creates a copy of the onscreen data into a single named file so that you can initially just leave it alone to run it's course, and later check back when working on a problem.

Oh yes, and could it maybe be told to deal with patch scripts if their in the same directory as the source package.

I know a tall order, but anything to make life easier....

regards
scsijon

[amigo]

src2pkg lends itself well to being driven by other scripts -see the example GroupBuild scripts in the documentation. For best results, each source should be in its own sub-directory so that files generated or used by each build are kept separately. It also makes it possible to run more than one build at a time.

Any patches placed alongside the sources will be automatically applied.

Location of final packages can be controlled by setting PKG_DEST_DIR=/path/to/destination

The '-LOG' option will log the output of all important commands run during the build.

src2pkg is meant to create great packages -but *one at a time*. While it would be possible to make it run through a list of sources as a single run, it would defeat more important purposes. Irt can't do magic, so building 5,000+ sources is gonna take some work no matter what system you use.

While src2pkg can build lots of sources without any help or special options, there will always be some which need patches, special options or that must be done in a certain order. This is the same for all build systems, so at some point human-knowledge must come into play -which means writing build recipes, etc. However, src2pkg can leverage previous knowledge, by using rpm *.spec files, SlackBuild scrips or debian build files. This makes the process of creating a repo of sources for src2pkg much easier.

Take a good look at the example *.src2pkg scripts in the docs as there are examples for building inter-dependent packages and other unusual builds.