Suddenly "not a dynamic executable" Error Encountered

[rockedge]

As the title indicates on a F96-CE_4 system after some compiling and installing dependencies has begun to throw a message when starting for example lxterminal or xterm (urxvt):

Screenshot(45).jpg (13.07 KiB) Viewed 1486 times

[rockedge]

Any ideas on how to fix it?

[bigpup]

Everything look good with the properties of the programs exec file?

lxterminal

urxvt

Maybe something talked about here is a clue:
https://askubuntu.com/questions/1097900 ... executable

[Wiz57]

This is just a "best guess", but are those 2 term programs compiled "statically"? If so, then it may be a
case of mismatched glibc. As I said though, this is only my best guess off the top of my head.
Wiz

[rockedge]

This is just a "best guess", but are those 2 term programs compiled "statically"? If so, then it may be a case of mismatched glibc. As I said though, this is only my best guess off the top of my head.
Wiz

This must be it. All the research into a cause and fix has led me to the same idea.

But what is the best scenario to fix it? Some how the glibc has been changed but I am looking at what to remove and restore. I installed the package binutils at some point as well.

[bigpup]

In PPM uninstall.

Anything listed for glibc that got installed?
If yes.
That could have changed the glibc version now being used.

[mikewalsh]

Hang about, hang about.

Now, I may be completely off the mark here.....but my understanding of static compiling is that the final item, at the end of the compiling process, has been linked against everything it requires to run, and those 'links' are somehow permanently 'fixed'. Not just dependencies like libs, etc.....but "basic" stuff like the glibc, too.

I'm remembering back some years, when we were discussing Barry's EasyDD utility he supplies with EasyOS. He offered up a statically-compiled 'dd' binary - compiled with musl, I believe - which I used to construct the EasyDD-portable. It didn't matter what Puppy you threw it at......architecture, glibc, whatever; that thing still ran.

I believe a 'true' statically-compiled binary has been built/linked against 'static' versions of everything else, too. Of course, I could be completely wrong in this assumption. I'm willing to be corrected.

Ah. Good summary here. Static linking makes a copy of the library actually into a part of the final executable. Which explains why statically-linked stuff is always considerably larger:-

Barry's 'dd' was almost 3 times bigger than an equivalent dynamically-linked version would have been......but the upshot was that it was able to run anywhere.

Mike.

[rockedge]

@mikewalsh there is a good chance you are on to something here. I did compile plocate and it certainly was a bit hectic and I started throwing in dependencies to get it to build correctly.

[mikewalsh]

@rockedge :-

Like I said, Erik, I could be completely wrong here. But as I understand it, a statically-compiled item will only "interfere" with the rest of the system if you've got it in the $PATH, where other items might call it. Those other items might also expect to find different library items associated with it, as though it were dynamically-linked, I suppose.

This is about the limits of my understanding as far as this stuff goes. I'm definitely no "expert"!

See the diagram I've added above.

Mike.

[mikewalsh]

@rockedge :-

Any "progress" on this, Erik? Just out of sheer curiosity, like....

Mike.

[rockedge]

@mikewalsh Still working on it! Though it doesn't seem to effect the terminal programs in their operation, I am trying to find a fix without destroying the system.

[Burunduk]

It's possible to reproduce this behavior on Fossapup64-9.5 by running echo ldd /bin/busybox >/etc/profile.d/test. Could it be that some weird file has been added to /etc/profile.d?

Edit: not a dynamic executable looks like a typical output of the ldd command. When bash starts, it runs two files: /etc/bash.bashrc and /root/.bashrc. The /root/.bashrc on Fossa is sourcing /etc/profile that is sourcing every file in /etc/profile.d (except *.txt).

So, it may be ldd commands somewhere in the /etc/profile or .bashrc or bash.bashrc files or in one of the files in the /etc/profile.d directory.

[rockedge]

@Burunduk Thanks for the tips! I managed to fix it using your information.

Turns out there is a file /etc/profile.d/gtkdialog that contains:

Code: Select all

if ldd $(which gtkdialog) | grep -Fq 'gtk-3' ; then #gtk3
	GTKDIALOG_BUILD=GTK3
elif ldd $(which gtkdialog) | grep -Fq 'gtk-X11-2' ; then #gtk2
	GTKDIALOG_BUILD=GTK2
fi
export GTKDIALOG_BUILD

which to test I commented out all the lines and the message no longer appears! Once I read the post I realized what the search results were saying when mentioning ldd.

Wondering when this was added to the /etc/profile.d directory.

[radky]

Wondering when this was added to the /etc/profile.d directory.

@rockedge

If I understand correctly, /etc/profile.d/gtkdialog was implemented when Woof-CE began the transition from gtk2 to gkt3 builds. The exported GTKDIALOG_BUILD variable is called in multiple scripts to define the gtk version of the current Puppy build.

For gtkdialog scripts, this allows the use of widget parameters (either gtk2 or gtk3) that are compatible with the application GUI. Unfortunately, some of our older Puppy applications do not port correctly to gtk3, in which case the legacy gtkdialog (renamed as gtk2dialog) is available in recent Puppy builds for compatibility with the problematic legacy applications.

The current version of /etc/profile.d/gtkdialog (as implemented in F96) is from the following Woof-CE commit of Sep 8, 2022:

https://github.com/puppylinux-woof-CE/w ... 852308c24d

[rockedge]

@radky Yes I realize the gtk2dialog usage scenario because we use a symlink to /usr/local/bin/gktdialog-8.5 complied against gtk2 in KLV-Airedale and KLV-Spectr providing the same feature as in F96-CE_4. The script must of worked until something changed recently when using some different compiling methods to build a package for plocate.

So tracking down the actual root cause still is on going. Commenting out the lines in the script may cause other pieces to fail. Because until a few days ago it worked as expected.

[rcrsn51]

Maybe you can just hide the error message with "2>/dev/null".

[dimkr]

This can happen if you replace /usr/sbin/gtkdialog with a script. What did you install?

[rockedge]

@dimkr that's the thing, I didn't replace anything in /etc/profile.d that I know of. I installed plocate
which I have also been experimenting with. Not a game changer but it setup easily and runs. Perhaps /usr/local/sbin/updatedb played a role. But I am just throwing out ideas as to what I broke.

Code: Select all

meson setup obj
ninja
addgroup --system plocate
ninja install
/usr/local/sbin/updatedb

more info here -> https://plocate.sesse.net/

Code: Select all

# plocate --help
Usage: plocate [OPTION]... PATTERN...

  -b, --basename         search only the file name portion of path names
  -c, --count            print number of matches instead of the matches
  -d, --database DBPATH  search for files in DBPATH
                         (default is /var/local/lib/plocate/plocate.db)
  -i, --ignore-case      search case-insensitively
  -l, --limit LIMIT      stop after LIMIT matches
  -0, --null             delimit matches by NUL instead of newline
  -N, --literal          do not quote filenames, even if printing to a tty
  -r, --regexp           interpret patterns as basic regexps (slow)
      --regex            interpret patterns as extended regexps (slow)
  -w, --wholename        search the entire path name (default; see -b)
      --help             print this help
      --version          print version information