Using slackBuild script from -current in source.

During the make cycle, cc* (.c, .o, .s, .le, .ls) appear, then are removed in /tmp.

In 8.0.0055, I'm left with 3 empty .c, .o, .le files + a .ld file giving the allowable ld options since it did not like an option or was missing a file.

In configure.log, I see a test result for dlopen() with a fail due to undefined reference related to the linker.

Everything seems to function properly & there are NO reported errors otherwise.

Can anybody replicate?

Anyone know when this crept into vim? It's been there awhile. Never had this with the 7 series.

NOT a big deal, though!

Patch?

Thanks.

I don't know about that, but I tried the new vim and found it not behaving well. For one example, some commands seemed to not work when placed in vimrc, even though they did work when entered interactively. After struggling with it for awhile, I decided the trouble wasn't worth it. Anyway, I don't know if this has anything to do with the issue you brought up -- probably not -- but IMO vim 8 isn't ready yet.

I have been using vi/vim for circa 40 years. With each release, I custom build my own spec, actually 3 (vim-nox, vim-athena, vim-gtk2|3), based on a single .vimrc. It always works. That includes the latest 8.0.0055.

What I'm noticing is a minor nuisance in the build of each type. In the past, going over many decades, the build is "perfect" & clean. It seems to be some mismatch of lib release versions that causes ld to complain lately.

It could be just my particular system or maybe it's more general?

rdsherman,
As a fan of vi/vim, may I ask your thoughts on elvis?
What makes vim preferable for you?

I use a lot of features now readily available with vim. I have written a few vim scripts that perform convenient operations within the vim environment. Examples are compiling/linking *.c code, building LaTeX documents, performing some arithmetic functions on various lines/columns of numbers, .... All this occurs in a colorful environment via the syntax files that accompany the package.

Most of this, maybe all, is not in elvis, which is intended mainly as a rescue editor; it works fine. However, to keep matters simple & consistent, I built a vim-nox, to serve as a base, but, it still retains lots of the enhanced version features.

While some folks use emacs for many of these tasks I do, I find vim a far simpler & quicker environment to do all the same.

elvis is fine. But, it is just too lacking in add-ons for "heavy duty production".

1 members found this post helpful.

For anyone who stumbles across this thread during a search, this problem is due to a regression in grep 2.26, which is now in -current. The solution is to roll back to 2.25 or apply the patch in this post.

2 members found this post helpful.

I've always felt more comfortable in elvis than vim (though adding some options to .vimrc helps a lot) but the biggest drawback of elvis is that it doesn't handle unicode characters. As Pat is changing to unicode by default for the next release, this may become a bigger issue for elvis in future.

It may be this grep bug, which breaks vim builds as well as upgradepkg: http://www.linuxquestions.org/questi...nt-4175593054/ . See also https://debbugs.gnu.org/cgi/bugreport.cgi?bug=24941, which references that posting. If that is the problem, the easiest answer is to revert grep to version 2.25 from slackware-14.2

It is indeed the same!

I have elsewhere recommended a revert to grep-2.25 until grep upstream & the Slackware gurus converge on a path forward.

We're waiting ...

From latest ChangeLog.txt:
which has fixed the residual garbage issue for me.

chris

let's hope it remains that way.