In building vim from -current, 7.0.0055, there always remains in /tmp cc* files (.c, .o, .le, .ld) that do NOT belong there. Here's an excerpt from config.log

configure:13837: checking for dlopen()
configure:13853: gcc -o conftest -O2 -fPIC conftest.c -lm -lncurses >&5
/usr/lib64/gcc/x86_64-slackware-linux/5.4.0/../../../../x86_64-slackware-linux/bin/ld: /tmp/ccGAUeJw.o: undefined reference to symbol 'dlopen@@GLIBC_2.2.5'
/lib64/libdl.so.2: error adding symbols: DSO missing from command line

Relevant?

Seems to be some mismatch of versions for libs, includes, ... of glibc, ld, ...?

The spurious cc* appear immediately after running configure.

make, make install are fine. no errors. everything works!

can anyone replicate?

(does NOT appear in my Fedora 24 partition with similar libs, ...)

In the same log file just after the failure you've seen, you'll find another attempt to find dlopen(). This time it succeeds. All that has happened is that the configure script is figuring out how to call dlopen(), including determining what other libs might be needed. The first method it tried failed but the second method succeeded by adding -ldl when it tried to compile its test program. Now the configure script knows that it must add -ldl to the relevant line in the Makefile whenever it's linking anything needing dlopen().

The spurious /tmp/cc* files are harmlessly left over from the configure process. You could add something to remove them after each build but be careful - anything simplistic like rm /tmp/cc* is likely to one day delete more than you intended. I'm surprised the configure script doesn't clean those up itself.

chris

Thanks for the clarification you note in your first paragraph! I've never learned the detailed mechaics of automake/autoconfig/m4 scripting.

I do indeed have a rm -f /tmp/cc* (_temporarily_) & I do realize the danger. And, yes, all functions just fine. But, I've been using the same Vim build script for decades (modified as needed for new features). Only recently (last 6 months or so) did I see this failure of configure to clean up after itself.

The bewildering aspect is that the very same build script in my up-to-date Fedora 24 partition does _not_ generate those spurious cc*s _plus_ the error snippet I quote does not appear. (viz, can't find dlopen@@GLIBC_2.2.5 nor a missing DSO on the CL).

I know this is not at all big deal; I just like everything I build to be "perfect". Usually that is possible in Slackware Linux.

Not only that, I think you'll find that if you build 14.2's version of vim (7.x) in -current, you won't have the left-over files in /tmp. Similarly, if you build -current's version (8.x) in 14.2, there are no left-overs. Also, at the moment, the autotools all have the same versions in both 14.2 and -current, namely:
autoconf-2.69-noarch-1, automake-1.15-noarch-1, libtool-2.4.6-x86_64-4 & m4-1.4.17-x86_64-1, so it's all a bit strange - it only happens with latest version of vim in -current.

chris

I just built the 14.2 vim-7.4.1938 using my -current environment ... and got the same damn 4 cc* in /tmp. It's not vim release dependent.

I no longer have the original v14.2 setup; I usually upgrade the moment PV issues anything in the ChangeLogs.

Weird. Any ideas? Can you replicate any of this?

Thanks. Richard

PS I built a few other random pkgs with -current. So far, only vim does this garbage thing.

Yes that's what I see. My guess is they're generated by gcc when its called during the configure process. One way to contain them is to set a new TMPDIR inside the vim.SlackBuild (somewhere near the beginning) so that gcc puts its intermediate files in there; there delete it at the end of the SlackBuild. What has worked for me is to add:
at the beginning of the SlackBuild; it creates a new directory in /tmp (or whatever else $TMPDIR is already set to). Then, at the end:
In practice, you'd probably want to check that the new $TMPDIR is set to something reasonable before doing rm -rf on it.

chris

I installed a pure 14.2 in a separate partition. No surprise, vim 7.4.x built as expected. But, so did vim 8.x! No garbage. Your intuition is correct.

There have not been many upgrades between 14.2 & -current. I'll slowly try them one by one & see if I can find the troublesome pkg. gcc did go from 5.3 -> 5.4.

I use the mktemp command often in my build scripts.

Stay tuned.

Richard

Chris

I think I got it. grep-2.26 is broken!

Started from the -14.2, adding upgrades & rebuilds, each time doing a vim build. When I went from grep-2.25 to the upgrade 2.26, tons of garbage showed up on my /tmp doorstep.

Can you please verify this. Thanks.

Richard

Yes, grep-2.26 is broken. I changed to grep-2.25 from 14.2 and vim now builds in -current without gcc leaving intermediate files in /tmp.

Actually, I remember now that grep-2.26 in -current has already been found to cause problems - see:
https://www.linuxquestions.org/quest...ent-4175593054
I tried the "dirty patch" found there and it solves this "garbage in /tmp" problem too.

chris

Thanks for reporting this to that grep link you cite.

Shall we mark this issue "closed/solved"?

I noticed a few days ago that my /var/log/packages entries were bizarre. Now I see that was grep, too.

Richard

I'm not sure what the etiquette is in this case. It is resolved in the sense that we now know what the cause of the problem is (grep-2.26). On the other hand, it's not resolved until either:
1. Pat reverts grep to 2.25
2. Pat applies the "dirty patch" (or something else) to grep-2.26
3. Upstream grep releases a fixed version that is used in -current
4. Upstream vim releases a version that takes (faulty?) grep-2.26 into account

chris