src2pkg-2.9 - build .pets from source code!
src2pkg-2.9 - build .pets from source code!
I've just released a new version of src2pkg. This is a minor version upgrade which mostly fixes a few minor errors when handling files or dirs which have spaces in their names.
You can get an installable *.pet package here:
http://distro.ibiblio.org/amigolinux/do ... arch-1.pet
For those who don't know, src2pkg is an 'intelligent' program for creating installable packages from source code or other content. src2pkg can build puppy *.pet packages, *.txz packages for slackware, *.tpkg packages for KISS-Linux, *.tazpkg packages for slitaz, *.deb ackages for debian/ubuntu and their derivatives and *.rpm packages for suse, fedora, etc.
src2pkg is the easiest way to build packages for you system, or for sharing. Many packages can be built without the need for a build recipe or script.
You can get an installable *.pet package here:
http://distro.ibiblio.org/amigolinux/do ... arch-1.pet
For those who don't know, src2pkg is an 'intelligent' program for creating installable packages from source code or other content. src2pkg can build puppy *.pet packages, *.txz packages for slackware, *.tpkg packages for KISS-Linux, *.tazpkg packages for slitaz, *.deb ackages for debian/ubuntu and their derivatives and *.rpm packages for suse, fedora, etc.
src2pkg is the easiest way to build packages for you system, or for sharing. Many packages can be built without the need for a build recipe or script.
Yes Flash, it needs some kind of devx_puppy.sfs .Flash wrote:I assume this program requires the .dev file to be installed, in order to compile from source code.
The x therein does not mean X server, but likely 's for devel oper's .
The quite functional sfs_load by shinobar makes it possible to load any devx you find scattered on your system .
Of course I would recommend the corresponding one for the current puppy one is running, but the ones with same or older glibc version should do it too, as my experiences can tell .
amigo,
libsentry fails to compile on Slacko 5.6 and 5.6.1
I cheated a bit and found another version of dirent.h to try, and this one worked:
http://cpansearch.perl.org/src/MHX/Conv ... e/dirent.h
- it is older, from 2005.
Original dirent.h attached.
(I was quite pleased to win a million euros on ibiblio not so long ago too. Danke)
libsentry fails to compile on Slacko 5.6 and 5.6.1
Code: Select all
# make
./create-defines
Checking truncate argument type... off_t
Checking readlinkat result type... ssize_t
Checking libc version... libc.so.6
Checking glibc subversion... ./create-defines: line 58: strings: command not found
cc -Wall -U_FORTIFY_SOURCE -D_GNU_SOURCE -DLIBDIR=\"/usr/local/lib\" -DPIC -fPIC -D_REENTRANT -DVERSION=\"0.7.2\" -c libsentry.c
libsentry.c:3087:5: error: conflicting types for ‘scandir’
In file included from libsentry.c:52:0:
/usr/include/dirent.h:256:12: note: previous declaration of ‘scandir’ was here
make: *** [libsentry.o] Error 1
Code: Select all
GNU C Library stable release version 2.15, by Roland McGrath et al.
Copyright (C) 2012 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.
There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
PARTICULAR PURPOSE.
Compiled by GNU CC version 4.7.1.
Compiled on a Linux 3.2.45 system on 2013-09-16.
Available extensions:
crypt add-on version 2.1 by Michael Glad and others
GNU Libidn by Simon Josefsson
Native POSIX Threads Library by Ulrich Drepper et al
BIND-8.2.3-T5B
libc ABIs: UNIQUE IFUNC
For bug reporting instructions, please see:
<http://www.gnu.org/software/libc/bugs.html>.
Code: Select all
# gcc -dumpversion
4.7.1
http://cpansearch.perl.org/src/MHX/Conv ... e/dirent.h
- it is older, from 2005.
Original dirent.h attached.
(I was quite pleased to win a million euros on ibiblio not so long ago too. Danke)
- Attachments
-
- dirent.h.gz
- Slacko original - dummy .gz extension
- (12.47 KiB) Downloaded 598 times
"strings: command not found " -this means you are missing 'strings' which is part of the util-linux package. Puppy may have removed this package to use that dreadful busybox instead.
"conflicting types for ‘scandir’ " This means that the devx doesn't include the correct glibc headers to match the kernel version.
"conflicting types for ‘scandir’ " This means that the devx doesn't include the correct glibc headers to match the kernel version.
Slacko still has it, but it's in the devx and it's named strings-GNU."strings: command not found " -this means you are missing 'strings' which is part of the util-linux package.
The busybox' one in turn is renamed to strings-BB-NOTUSED.Puppy may have removed this package to use that dreadful busybox instead.
Greetings!
[color=red][size=75][O]bdurate [R]ules [D]estroy [E]nthusiastic [R]ebels => [C]reative [H]umans [A]lways [O]pen [S]ource[/size][/color]
[b][color=green]Omnia mea mecum porto.[/color][/b]
[b][color=green]Omnia mea mecum porto.[/color][/b]
Slackware uses a source called bsdstrings which is added to utils-linux.
Here's a quote from the binutils.SlackBuild:
Here's a quote from the binutils.SlackBuild:
Code: Select all
# Differentiate between BSD strings and GNU strings
( cd $PKG/usr/bin ; mv strings strings-GNU )
If you follow the path rather the full link you find it is now:Trobin wrote:Is src2pkg still available. All I got. from trying the link, is a 404 not found page.
Thank you.
http://distro.ibiblio.org/amigolinux/do ... arch-1.pet
Cheers
peebee
LxPup = Puppy + LXDE
Main version used daily: LxPupSc; Assembler of UPups, ScPup & ScPup64, LxPup, LxPupSc & LxPupSc64
Main version used daily: LxPupSc; Assembler of UPups, ScPup & ScPup64, LxPup, LxPupSc & LxPupSc64
Hi amigo,
I can't install src2pkg in Raring-5.6.94.
I can't install src2pkg in Raring-5.6.94.
- Attachments
-
- src2pkg.jpg
- (56.7 KiB) Downloaded 697 times
Hi amigo,
Installed successfully as follows: when the installation progressed to the failure point, I opened the location dir - the package was there. Did nothing, closed Rox, installation completed without issues. But, if I don't open the location dir, installation fails. Mystery. Not a big deal, though.
Did a couple test runs - works absolutely great.
BTW, src2pkg, as I discovered accidentally, has its own wiki: http://www.src2pkg.net.
Thank you, very much for this tool.
Installed successfully as follows: when the installation progressed to the failure point, I opened the location dir - the package was there. Did nothing, closed Rox, installation completed without issues. But, if I don't open the location dir, installation fails. Mystery. Not a big deal, though.
Did a couple test runs - works absolutely great.
BTW, src2pkg, as I discovered accidentally, has its own wiki: http://www.src2pkg.net.
Thank you, very much for this tool.
"when the installation progressed to the failure point, I opened the location dir - the package was there. Did nothing, closed Rox, installation completed without issues." That wouldn't make sense to anyone else, but I think I see from that what may be going wrong -the pinstall.sh script is not exiting properly. But nobody else has reported such an issue...
amigo,
I have a question regarding some settings, namely cflags. They are supposed to be set in src2pkg.conf., that's pretty straightforward. I can't find where the 'O level' resides. Exporting my own cflags with O3, Os, doesn't seem to work. I'd like to control those directly.
Thank you in advance.
I have a question regarding some settings, namely cflags. They are supposed to be set in src2pkg.conf., that's pretty straightforward. I can't find where the 'O level' resides. Exporting my own cflags with O3, Os, doesn't seem to work. I'd like to control those directly.
Thank you in advance.
OPTIM_FLAGS is what contains the optimization flags. There is a shortcut for either of the settings you mention:
OPTIMIZE_4_SIZE=YES
gives you -Os
OPTIMIZE_4_SPEED=YES
gives you -03
(the default gives you -O2)
I know it a little confusing, but the final options are composed from several elements, each of which can be set individually.
STD_FLAGS="$(echo $OPTIM_FLAGS $MACHINE $EXTRA_FLAGS $TUNE_FLAGS )"
MACHINE is normally '-m32' unless the system is 64-bit.
TUNE_FLAGS is composed from MARCH_FLAGS and ARCH_FLAGS
You can see the code where this is happening in /usr/libexec/src2pkg/01-pre_process. The settings then get used in /usr/libexec/src2pkg/06-configure_source. (Search for STD_FLAGS)
You might want to set the follwoing values in src2pkg.conf file:
It's important to note that using this sort of syntax:
[[ $EXTRA_FLAGS ]] || EXTRA_FLAGS=
instead of simply:
EXTRA_FLAGS=
allows you to override these settings on a per-package basis, so I recommend always using such syntax in the conf file.
OPTIMIZE_4_SIZE=YES
gives you -Os
OPTIMIZE_4_SPEED=YES
gives you -03
(the default gives you -O2)
I know it a little confusing, but the final options are composed from several elements, each of which can be set individually.
STD_FLAGS="$(echo $OPTIM_FLAGS $MACHINE $EXTRA_FLAGS $TUNE_FLAGS )"
MACHINE is normally '-m32' unless the system is 64-bit.
TUNE_FLAGS is composed from MARCH_FLAGS and ARCH_FLAGS
You can see the code where this is happening in /usr/libexec/src2pkg/01-pre_process. The settings then get used in /usr/libexec/src2pkg/06-configure_source. (Search for STD_FLAGS)
You might want to set the follwoing values in src2pkg.conf file:
Code: Select all
[[ $EXTRA_FLAGS ]] || EXTRA_FLAGS="-pipe -fomit-frame-pointer -fno-strict-aliasing -Wno-shadow -Wno-unused"
[[ $EXTRA_LDFLAGS ]] || EXTRA_LDFLAGS="--relax,--sort-common,--no-keep-memory"
[[ $EXTRA_FLAGS ]] || EXTRA_FLAGS=
instead of simply:
EXTRA_FLAGS=
allows you to override these settings on a per-package basis, so I recommend always using such syntax in the conf file.
amigo,
I have one more question, not directly related to src2pkg - LDFLAGS.
At what point/stage do they come into play? They are not needed for ./configure, they are not needed during make, I guess. They can be exported, but when? How would a normal sequence of commands look like, if I performed a manual compiling?
1) ./configure
2) make
3) export LDFLAGS ?
4) make install
Thank you in advance.
I have one more question, not directly related to src2pkg - LDFLAGS.
At what point/stage do they come into play? They are not needed for ./configure, they are not needed during make, I guess. They can be exported, but when? How would a normal sequence of commands look like, if I performed a manual compiling?
1) ./configure
2) make
3) export LDFLAGS ?
4) make install
Thank you in advance.
No, CFLAGS and LDFLAGS are used during configuration:
export CFLAGS
export CPPFLAGS (if using g++)
export LDFLAGS
configure
make
make install
However, the procedure varies a great deal, depending on the sources and configuration method. Not one of the above commands is universal and always used. This is where src2pkg really helps because it understands dozens of variations and detects when to use the right method.
export CFLAGS
export CPPFLAGS (if using g++)
export LDFLAGS
configure
make
make install
However, the procedure varies a great deal, depending on the sources and configuration method. Not one of the above commands is universal and always used. This is where src2pkg really helps because it understands dozens of variations and detects when to use the right method.
Thanks, amigo.
I have some basic understanding of CFLAGS and need to read more about LDFLAGS. No doubt, src2pkg is a powerful and sophisticated tool and I will be using it. It's well crafted and documented, and I want you to know, that your work is greatly appreciated. The only beef I have with it is its input part. I'd like it to be a little bit simpler, more intuitive. Something like that of buildpets', where I can have all the options at a glance. I just instinctively expect them to be seen in one place. Please, consider this a feature request.
Thank you.
I have some basic understanding of CFLAGS and need to read more about LDFLAGS. No doubt, src2pkg is a powerful and sophisticated tool and I will be using it. It's well crafted and documented, and I want you to know, that your work is greatly appreciated. The only beef I have with it is its input part. I'd like it to be a little bit simpler, more intuitive. Something like that of buildpets', where I can have all the options at a glance. I just instinctively expect them to be seen in one place. Please, consider this a feature request.
Thank you.
Well, having every option in just one place is problematic -wherever that one place is.
If everything must be explicitly given in a build script, like buildpet, then changing common configuration options would require you to edit every build script -after first requiring that there *be* a build script for the source. If every common option was held in a single configuration file then you wouldn't be able to adjust, for instance, CFLAGS for just one package -this is what gentoo's 'emerge' limits you to.
I've tried to make it possible to build some things without any package-specific build recipe and also without any general config file at all -this means that some sane defaults will always be set no matter what. If you want to adjust the default value for all builds, for CFLAGS, for instance, then that should go in the main config file at /etc/src2pkg/src2pkg.conf. If you use the conditional syntax suggested earlier, then you can still override the setting from the command-line or from within a build script.
Many options are best seen as being transitional -like cleanup functions, etc., which can be turned on and off from the command line. Build scripts should only contain stuff which is critical and/or indispensable to that specific build. The whole system is designed to encourage the use of build scripts -unless the absence of one means that everything is done automatically without any special non-transitional options. Any software build is only as good as its repeatability factor.
Feel free to ask me about any options you are interested in or looking for -because they are probably already in there -like package splitting or size reduction options.
If everything must be explicitly given in a build script, like buildpet, then changing common configuration options would require you to edit every build script -after first requiring that there *be* a build script for the source. If every common option was held in a single configuration file then you wouldn't be able to adjust, for instance, CFLAGS for just one package -this is what gentoo's 'emerge' limits you to.
I've tried to make it possible to build some things without any package-specific build recipe and also without any general config file at all -this means that some sane defaults will always be set no matter what. If you want to adjust the default value for all builds, for CFLAGS, for instance, then that should go in the main config file at /etc/src2pkg/src2pkg.conf. If you use the conditional syntax suggested earlier, then you can still override the setting from the command-line or from within a build script.
Many options are best seen as being transitional -like cleanup functions, etc., which can be turned on and off from the command line. Build scripts should only contain stuff which is critical and/or indispensable to that specific build. The whole system is designed to encourage the use of build scripts -unless the absence of one means that everything is done automatically without any special non-transitional options. Any software build is only as good as its repeatability factor.
Feel free to ask me about any options you are interested in or looking for -because they are probably already in there -like package splitting or size reduction options.