binutils, what is /share/locale/uk/LC_MESSAGES/bfd.mo for? - Page 1
Forum section: electronics / general

author: legacy
author_rank: Super Contributor
timestamp: February 03, 2019, 06:29:40 pm
content: so I am trying to create an overlay for Gentoo with a simple folder schema:Code:lsp /usr/idp/F /usr/idp/binF /usr/idp/m68hc11-elfF /usr/idp/riscv32-unknown-elfF /usr/idp/shareas you can see binaries go into /usr/idp/bin, while specific files go to the $target folderbut I also have a "share" folder, which containsCode:lsp /usr/idp/shareF /usr/idp/share/infoF /usr/idp/share/localeF /usr/idp/share/manand /share/locale/uk/LC_MESSAGES contains a lot of .mo files, e.g. bfd.mowhat is it useful for?I have to care about "collisions", because if I emerge a toolchain there are files with the same filename that collide into the same and /share/locale/uk/LC_MESSAGES folderThis is no good for how Gentoo works.

author: legacy
author_rank: Super Contributor
timestamp: February 03, 2019, 11:49:47 pm
content: Code:2019-01-30--07-36-22---2019-01-30--07-37-26 - [ dev-embedded/m68hc11-assembler ] - success - @2.29.1/7.3.02019-01-30--07-42-22---2019-01-30--07-56-28 - [ dev-embedded/m68hc11-binutils ] - success - @2.29.1/7.3.02019-01-30--08-07-40---2019-01-30--08-14-18 - [ dev-embedded/m68hc11-gcc ] - success - @2.29.1/7.3.02019-02-03--18-59-37---2019-02-03--20-13-22 - [ dev-embedded/riscv32-binutils ] - success - @2.29.1/7.3.0I am finalizing the Overlay for the dev-embedded stuffwhat if I simply remove these ".mo" files from the install procedure?I don't understand what they are for, and which tool inside binutils should need them.p.s.I have also disabled some featuresCode:# Disable modules that are in a combined binutils/gdb tree. #490566conf="$conf --disable-gdb "conf="$conf --disable-libdecnumber "conf="$conf --disable-sim "# Strip out broken static link flags.# https://gcc.gnu.org/PR56750conf="$conf --without-stage1-ldflags "

author: amyk
author_rank: Super Contributor
timestamp: February 04, 2019, 12:00:13 am
content: Like the path says, they are the messages (text strings)the program prints out, if you delete those files either the program will become completely mute or might default to English (in which case you may omit the .mo files.)

author: sleemanj
author_rank: Super Contributor
timestamp: February 04, 2019, 02:06:09 am
content: Compiled language translation files, seeGNU gettext

author: legacy
author_rank: Super Contributor
timestamp: February 04, 2019, 11:29:11 am
content: Quote from: sleemanj on February 04, 2019, 02:06:09 amthanks!can these files be removed, or can binutils be compiled without them?the reason I ask is simple: only these files make collisions for different toolchains, and this is a problem for Gentoo, specifically for the install procedure that needs a trick in order to avoid complete failure.Collisions are assumed to be a BAD event for the sandbox during the processing.Code:# lsp /usr/idp/bin/*708 Kbyte /usr/idp/bin/m68hc11-elf-addr2line772 Kbyte /usr/idp/bin/m68hc11-elf-ar1 Mbyte /usr/idp/bin/m68hc11-elf-as3 Mbyte /usr/idp/bin/m68hc11-elf-cc1708 Kbyte /usr/idp/bin/m68hc11-elf-c++filt130 Kbyte /usr/idp/bin/m68hc11-elf-cpp65 Kbyte /usr/idp/bin/m68hc11-elf-elfedit837 Kbyte /usr/idp/bin/m68hc11-elf-gprof1 Mbyte /usr/idp/bin/m68hc11-elf-ld1 Mbyte /usr/idp/bin/m68hc11-elf-ld.bfd708 Kbyte /usr/idp/bin/m68hc11-elf-nm902 Kbyte /usr/idp/bin/m68hc11-elf-objcopy1 Mbyte /usr/idp/bin/m68hc11-elf-objdump772 Kbyte /usr/idp/bin/m68hc11-elf-ranlib581 Kbyte /usr/idp/bin/m68hc11-elf-readelf708 Kbyte /usr/idp/bin/m68hc11-elf-size708 Kbyte /usr/idp/bin/m68hc11-elf-strings902 Kbyte /usr/idp/bin/m68hc11-elf-strip70 Kbyte /usr/idp/bin/m68hc11-mos-as65 Kbyte /usr/idp/bin/m68hc11-mos-ld965 Kbyte /usr/idp/bin/riscv32-unknown-elf-addr2line1 Mbyte /usr/idp/bin/riscv32-unknown-elf-ar1 Mbyte /usr/idp/bin/riscv32-unknown-elf-as964 Kbyte /usr/idp/bin/riscv32-unknown-elf-c++filt65 Kbyte /usr/idp/bin/riscv32-unknown-elf-elfedit7 Mbyte /usr/idp/bin/riscv32-unknown-elf-gdb3 Kbyte /usr/idp/bin/riscv32-unknown-elf-gdb-add-index1 Mbyte /usr/idp/bin/riscv32-unknown-elf-gprof1 Mbyte /usr/idp/bin/riscv32-unknown-elf-ld1 Mbyte /usr/idp/bin/riscv32-unknown-elf-ld.bfd965 Kbyte /usr/idp/bin/riscv32-unknown-elf-nm1 Mbyte /usr/idp/bin/riscv32-unknown-elf-objcopy1 Mbyte /usr/idp/bin/riscv32-unknown-elf-objdump1 Mbyte /usr/idp/bin/riscv32-unknown-elf-ranlib774 Kbyte /usr/idp/bin/riscv32-unknown-elf-readelf965 Kbyte /usr/idp/bin/riscv32-unknown-elf-size965 Kbyte /usr/idp/bin/riscv32-unknown-elf-strings1 Mbyte /usr/idp/bin/riscv32-unknown-elf-stripnote that binaries have a prefix, but the GNU configure cannot do it for the *.mo filesIdeally, a workaround would look like thisCode:lsp /usr/idp/share/locale/uk/LC_MESSAGES_hypothetical/*186 Kbyte /usr/idp/share/locale/uk/LC_MESSAGES/m68hc11-bfd.mo231 Kbyte /usr/idp/share/locale/uk/LC_MESSAGES/m68hc11-binutils.mo560 Kbyte /usr/idp/share/locale/uk/LC_MESSAGES/m68hc11-gas.mo12 Kbyte /usr/idp/share/locale/uk/LC_MESSAGES/m68hc11-gprof.mo73 Kbyte /usr/idp/share/locale/uk/LC_MESSAGES/m68hc11-ld.mo34 Kbyte /usr/idp/share/locale/uk/LC_MESSAGES/m68hc11-opcodes.mo249 Kbyte /usr/idp/share/locale/uk/LC_MESSAGES/riscv32-bfd.mo322 Kbyte /usr/idp/share/locale/uk/LC_MESSAGES/riscv32-binutils.mo665 Kbyte /usr/idp/share/locale/uk/LC_MESSAGES/riscv32-gas.mo12 Kbyte /usr/idp/share/locale/uk/LC_MESSAGES/riscv32-gprof.mo156 Kbyte /usr/idp/share/locale/uk/LC_MESSAGES/riscv32-ld.mo63 Kbyte /usr/idp/share/locale/uk/LC_MESSAGES/riscv32-opcodes.mothe above was obtained by a manual script, sort of file rename, but this way a binary (gettext?) that needs to read the %.mo won't find it since it will look for a renamed.so it should be done in the ./configure for coherency

author: sleemanj
author_rank: Super Contributor
timestamp: February 04, 2019, 11:34:27 am
content: If you are only dealing in English (US english probably) you can probably do without them.

author: legacy
author_rank: Super Contributor
timestamp: February 04, 2019, 11:39:26 am
content: Code:conf="$conf --without-included-gettext "conf="$conf --disable-nls "I am trying this

author: BloodyCactus
author_rank: Frequent Contributor
timestamp: February 04, 2019, 03:07:00 pm
content: cant you just crosscompile the toolchain to be with --prefix=/usr/idp/ ? and just build all of it that way and its correct.

author: legacy
author_rank: Super Contributor
timestamp: February 04, 2019, 03:40:06 pm
content: Quote from: BloodyCactus on February 04, 2019, 03:07:00 pmno, it's not correct. Gentoo forces a toolchain to be segregated in a specific prefixe.g.Code:# gcc-config -l hppa2.0-unknown-linux-gnu-4.1.2 hppa2.0-unknown-linux-gnu-4.2.4 hppa2.0-unknown-linux-gnu-4.4.7 hppa2.0-unknown-linux-gnu-4.9.3 hppa2.0-unknown-linux-gnu-5.4.0 hppa2.0-unknown-linux-gnu-6.4.0 hppa2.0-unknown-linux-gnu-7.3.0 * hppa64-unknown-linux-gnu-4.9.4 hppa64-unknown-linux-gnu-6.4.0 hppa64-unknown-linux-gnu-7.3.0 * m68hc11-elf-3.3.6 * m68k-elf-4.1.2 * m68k-unknown-linux-gnu-4.1.2 * mips-unknown-linux-gnu-5.3.0 * mips64-unknown-linux-gnu-5.3.0 * powerpc-unknown-linux-gnu-5.3.0 *it means --prefix is ={ /usr/hppa2.0-unknown-linux-gnu, /usr/hppa64-unknown-linux-gnu, /usr/m68hc11-elf, /usr/m68k-elf, /usr/m68k-unknown-linux-gnu, /usr/mips-unknown-linux-gnu, /usr/mips64-unknown-linux-gnu, /usr/powerpc-unknown-linux-gnu }unfortunately, this approach depends oncrossdev, which usually profiles for Linuxso these two toolchains need an override patch in order to force crossdev to avoid considering them as "sources" for "cross-emerging" toolsCode: m68hc11-elf-3.3.6 * m68k-elf-4.1.2 *anyway, in order to make my life easier, I am considering barebone toolchains as independent things, so they are not handled bycrossdev(which does a great job, but it's too centralized and difficult to be handled when you want something "special")In my case, --prefix=/usr/idp/ is in use and itcauses collisionwith some files on different toolchains.I want everything inside /usr/idp; all goes as it should, except { 68hc11, riscv, etc } with --prefix=/usr/idp/ all collide /usr/idp/share/*.mo files, and this is a problem for the sandbox since a collision is a bad event that makes the install process to fail.Anyway, I have now hacked the Makefile, removed gdb, and other stuff, and now it's working as it shouldI had to- to create a fake Gdb Makefile, because Gdb tries to compiles things which try to install crap- to disable nls- to disable gettext