src2pkg-2.7 - create packages from any source code

Miscellaneous tools
Message
Author
User avatar
Tman
Posts: 808
Joined: Sat 22 Jan 2011, 21:39
Location: Toronto

#41 Post by Tman »

Btw.. I didn't attach the file.txt for the Thunar and its dependency pets becuase I altered them and deleted the original pets.

amigo
Posts: 2629
Joined: Mon 02 Apr 2007, 06:52

#42 Post by amigo »

dev_save -there's the problem. I'm afraid I'll have to look at a fix for this tomorrow as it is getting late here. It would help if you post the output from scr2pkg when you run this build. What I'm looking for is what comes just after this line in the output:
Compiling has been - Successful!"
Make sure you are not using the '-VV' option or the line will be lost.

No wait, here's a fix for it. Open the file /usr/libexec/src2pkg/08-fake_install and scroll down to line 303:
"post_fake_install() {"
Place the cursor at the end of that line, hit ENTER and then paste this in there:

Code: Select all

	if [[ -d "$PKG_DIR"/initrd ]] ; then
		( cd "$PKG_DIR" && rm -rf initrd )
	fi
There's already a general fix-up routine there which covers all content-creation types, so it should be fine there.

User avatar
Tman
Posts: 808
Joined: Sat 22 Jan 2011, 21:39
Location: Toronto

#43 Post by Tman »

Thanks, very much, amigo.:)
Your patch fixed the issue in the pet. It is still creating the initrd folder, but your patch removes it.

I here is the output from src2pkg as you requested earlier:

Code: Select all

Compiling has been - Successful!
Checking for Makefile rule: 'install' Okay
Checking support for DESTDIR (or similar) - Not found
   Notice - DESTDIR support not found. Falling back to JAIL install
Creating content in JAIL root - Using: 'make install'
cd src ; make all
make[1]: Entering directory `/initrd/mnt/dev_save/jwm-2.1.0-src-1/src'
make[1]: Nothing to be done for `all'.
make[1]: Leaving directory `/initrd/mnt/dev_save/jwm-2.1.0-src-1/src'
cd src ; make install ; cd ..
make[1]: Entering directory `/initrd/mnt/dev_save/jwm-2.1.0-src-1/src'
strip jwm
install -d /usr/bin
install jwm /usr/bin/jwm
make[1]: Leaving directory `/initrd/mnt/dev_save/jwm-2.1.0-src-1/src'
install -d /usr/etc
install -m 644 example.jwmrc /usr/etc/system.jwmrc
install -d /usr/share/man/man1
install -m 644 jwm.1 /usr/share/man/man1/jwm.1
   Notice - Checking integrity of '' installation - Done
Safe content creation - Successful!
Processing package content:
Correcting package permissions - Done
Stripping ELF binaries - Using: strip -p --strip-unneeded Done
Checking for standard documents - Done
   NOTICE - No man-pages installed by Makefile
Found man-pages in SRC_DIR - Installing in PKG_DIR
Compressing man pages - Done
Creating slack-desc - From default text
Rechecking package correctness:
Checking for misplaced dirs - Done
Rechecking package permissions - Done
Checking for dead links in PKG_DIR - Done
Searching for links in: jwm-2.1.0-i486-1 - None found
Creating package: 'jwm-2.1.0-i486-1.pet' - Done
Package Creation - Successful! Package location:
/mnt/home/jwm-2.1.0-i486-1.pet

amigo
Posts: 2629
Joined: Mon 02 Apr 2007, 06:52

#44 Post by amigo »

"Creating content in JAIL root" is what I was looking for -as I thought I'd have to code something for each type of content-creation.

"It is still creating the initrd folder" -I'll fix this a different way for next version which should avoid it being created at all.

amigo
Posts: 2629
Joined: Mon 02 Apr 2007, 06:52

#45 Post by amigo »

Keef, I need to see a copy of a header on your system:
/usr/include/dirent.h
Either paste inside code tags here, or attach it please. I'm pretty sure there is a mis-match between that header and the version used when glibc was compiled. When src2pkg tries to compile libsentry, the libsentry 'make' process tries to figure out which syntax to use for the 'scandir' function among others. The glibc version is read directly to figure this out. A new syntax is used for glibc >= 2.10, so it should be working. But that syntax should also match in the 'kernel headers' which were used to define the glibc kernel interface when glibc was compiled. If they don't compiling *lots* of things will fail.

I'm pretty sure that I can't really fix this in the libsentry make process. If I have it read the scandir syntax from the header, instead of from implying from the glibc version, I think the library would compile, but then segfault when you run it. Could you perhaps try some other distro with a 'sane' toolchain? No, I didn't really mean that did I?

User avatar
sc0ttman
Posts: 2812
Joined: Wed 16 Sep 2009, 05:44
Location: UK

#46 Post by sc0ttman »

amigo wrote:Keef, I need to see a copy of a header on your system:
/usr/include/dirent.h....I'm pretty sure there is a mis-match between that header and the version used when glibc was compiled
Just in case you're gonna waste your own precious time on this, Keef and myself are past this now, all fixed...
It was indeed me being dumb/lazy/cautious... I got my arse in gear, the toolchain is now 'sane'
(ish... its still got old kernel, therefore old kernel headers....)

... But I just built libsentry fine, and went on to compile lots of other stuff, inc FreeCiv, some SDL games, etc...
I think the library would compile, but then segfault when you run it.
Leave as is, so others hit the same problem, if they deserve it! :twisted:
[b][url=https://bit.ly/2KjtxoD]Pkg[/url], [url=https://bit.ly/2U6dzxV]mdsh[/url], [url=https://bit.ly/2G49OE8]Woofy[/url], [url=http://goo.gl/bzBU1]Akita[/url], [url=http://goo.gl/SO5ug]VLC-GTK[/url], [url=https://tiny.cc/c2hnfz]Search[/url][/b]

amigo
Posts: 2629
Joined: Mon 02 Apr 2007, 06:52

#47 Post by amigo »

Gosh, scOttman, I feel so... vindicated! You must have wrongly updatet the kernel headers when you updated the kernel.... For my distro, I call the headers 'libc-headers' instead of kernel-headers so that no one will think they are really related to the running kernel version. No ,wait, I missed this: "(ish... its still got old kernel, therefore old kernel headers....)".

Let me reiterate. When you compile glibc for a new system, you choose a certain version of the includes from the kernel sources. The version of these headers has absolutely no relation to whatever kernel you are running at glibc compile time, nor any relation to the kernel version you plane to release, nor to any upgraded-kernel you might use afterward (well, there a couple of corner cases where this is not *absolutely* true).

The headers used when compiling glibc define how glibc interfaces with the kernel. In order to have a sane system, these same kernel-headers should be used for compiling all software on the system until a new glibc version is created. So, the kernel headers which are present under /usr/include should always be the same for the life of the distro. And note that as soon as you upgrade glibc, you should properly re-compile *every* bit of software on the system. If you have noticed the many GLIBC_VERSION errors on this forum, this is exactly where they come from -mismatching binaries/libs.

This does not mean that you can never upgrade the kernel. The kernel sources do not install their headers under /usr/include -the kernel includes everything it needs under one dir. So, go right ahead and run any kernel version you like. The only time that the headers of the running kernel version matter is when you are compiling out-of-tree kernel modules.

So, make a nice package out of the original headers so they can always be handy and stay the same. Then, do what you like about a running kernel. When you need to compile out-of-tree modules, they are gonna need the full kernel sources *of the running kernel*. Compiling the module will look for the internal kernel headers -usually in the default location /usr/src/linux -otherwise there will be a configuration option which points the build at the correct kernel version.

Read this over and over again until it starts to make sense.

Note that there are other elements to having a truly sane toolchain. The toolchain only consists of three things: glibc, gcc and binutils. Later versions of gcc have external lib dependencie which also should fit and match, but to really understand the basics just consider those three.

Now, a truly sane toolchain is when all three of these components have a 'circular dependency* on each other. That means that *this* glibc was compiled by *this* gcc and linked using *this* binutils. It takes at least two passes to accomplish that. If that sounds like overkill, then you'll never be up to creating your own toolchain. Every major distro -nay, every 'true' distro does this every time the toolchain changes. Why? It is the Right Way (tm) and the only way to ensure that you never see those GLIBC_VERSION errors. Any so-called distro which does not observe these procedures is pure junk and is gonna bring lots of misery to nearly everyone who touches it. You can't simply grab some binaries from just anywhere and start mixing them.

User avatar
Keef
Posts: 987
Joined: Thu 20 Dec 2007, 22:12
Location: Staffordshire

#48 Post by Keef »

Amigo,
Thanks for the explanation. It is still mostly above my skill level, but I think I get the gist of it. I can understand the need to do several passes when building new tools. There is probably a good analogy somewhere, but I can't think of it yet. If you are using the 'old' tools to build the 'new', the job's not done until you have 'fully-filtered' new tools that can completely replace all the 'old' ones.

amigo
Posts: 2629
Joined: Mon 02 Apr 2007, 06:52

#49 Post by amigo »

Yeah, you build the new tools with the old ones -upgrading as you go, then re-build it all using the new versions -done.

c.lei
Posts: 1
Joined: Thu 22 Mar 2012, 16:09

src2pkg-2.7 - create packages from any source code

#50 Post by c.lei »

Not really puppy related, but I think everyone should be aware of this:

For some reason unknown, installing src2pkg-2.7-2.noarch.rpm on my machine running Fedora 9 corrupts the system.

When I reboot the system, I get a Gnome system error message basically saying the Gnome Power Management defaults have been corrupted and the
Gnome display is pretty much trashed.

Basically I have to reinstall the system from a recent partition image backup to recover from this since I really don't have a clue as to what acutally got trashed, and I'm not about to install the rpm on my other computers.

Any ideas as to what is going on other that a bad install rpm that's somehow trashing non-related files in ect when it's installed on Fedora and other systems?

User avatar
Tman
Posts: 808
Joined: Sat 22 Jan 2011, 21:39
Location: Toronto

#51 Post by Tman »

I tried installing src2pkg in Slacko today.
When I issued the command "src2pkg --setup", I got the following error message:

Code: Select all

Creating libsentry - Ooops! Can't live without it
Any ideas?

User avatar
Keef
Posts: 987
Joined: Thu 20 Dec 2007, 22:12
Location: Staffordshire

#52 Post by Keef »

Tman,

Try the previous page, starting with my post at the top - see if anything there helps.

User avatar
Tman
Posts: 808
Joined: Sat 22 Jan 2011, 21:39
Location: Toronto

#53 Post by Tman »

Keef wrote:Tman,

Try the previous page, starting with my post at the top - see if anything there helps.
Thanks Keef.

User avatar
oldyeller
Posts: 889
Joined: Tue 15 Nov 2011, 14:26
Location: Alaska

#54 Post by oldyeller »

were is the download link?

User avatar
Keef
Posts: 987
Joined: Thu 20 Dec 2007, 22:12
Location: Staffordshire

#55 Post by Keef »

Link is in first post, it is just not clickable.

User avatar
oldyeller
Posts: 889
Joined: Tue 15 Nov 2011, 14:26
Location: Alaska

#56 Post by oldyeller »

Thanks downloading now

Post Reply