[SOLVED] /usr/lib and /usr/lib64

bartgymnast · 11-19-2013, 03:42 AM

In my personal knowledge the /usr/lib64 directory is used for the 64bit libraries of programs.

Is it intended to have have also the binary programs placed here, for example:

Code:

root@Slack64-14-1:/usr/lib64/xfce4/session# ls -l
total 20
-rwxr-xr-x 1 root root 1594 Sep  8 00:55 balou-export-theme*
-rwxr-xr-x 1 root root 2818 Sep  8 00:55 balou-install-theme*
drwxr-xr-x 2 root root 4096 Sep  8 00:55 splash-engines/
-rwxr-xr-x 1 root root 6712 Sep  8 00:55 xfsm-shutdown-helper*

shouldn't these be in: /usr/libexec/ (for example)

these are a few more of these examples.
and if it is intended to be in /usr/lib64, why is this.

GazL · 11-19-2013, 04:36 AM

The FHS guys in their infinite wisdom decided that it's ok for applications to dump secondary executables and suchlike in /usr/lib/<appname> rather than /usr/libexec. Personally I'm with you and would much rather see a /usr/lib that only contains things ending in .so or .a but those days are gone.

bartgymnast · 11-19-2013, 05:13 AM

actually I can understand that for multi-lib purposes some binaries are /usr/lib{LIBDIRSUFFIX}

however, and I think this is an issue in this case on slackware64
shouldn't the locale directory be in /usr/lib/locale instead of /usr/lib64/locale

because regardless of being on a 64bit system, these files would not change, and should be in /usr/lib/locale

I am not sure how many other package/directories are in lib64 that imo should be in /usr/lib as due to the above statement.

GazL · 11-19-2013, 05:40 AM

My personal preference is for the debian way of doing multilib with a /lib and /lib32 on 64bit systems, which would have avoided the ugliness we see on Slackware with the artificial /lib /lib64 split.
It's not a big deal, just a matter of aesthetics (much like not having non-libraries in /usr/lib).

bartgymnast · 11-19-2013, 06:00 AM

if I look in the glibc.SlackBuild (64bit even)

you find the following patch being used:
# Use old-style locale directories rather than a single (and strangely
# formatted) /usr/lib/locale/locale-archive file:
zcat $CWD/glibc.locale.no-archive.diff.gz | patch -p1 --verbose || exit 1

even the patch suggest that the locale directory would be in /usr/lib/locale

GazL · 11-19-2013, 06:30 AM

You can't read anything into that. Clearly Pat just didn't change the comment in the 64bit version of the slackbuild.

bartgymnast · 11-19-2013, 07:34 AM

I just checked the whole glibc source.

in the ChangeLog.10 this is mentioned.

Code:

        * sysdeps/unix/sysv/linux/configure.in: For sparc64, put locale
        stuff into $exec_prefix/lib/locale because it can be shared between
        32bit and 64bit libraries.

also in the rest of the source (following files)

Code:

manual/locale.texi
timezone.private.h (#define LOCALE_HOME             "/usr/lib/locale")
sysdeps/gnu/configure(.in)

I never considered it an issue, untill recently with some software packages that have this hardcoded aswell.

the other locale directories are fine /usr/share/locale/ and /usr/share/i18n/

Didier Spaier · 11-19-2013, 07:51 AM

Well glibc is the provider, but main user is gettext.

gettext expects to find locale definitions in /usr/lib/locale or /usr/lib64/locale depending on the architecture and translation files in /usr/share/locale/<locale>/LC_MESSAGES, unless TEXTDOMAINDIR be set to another value than the default /usr/share/locale.

I don't see a need to change that.

bartgymnast · 11-19-2013, 09:21 AM

according to the gettext manual at gnu.org
it expects TEXTDOMAINDIR at $(datadir)/locale
unless you (script writer defines it otherwise)

and gettext is 1 of many tools, it is not the only tool.

glibc however, I noticed in the Makeconfig it sets it to libdir/locale

it is clear now.

Didier Spaier · 11-19-2013, 11:21 AM

Quoted from gettext's manual:

Quote:

11.2.3 Locating Message Catalog Files

Because many different languages for many different packages have to be stored we need some way to add these information to file message catalog files. The way usually used in Unix environments is have this encoding in the file name. This is also done here. The directory name given in bindtextdomains second argument (or the default directory), followed by the name of the locale, the locale category, and the domain name are concatenated:
dir_name/locale/LC_category/domain_name.mo The default value for dir_name is system specific. For the GNU library, and for packages adhering to its conventions, it's:
/usr/local/share/locale locale is the name of the locale category which is designated by LC_category. For gettext and dgettext this LC_category is always LC_MESSAGES.3 The name of the locale category is determined through setlocale (LC_category, NULL). 4 When using the function dcgettext, you can specify the locale category through the third argument

bartgymnast · 11-19-2013, 02:23 PM

point me where it says libdir there didier.

but like I said, doesnt matter, glibc actually sets this in Makeconfig file

Didier Spaier · 11-19-2013, 02:51 PM

OK, maybe I just misunderstood what you meant.

<OT>As you live in the Netherlands, I guess you speak Dutch? Maybe you could join the Dutch translation team of the slint project? </OT>

jtsn · 11-19-2013, 03:07 PM

Quote:

Originally Posted by GazL

My personal preference is for the debian way of doing multilib with a /lib and /lib32 on 64bit systems, which would have avoided the ugliness we see on Slackware with the artificial /lib /lib64 split.

Debian made that mistake and it caused a lot of ugly issues and breakage. For further comments on that topic, see http://utcc.utoronto.ca/~cks/space/b...b64VersusLib32