I'm posting this here as a continuation of a thread on the Slackware forum:

It's just that because some packages wind up with BOTH /usr/lib64 AND /usr/lib, they both have pkgconfig directories in them. And they're likely identical to each other. It's just that /usr/lib, is specifically for 32bit code in Slamd64.

But I probably ought to check and make sure. Now I just have to remember a package that that happened with during the build. Maybe I'll just wait until it happens again. But if you add that code, it never will. That would be better, since this applies to all users having 64bit systems.

Shingoshi

I'm pretty sure you are getting this because of a routine in src2pkg which searches for *.pc files in the sources and instals them if they haven't already been installed. But the routine was written without regard for using an alternate libdir. It looks for *.pc files and if it finds any, it then looks in PKG_DIR/usr/lib/pkgconfig to see if they are there.

This code is found in the advanced_docs routine in /usr/libexec/src2pkg/11-create_docs in lines 92-97. As a quick fix, you can simply comment out these lines until I get the libdir matters sorted out better.

As piete mentioned, it is not a cut and dried issue, even leaving aside differences between one distro and another. Sometimes it is impossible to compile a program with true 64bit compatibility. In these cases you may have to have separate 32bit versions of some libs.

It may be well to consider carefully what piete has to say about 64bit issues as he obviously has some experience there. The initial support for 64bit systems in src2pkg was made possible mostly by my carefully considering what he had to say about it and from links/references that he provided. I'm still nopt what you would call thoroughly enlightened about the best way to set up a 64bit system, much less how to accomodate the different needs of the various systems or tastes of different users. We also have some guidelines to obsever or at least be aware of.

As far as the *.pc files goes, the files that match 64bit libs should go under /usr/lib64/pkgconfig apparently because they are architecture-dependent. If you are planning to have a dual-lib system, then things can get really complicated. If you want to compile a program to use libs under /usr/lib64 then you will need to set a couple of environmental variables when building the programs. These include LDFLAGS and PKG_CONFIG_DIR or PKGCONFIG_PATH. For a dual libs system you will need flexibility to be able to use different setting according to the program's requirements.
src2pkg usually sets 'sane' defaults according to what the majority of packages need and then allows for these settings to be overridden on a package-per-package basis. This usually means creating package-specific entries in a build script. This makes sure that the right settings are used and that you don't have to try to remember what you did the next time you want to build, or that others can easily use your scripts and get the same results.

I can pretty easily setup the lib64 code and the needed enivronmental variables as options with self-detection and setting of defaults. But I need to understand all the angles first and not just the preferences or needs of one person or system.
You can help by being a good investigator and learner. Paying attention to and asking questions of those who are more experienced helps reduce our/my work load. if you are using slamd64 then it will be of great advantage to pay close attentiuon to what they do in their build scripts.

You might also help me by trying to 'drum up' a few users of slamd64 for src2pkg. This would help a lot to debug code and to get a better consensus for defaults, etc.

Ok. So now that we're here. You should first know, that I'm not held in high regard with some Slamd64 users. Specifically, because I build a lot of my own packages. I had to build KMess, just so that I could chat with a friend online. There is this patronage with which you are all too aware, about following the thinking of one person (who needn't be identified), respected for the vision of Slackware. The problem is that vision doesn't include many of the things I aspire to. Some of them include, Xen, LTSP, Gluster (the gnu clustering system) and many others. It's almost a misnomer to say Slackware and desktop in the same sentence. Since Slackware probably has the highest percentage of users who prefer command line management. So the very idea of moving into divergent technologies, is pretty much seen as superfluous.

That I would consider using something like Gentoo for developing Slackware apps, is sheer anathema to some. It's as though I've committed an act of blasphemy. But that's exactly what I'm doing now. And I will be using src2pkg in my Gentoo chroot, just for that purpose.

I'm currently writing a wrapper for src2pkg, from which I can run a specific set of commands just for my own usage. One of those things will be the building of multiarch packages. As we have privately discussed various options for file management, as to where things should go, I should let you know I think I have settled on a format to follow from now on. It is definitely not Slackware's. Though I will be using Slackware tools in my newly developed system.

Some time ago, when searching for various Linux distributions, I came across GoboLinux. You may or not be aware of them. One of the curious things about them, is that they have an almost Windows-like filesystem structure. Going so far as to use /Programs instead of /usr. Most importantly, they don't use shared directories. Everything installed by one package, is in one directory. EVERYTHING! They do use symlinks to identify where things are. But all of the libs, headers, libraries etc. are in one master directory for each package. Things aren't spread all over the place as it typically is in Linux.

So, using your src2pkg scripts, I will now be identifying my PRE_FIX as /usr/$NAME/$VERSION. Doing this will allow me to have multiple versions of the same package installed at once, and nothing will ever be overwritten by updates. Now I may do something like this for Glib (as an example), where I have versions 2.8, 2.10, 2.12, 2.14 etc. continuing. So under /usr/Glib would be the versions in their own directories as listed here. This would be especially useful for packages like Qt, gcc and others which often cause some packages to balk, if the version they're looking for isn't installed.

Just consider your other thread for PDV, and your question of compilers. And no, I'm actually using the stock (4.1.2) compiler for Slamd64.

So anyway, to avoid the same thing happening again, with going off thread, I will start another here, just for building multiarch multilibs.

Shingoshi

"Everything installed by one package, is in one directory"
The /opt directory on Linux systems was especially created for just this purpose or for any app which doesn't use the standard directory layout. I'd strongly suggest that you this structure instead of under /usr, simply because it will help you to keep things more organized by separating the stuff you configure this way from the normal dirs under /usr. One of the 'rules' about /usr is that you are not really supposed to create new directories there -obviously exceptions to this for stuff like mozilla and, historically, X.
Of course you are free to do what you want.
I am aware of gobolinux -the 'links spaghetti' distro. You'll remember me referring you to a distro which changes the dir structure completely as hard-coded changes in all programs including the kernel. The problem with this approach and that of gobo is that a lot of extra steps have to made for each and every prgram and library.
You may be interested in looking at the AppDir system for creating programs that live entirely in their own dir. I have created a generic AppDir package which makes it pretty easy to create your own AppDirs, called AppBuilder.
You can find it and a couple of dozen pre-made AppDirs here:
http://distro.ibiblio.org/pub/linux/...nload/AppDirs/

If a system is fundamentally insecure, does it matter how well it would otherwise perform? If that system is in fact a server, providing applications and services to multiple computers of various architectures, which are all depending on that single server to provide them with essential services, how much more important is it, to have security as the highest concern?

So let me ask some more questions. If a system is built from the beginning to use a file structure like the one that I've suggested, and we take as a given that packaging conforms strictly to that designated format, how likely would the following ever be prone to occur:

1. Could such a system ever have it's binaries or libraries overwritten?
2. Could a root install of any package ever cause the system to break by the above?
3. Would it be more or less possible to track/block malicious software in that system?

Shingoshi

Since that was the reason this thread was started in the frist place, it's ironic that the whole issue of what to label the libdirs for each arch, has been completely eliminated by my suggested directory system.

I was thinking that the entire system should be thought of as a website. Which means, httpd (or something similar) would be critical to the management of the operating system.

I have another question also. Is it possible to use "in place" the compiled files from a source, without having to run "make install"? In other words, can the original source tree be left alone, and run the programs from it, without installing them elsewhere? What would be required to do this? I am thinking specifically of those sources which have no installation instructions, or don't make use of DESTDIR. This would especially come in handy for sources obtained from cvs, svn, git or other similar means. If it is possible, you could completely do away with packages as we know them now. And software updates would likely be less of a nightmare. Without having to be concerned about installation procedures, management would cease being a thing of great concern.

Shingoshi

As far as binaries are concerned, in order to be able to run them from 'odd' locations, you must either include their location in your path or create wrappers which go in your path which call the program in question.
Libraries are the real problem, though. Again, if you want programs to be able to dind them then an entry must be created in your ld.so.conf file which points to the directory where they are. This can get quite messy when you have lots of libs and programs. And since these libs (and headers) must be present and located when compiling programs, you have to take extra steps when compiling to make sure everything gets found, -like passing --libdir, --includesdir, -bindir and --sbindir to configure and then including LDFLAGS and possibly GCC_INCLUDES environmental variables. You have to do this for each package. It really is a lot of trouble and no-one has come up with a satisfactory way to resolve it in any sort of universally applicable way. This is why the standard directory structure and paths are som important. Even the above steps won't work for everything because many programs and libs have some of the paths hard-coded into the program and must be patched if you are to make changes.

Designing and creating a multi-lib or multi-arch system is very complicated. It is much simplified by using standardized locations for the libraries, at least. Putting wrappers in the path for binaries in non-standard locations is then much easier. Otherwise your wrappers must include a system-wide search for the needed libraries and set LD_LIBRARY_PATH as well as PATH. Or you must, as stated, modify /etc/profile to add each binary's location to the PATH and ld.so.conf to add the location of each library.

I think you need to ask yourself why you are trying to do everything in a different way and if the effort will provide any true advantages. Plus, if you start thoroughly testing some of the stuff you have already built, I think you'll find that it is not all working to perfection. Working out the nagging details for each and every program is gonna be a royal PITA. And autoconf is not your friend in these cases.

About security issues, it is entirely your call as to how important it is or what your priorities are. If you have installed libs and programs to non-standard locations its is very unlikely that they would be overwritten by other installations.

Be sure to update to the latest bug-fix version(1.9.5):
http://distro.ibiblio.org/pub/linux/...nload/src2pkg/

Gilbert,
I wrote this yesterday, before you responded below to the last thing I had written. I am still working out the details of my concept. But at least it is somehow comforting knowing that I'm not the only one thinking about this. It also helps being able to see what others like GoboLinux have achieved in addressing these very same issues. It also gives me an appreciation of how difficult it is to do this, and the amount of resistance one faces by even suggesting such a thing. So read what I have below, in the context of this definitely being a work-in-progress.

There is something particularly intriguing about GoboLinux, and the way that it organizes programs in it's system. And it has me thinking that something of a hybrid of Slackware's source/package tree and GoboLinux's model, is in order. In Slackware, we currently have the following directories:

a
ap
c >> This directory would be eliminated, by each arch having it's own tree.
d
e
f
k
kde
kdei
l
n
t
tcl
x
xap
y

Taking into account my model of doing things, these can easily be changed, and be the basis for grouping all applications on the system. All of these would be subdirectories of /Programs.

/Base-System
/Administration
/Programming
/Editors
/Education
/FAQ
/Games
/Gnome
/Graphics
/Kernel
/KDE
/KDEI
/Libraries
/Multimedia
/Networking
/Office
/X-Window
/Window-Apps

An even more thorough method would be to use the packaging organization used by ports systems like Gentoo, Net|FreeBSD. I like the idea of using Gentoo's even better than Slackware's. Since the packages are very well organized, and their directory location within the ports can be used as part of the prefix during compilation of each package. Given the requirement of compiling my own software for this distribution, attempting to maintain adherence to Slackware, which doesn't provide such a system as ports, and likely never will, makes no sense logistically. This only reinforces my desire to use Gentoo as my build engine.

With some modifications to the operations of src2pkg, I will be able to take full advantage of the more comprehensive environment provided by Gentoo, which would ensure higher success in attempting to compile packages for a separate distribution like Slackware, which is comparatively limited.

Given my own personal preference for KDE, I would likely consider using the menu structure of KDE as my root application directory structure. So I have actually reorganized the list above to reflect that.

Shingoshi

I'm in the process of creating a script tool for setting up new chroot environments using the Gentoo stages. I want to have a means to download/install the latest copy of src2pkg every time this script is run. Then all I will have to do, is:

wget http://distro.ibiblio.org/pub/linux/...pkg-latest.tgz

Shingoshi

If there is no restriction on the use of variables in /etc/ld.so.conf, none of this will be an issue. And even if variables are forbidden in that file, I can still do the same thing as I did for wine, when I placed it in a non-standard location. This was the script which I created for locating the binaries, as I had intended to place them before:

THE OLD:
=====================================
#!/bin/sh

# /etc/profile.d/multiarch.sh
# This is our multiarch PATH configuration script.

for arch in $(cd /lib/modules/$(uname -r)/source/arch; ls -d *)
do
export PATH="$PATH:/$arch/usr/bin:/$arch/usr/sbin"
done
=====================================
THE NEW:
=====================================
for arch in $(cd /lib/modules/$(uname -r)/source/arch; ls -d *)
do
binpath="/cluster/Programs/$GROUP/$NAME/$VERSION/$ARCH/bin:"
sbinpath="/cluster/Programs/$GROUP/$NAME/$VERSION/$ARCH/sbin:"
mkdir -p $binpath $sbinpath #(Creating my directories during configuration)
export PATH="$PATH:$binpath:$sbinpath:"
done

Yes, there are undoubtedly errors in the above! That code will be run for every new package that is compiled and later installed. So the variables $pname and $pvers will come directly from the build's configuration process.

I can simply change this to the above lines for the binaries, and write something similar for the libraries. I think this should be the correct way to write it:
echo "/cluster/Programs/$GROUP/$NAME/$VERSION/$ARCH/lib" | cat >> /etc/ld.so.conf

Although, I might be able to do this instead:
echo "/cluster/Programs/$GROUP/*/*/*/lib" | cat >> /etc/ld.so.conf
If the above line works, I would only have to do it once, and not for each and every
package that's compiled.

Shingoshi

bash-3.1# $PATH
bash: /sbin:/bin:/usr/sbin:/usr/bin:/usr/pkg/bin:/root/buildpkg/bin:/usr/portage/bin:
/usr/local/bin:/usr/bin:/bin:/usr/X11R6/bin:/usr/games::/usr/lib64/java/bin:
/usr/lib64/java/jre/bin:/usr/lib64/java/bin:/usr/lib64/java/jre/bin:/alpha//usr/bin:
/arm//usr/bin:/avr32//usr/bin:/blackfin//usr/bin:/cris//usr/bin:/frv//usr/bin:/h8300/usr/bin:
/i386//usr/bin:/ia64//usr/bin:/m32r//usr/bin:/m68k//usr/bin:/m68knommu//usr/bin:
/mips//usr/bin:/parisc//usr/bin:/powerpc//usr/bin:/ppc//usr/bin:/s390//usr/bin:
/sh//usr/bin:/sh64//usr/bin:/sparc//usr/bin:/sparc64//usr/bin:/um//usr/bin:/v850//usr/bin:
/x86_64//usr/bin:/xtensa//usr/bin:/usr/pkg/bin:/usr/pkg/sbin::/usr/lib64/qt/bin:/usr/share/texmf/bin:
/home/shingoshi/bin:/xtensa//usr/bin:

I don't know why there are double "//" in the paths having an arch prefix. But I know that it does work.

Gilbert,
It appears that one of the things you've repeatedly spoken about, specifically the hardcoding of locations in binaries and libraries, can be disabled by using --disable-rpath, in those sources which allow it.

From Wikipedia:
The primary disadvantage of use RPATH is that it overrides the LD_LIBRARY_PATH settings which makes things like running a precompiled binary out of a user's home directory or some other non-default location difficult or impossible. Use of RPATH also makes it difficult, if not impossible, to upgrade libraries without forcing a reinstallation of all the software dependent on (even the older versions of) the libraries (see RPATH considered harmful).

Given the information above, it seems I must always disable this in all of my future builds, if I'm going to be able to successfully relocated binaries and libraries at my discretion.

Shingoshi

Notice that I still have /usr/ib/pkgconfig:

./
usr/
usr/share/
usr/share/xcb/
usr/share/xcb/xcb.xsd
usr/share/xcb/xproto.xml
usr/share/xcb/bigreq.xml
usr/share/xcb/composite.xml
usr/share/xcb/damage.xml
usr/share/xcb/dpms.xml
usr/share/xcb/glx.xml
usr/share/xcb/randr.xml
usr/share/xcb/record.xml
usr/share/xcb/render.xml
usr/share/xcb/res.xml
usr/share/xcb/screensaver.xml
usr/share/xcb/shape.xml
usr/share/xcb/shm.xml
usr/share/xcb/sync.xml
usr/share/xcb/xc_misc.xml
usr/share/xcb/xevie.xml
usr/share/xcb/xinerama.xml
usr/share/xcb/xf86dri.xml
usr/share/xcb/xfixes.xml
usr/share/xcb/xprint.xml
usr/share/xcb/xtest.xml
usr/share/xcb/xv.xml
usr/share/xcb/xvmc.xml
usr/lib64/
usr/lib64/pkgconfig/
usr/lib64/pkgconfig/xcb-proto.pc
usr/doc/
usr/doc/xcb-proto-1.1/
usr/doc/xcb-proto-1.1/COPYING
usr/doc/xcb-proto-1.1/INSTALL
usr/doc/xcb-proto-1.1/NEWS
usr/doc/xcb-proto-1.1/README
usr/doc/xcb-proto-1.1/TODO
usr/lib/
usr/lib/pkgconfig/
usr/lib/pkgconfig/xcb-proto.pc
install/
install/slack-desc
/usr/libexec/src2pkg/static/tar-1.13: xcb-proto-1.1-x86_64-1panoplyx.tar is the archive; not dumped

Gzipping xcb-proto-1.1-x86_64-1panoplyx.tar to xcb-proto-1.1-x86_64-1panoplyx.tar.gz
Renaming xcb-proto-1.1-x86_64-1panoplyx.tar.gz to xcb-proto-1.1-x86_64-1panoplyx.tgz
Moving xcb-proto-1.1-x86_64-1panoplyx.tgz to /usr/src/panoplyx/PACKAGES

Package Creation - Successful! - Package Location:
/usr/src/panoplyx/PACKAGES/xcb-proto-1.1-x86_64-1panoplyx.tgz

Shingoshi

No, this is fixed in 1.9.6 which I am working on. Lot of new changes going in this time. I'll upload it in a few days, I guess.

It's ok. It's not like I didn't have a work-around for it. I just mistakenly thought it was gone. So when I checked to find out if it was, I realized it wasn't. Please, Please Please, also make a link to the latest copy of src2pkg, so it can be grabbed with "wget $mirror/src2pkg.latest.tgz"

Shingoshi