SlackwareThis Forum is for the discussion of Slackware Linux.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
the 32bit static binary of 1.99.5 released seems to work only on a pure 64bit system, it doesn't work on a multilib system and neither on a 32bit system.
I suspect there's something screwy in the way the texmacs devs assemble the binary they redistribute that makes it segfault when it finds some 32bit stuff conflicting with what he has already compiled in statically.
So what is in 4.4.16 that wasn't in 4.4.14? (It's not that important, I am merely curious.)
Did you try using strace on the texmacs binary?
On 4.4.16: I am compiling my kernel myself anyway, and -current has moved to 4.4.16 without even upgrading glibc, so figure that 4.4.16 merely fixes some bugs and is a harmless upgrade. I was fairly careful to check that important options in the -current config for 4.4.16 matched with my config as I was going through "make menuconfig". Then, I even decided to look through the .config files themselves, and found CONFIG_FRAME_VECTOR=y that I am still trying to understand what it is supposed to do. There is more on this in other messages in this thread.
strace will print out a mind-boggling amount of stuff, but the last 100 lines or so of output may provide a clue when the segfault happens.
On the strace: I have posted strace output in another message in this thread. texmacs appears to SIGSEGV after calling mmap2. I do not understand why it segfaults, but perhaps it is trying to access forbidden memory.
Also, do this to install texmacs
Code:
cd
mkdir texmacs-bin
cd texmacs-bin
tar xvf ~/downloads/TeXmacs-1.99.5-x11-i386-pc-linux-gnu.tar.gz
chown -R devel:users TeXmacs-1.99.5-10549M-i386-pc-linux-gnu
ln -s TeXmacs-1.99.5-10549M-i386-pc-linux-gnu texmacs-path
Well, I'm not familiar enough with gdb and backtrace to be of any help there. That was 55020's suggestion. But if texmacs was compiled without debug info, gdb may not provide any insight.
But, what might provide some insight on your issue, since Richard Cranium was able to use it fine on his 14.2 system is to find out what your system is currently running and how you got it there. Based on your thread title, it is easy to assume you're using 14.2. From there, I'm also assuming this is an upgrade from 14.1, right? How did you upgrade from 14.1 to 14.2? If you used slackpkg, do you have anything in your blacklist? Beyond that, do you have programs that were compiled on 14.1 that are still installed with 14.2?
I just tried this on a headless VM running 14.2 64bit (no multilib) and since I don't have X running, it fails, but it seems to get further than yours. So, it seems to indicate it is just an issue with something on your computer. Since it works with a stock 14.2 install, the kernel should not cause your problem.
Code:
jbhansen@desktop-14_2-prep:~/TeXmacs-1.99.5-10549M-i386-pc-linux-gnu$ TEXMACS_PATH=. sh bin/texmacs
QIconvCodec::convertFromUnicode: using Latin-1 for conversion, iconv_open failed
QIconvCodec::convertToUnicode: using Latin-1 for conversion, iconv_open failed
Fontconfig error: "/etc/fonts/conf.d/10-scale-bitmap-fonts.conf", line 70: non-double matrix element
Fontconfig error: "/etc/fonts/conf.d/10-scale-bitmap-fonts.conf", line 70: non-double matrix element
Fontconfig warning: "/etc/fonts/conf.d/10-scale-bitmap-fonts.conf", line 78: saw unknown, expected number
texmacs.bin: cannot connect to X server :0
If you feel further checking with an X session is warranted, I can do that tomorrow after work (it's getting late here and my wife is patiently waiting for me to get to bed). I can also try and spin up a VM running multilib, but I doubt that would make any difference with this.
Have you tried a VM with a fresh install to see if your issues occur there?
I upgraded from slackware64 14.1 to 14.2, including multilib, by first installing a custom-compiled 4.4.16 kernel from the source in -current, but now am using source from kernel.org for 4.4.16. I installed the kernel as described in a prior message in this thread. I booted 4.4.16 while still running slackware64 14.1, and since it worked, I decided it was safe to continue the upgrade to slackware 14.2. I upgraded packages according to instructions substantially the same as in UPGRADE.TXT and according to my notes based on alienbob's older instructions. I have a full rsync of slackware repos for current, 14.2, 14.1 for 64-bit and 32-bit on my hard drive, and I pointed slackpkg to use the slackware64-14.2 repo on my hard drive to begin the upgrade. I also have a full lftp mirror of the multilib repos for 14.1 and 14.2. So, I have all packages locally as I work on upgrading.
I blacklisted:
Code:
#kernel-firmware
kernel-generic
kernel-generic-smp
#kernel-headers
kernel-huge
kernel-huge-smp
kernel-modules
kernel-modules-smp
kernel-source
#
# aaa_elflibs can't be updated.
#
#aaa_elflibs
# You can blacklist using regular expressions.
#
# Don't use *full* regex here, because all of the following
# will be checked for the regex: series, name, version, arch,
# build and fullname.
#
# This one will blacklist all SBo packages:
#[0-9]+_SBo
[0-9]+alien
[0-9]+compat32
# after release upgrade blacklist these
gcc
gcc-g++
gcc-gfortran
gcc-gnat
gcc-java
gcc-objc
glibc
glibc-i18n
glibc-profile
glibc-solibs
#glibc-zoneinfo
The first step was to upgrade onto the new multilib gcc and glibc packages for 14.2, according the instructions, using "upgradepkg" from within my mirror of 14.2 multilib repo. This worked fine and I was able to continue running and upgrading. I run "slackpkg update", and upgraded slackpkg itself first, then
I rebooted and rebult my kernel using upgraded gcc, and have since done a full recompile of the kernel from fresh decompressed sources on the new gcc. I rebuilt my initrd and reran lilo. I rebooted and uninstalled and installed nvidia driver 340.96, reinstalled libvdpau, and rebooted. Basically, I reinstall the kernel and video drivers after the upgrade to further refresh them on the new gcc and libraries, to make sure they match up.
Some SBo packages were upgrade because they became part of slackware, but I now blacklist SBo packages again. All of my hardware works again as before, including hw sensors in ksysguard for cpu and memory temps and fan speeds, and voltages. My audio works, the same as before, mostly... I still execute the rc.alsa and not the rc.pulseaudio... I have custom scripts and custom .asoundrc to change between HDMI sound on TV or SPDIF sound to a stereo that worked well for many years and still works. Everything works well, just this texmacs binary. But it concerns me, because texmacs is an important application for me.
I upgraded my multilib packages, partly using my scripting
Code:
#!/bin/bash
# Upgrade installed compat32 packages from 32-bit slackware-current packages.
#
# The default is to do a dry run that doesn't do anything.
# Pass --go on the command line to do the real stuff.
# Still, nothing happens unless you okay it at prompts that show pending commands.
#
# For each installed pkg *-compat32-* in /var/log/packages:
# Get installed pkg info.
# Find current pkgname in /home/sysop/mirror/slackware32/
# Get current pkg info.
# Get pkgset directory letter/name.
# If version or build is different:
# Prompt to ask to upgrade. If yes:
# convertpkg-compat32 on current pkgname.
# upgradepkg on the resulting /tmp/pkgname
# remove pkg in /root/packages-multilib/<set>-compat32/pkgfile
# mv /tmp/pkgfile /root/packages-multilib/<set>-compat32/
ARCH=${ARCH:-$(uname -m)}
# Location to find 32-bit slackware package set directories <set>/
MIRROR32=/home/sysop/mirror/slackware32-14.2/slackware-14.2/slackware
# Name of MIRROR32 slackware release
MIRROR32_NAME="slackware 14.2"
# Location to store 32-bit slackware compat32 package set directories <set>-compat32/
MULTILIB=/root/packages-multilib/compat32
# Warning: spaces in path/filenames would cause problems with the CMD variables below
# Collect package name/filename of all packages under $MIRROR32 into associative array CURRENTPKG:
# CURRENTPKG[<package name>]=<./set/filename>
# Used later to find slackware-current package filename associated with a package name.
echo "Collecting slackware mirror package information..."
declare -A CURRENTPKG
for i in $( cd $MIRROR32 && find . ../patches | sort -r | grep ".*\.t[xg]z$" ) ; do
PKGFILE=$( basename $i )
PKGNAME=$(echo $PKGFILE | rev | cut -f4- -d- | rev)
CURRENTPKG[${PKGNAME}]=${i}
#echo "PKGFILE=$PKGFILE"
#echo "PKGNAME=$PKGNAME"
#echo "${PKGNAME}=${CURRENTPKG[${PKGNAME}]}"
done
echo "Searching for upgrades..."
# For each installed compat32 package, look for new current version and upgrade
for i in /var/log/packages/*-compat32-* ; do
# Collect info about installed compat32 package
PKGFILECOMPAT=$(basename ${i})
PKGNAME=$(echo ${PKGFILECOMPAT} | rev | cut -f5- -d- | rev)
PKGVERSION=$(echo ${PKGFILECOMPAT} | rev | cut -f3 -d- | rev)
#PKGBUILD=$(echo ${PKGFILECOMPAT} | rev | cut -f1 -d- | cut -f2- -d. | rev)
PKGBUILD=$(echo ${PKGFILECOMPAT} | rev | cut -f1 -d- | rev)
# Collect info about 32-bit slackware-current package
if [ -z ${CURRENTPKG[${PKGNAME}]} ] ; then
echo
echo "Package: ${PKGNAME}, is NOT in ${MIRROR32_NAME}; unable to find upgrade."
echo " Installed: ${PKGFILECOMPAT}"
echo " This package may have been installed special, or it has been removed from slackware-current."
else
CURRENTPKGFILE=$(basename ${CURRENTPKG[${PKGNAME}]})
CURRENTPKGNAME=$(echo ${CURRENTPKGFILE} | rev | cut -f4- -d- | cut -f1 -d/ | rev)
CURRENTPKGVERSION=$(echo ${CURRENTPKGFILE} | rev | cut -f3 -d- | rev)
CURRENTPKGBUILD=$(echo ${CURRENTPKGFILE} | rev | cut -f1 -d- | cut -f2- -d. | rev)
CURRENTPKGSET=$(echo ${CURRENTPKG[${PKGNAME}]} | cut -f2 -d/ )
if [[ (${PKGVERSION} != ${CURRENTPKGVERSION}) || (${PKGBUILD} != "${CURRENTPKGBUILD}compat32") ]] ; then
# Package upgrade is available
echo
echo "Package: ${PKGNAME}, available in ${MIRROR32_NAME}."
echo " Installed: ${PKGFILECOMPAT}"
echo " Available: ${CURRENTPKGFILE}"
echo -n "Upgrade to available version? (y/n)"
read -n 1 ANSWER
echo
if [[ ${ANSWER} = "y" ]] ; then
# Prepare upgrade commands
CMDCONVERT="convertpkg-compat32 -i ${MIRROR32}/${CURRENTPKG[${PKGNAME}]}"
CONVERTPKGFILE="${CURRENTPKGNAME}-compat32-${CURRENTPKGVERSION}-${ARCH}-${CURRENTPKGBUILD}compat32.txz"
CMDMKDIR="mkdir -p ${MULTILIB}/${CURRENTPKGSET}-compat32/"
CMDMV="mv /tmp/${CONVERTPKGFILE} ${MULTILIB}/${CURRENTPKGSET}-compat32/"
CMDRM="rm -f ${MULTILIB}/${CURRENTPKGSET}-compat32/${PKGFILECOMPAT}.txz"
CMDUPGRADE="upgradepkg ${MULTILIB}/${CURRENTPKGSET}-compat32/${CONVERTPKGFILE}"
# Get permission to run upgrade commands
if [[ $1 = "--go" ]] ; then
echo "Performing upgrade... (warning: check pending commands before proceeding)"
echo "Pending: ${CMDCONVERT}"
echo "Pending: ${CMDMKDIR}"
echo "Pending: ${CMDMV}"
echo "Pending: ${CMDRM}"
echo "Pending: ${CMDUPGRADE}"
echo -n "Perform pending commands? (y/n)"
read -n 1 ANSWER
echo
if [[ ${ANSWER} = "y" ]] ; then
${CMDCONVERT}
${CMDMKDIR}
${CMDMV}
${CMDRM}
${CMDUPGRADE}
echo ${CMDMV}
echo ${CMDRM}
else
echo "Upgrade of package aborted."
echo -n "Continue? (y/n)"
read -n 1 ANSWER
echo
if [[ ${ANSWER} != "y" ]] ; then exit ; fi
fi
else
echo "Performing upgrade... dry run, echoing commands only (use --go to perform real upgrade)"
echo "Dry: ${CMDCONVERT}"
echo "Dry: ${CMDMKDIR}"
echo "Dry: ${CMDMV}"
echo "Dry: ${CMDRM}"
echo "Dry: ${CMDUPGRADE}"
echo -n "Continue? (y/n)"
read -n 1 ANSWER
echo
if [[ ${ANSWER} != "y" ]] ; then exit ; fi
fi
fi
# Upgrade done
else
# Package is up-to-date
echo "Package: ${PKGNAME}, is up-to-date."
fi
fi
done
But, I manually ran "upgradepkg --install-new" on all packages in the multilib 14.2 repo, to make sure I got everything. I've manually looked through /var/log/packages to try to see if any packages look very old or where not upgraded. Using my script above, I can usually upgrade the multilib packages, or even add more multilib packages and upgrade them. I pulls packages from the 32-bit release and packages them using the convertpkg-compat32 tool. Overall, I looked a everything. I run an 8-disk mdadm raid6 with luks and lmv on top, and all of that works on 14.2 without requiring any special edits of the initrd or anything else - I checked that the initrd-tree is smart enough to copy the mdadm.conf file and use it to allow udev to incrementally build the array, which is something I used to have to hack slighly to make it do. The upgrade was mostly straightforward and supported my configuration well.
I'm not sure what other details to provide, but the upgrade process is technical and I have given the main details now.
Thanks for the in-depth info on the upgrade. Everything looks relatively good (although, when running upgradepkg with the multilib stuff, I would personally add --reinstall to your command in case any of the version/build numbers happened to stay the same between 14.1 and 14.2 (hopefully they wouldn't), but that is likely just a personal preference in this situation and not the cause of your problem). Am I to understand that you removed your old SBo packages that were compiled with 14.1?
But, based on ponce's post above, it looks like this could be related to multilib. I'll have to wait to get home and I can try to set up a VM to check his observations, but he's a pretty smart guy (one of the admins for SBo and quite the helpful guy on the forum and SBo mailing lists), so I don't expect to find anything different from his results. Would you be willing, as a possibly temporary test, to remove the compat32 packages and revert the multilib packages to the pure 64bit Slackware packages to see if this fixes your seg fault?
the 32bit static binary of 1.99.5 released seems to work only on a pure 64bit system, it doesn't work on a multilib system and neither on a 32bit system.
I suspect there's something screwy in the way the texmacs devs assemble the binary they redistribute that makes it segfault when it finds some 32bit stuff conflicting with what he has already compiled in statically.
ponce,
Thanks for testing that (I'm not really setup here to test much), and providing your findings that it runs on a pure 64-bit slackware64 14.2. So, if I really must run that binary texmacs, I could uninstall the multilib gcc and glibc and go back to the standard pure 64-bit slackware64. I may eventually stop using multilib and I have to look at what I am still using it for, if anything. I was using it for wine and running foobar2000 in wine, but not very often and I could probably do without it.
It could be that it is a screwy binary, because I can run DOOM3 doom.x86
in OpenGL with sound. So, I know 32-bit programs can run on my setup.
I like every program to work on my setup, so this texmacs problem got me worried, but you provide results that are a workaround - dropping the multilib if I really need to run that texmacs binary.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
