LinuxQuestions.org
Share your knowledge at the LQ Wiki.
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Distributions > Slackware
User Name
Password
Slackware This Forum is for the discussion of Slackware Linux.

Notices


Reply
  Search this Thread
Old 11-11-2016, 09:11 PM   #1
rdsherman
Member
 
Registered: Aug 2009
Location: Santa Monica CA
Distribution: Slackware64
Posts: 54

Rep: Reputation: 9
linker, glibc, include - version incompatibility?


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, ...)
 
Old 11-11-2016, 10:56 PM   #2
chris.willing
Member
 
Registered: Jun 2014
Location: Brisbane, Australia
Distribution: Slackware,LFS
Posts: 409

Rep: Reputation: Disabled
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
 
Old 11-12-2016, 01:00 AM   #3
rdsherman
Member
 
Registered: Aug 2009
Location: Santa Monica CA
Distribution: Slackware64
Posts: 54

Original Poster
Rep: Reputation: 9
Quote:
Originally Posted by chris.willing View Post
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.
 
Old 11-12-2016, 01:21 AM   #4
chris.willing
Member
 
Registered: Jun 2014
Location: Brisbane, Australia
Distribution: Slackware,LFS
Posts: 409

Rep: Reputation: Disabled
Quote:
Originally Posted by rdsherman View Post
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
 
Old 11-12-2016, 02:26 AM   #5
rdsherman
Member
 
Registered: Aug 2009
Location: Santa Monica CA
Distribution: Slackware64
Posts: 54

Original Poster
Rep: Reputation: 9
Quote:
Originally Posted by chris.willing View Post
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.
 
Old 11-13-2016, 06:53 AM   #6
chris.willing
Member
 
Registered: Jun 2014
Location: Brisbane, Australia
Distribution: Slackware,LFS
Posts: 409

Rep: Reputation: Disabled
Quote:
Originally Posted by rdsherman View Post
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?
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:
Code:
export TMPDIR=`mktemp -d -t XXXXXX' || exit 1
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:
Code:
rm -rf $TMPDIR
In practice, you'd probably want to check that the new $TMPDIR is set to something reasonable before doing rm -rf on it.

chris
 
Old 11-13-2016, 11:40 AM   #7
rdsherman
Member
 
Registered: Aug 2009
Location: Santa Monica CA
Distribution: Slackware64
Posts: 54

Original Poster
Rep: Reputation: 9
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
 
Old 11-13-2016, 02:19 PM   #8
rdsherman
Member
 
Registered: Aug 2009
Location: Santa Monica CA
Distribution: Slackware64
Posts: 54

Original Poster
Rep: Reputation: 9
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
 
Old 11-13-2016, 05:23 PM   #9
chris.willing
Member
 
Registered: Jun 2014
Location: Brisbane, Australia
Distribution: Slackware,LFS
Posts: 409

Rep: Reputation: Disabled
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

Last edited by chris.willing; 11-13-2016 at 05:26 PM. Reason: fix url
 
Old 11-13-2016, 06:28 PM   #10
rdsherman
Member
 
Registered: Aug 2009
Location: Santa Monica CA
Distribution: Slackware64
Posts: 54

Original Poster
Rep: Reputation: 9
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
 
Old 11-13-2016, 07:03 PM   #11
chris.willing
Member
 
Registered: Jun 2014
Location: Brisbane, Australia
Distribution: Slackware,LFS
Posts: 409

Rep: Reputation: Disabled
Quote:
Originally Posted by rdsherman View Post
Shall we mark this issue "closed/solved"?
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
 
  


Reply


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off



Similar Threads
Thread Thread Starter Forum Replies Last Post
[SOLVED] LFS 7.8-systemd 5.7 glibc error: Need linker with .init_array/.fini_array support Michael Farthing Linux From Scratch 20 12-18-2016 12:41 PM
#include and linker flags icecubeflower Programming 4 11-24-2009 10:28 PM
Kernel Panic: version incompatibility Mohsen Programming 1 01-24-2006 08:12 AM
Argh! BadWM after upgrading ALSA to 1.0.7 (Glibc 2.3.3 incompatibility?) SocialEngineer Linux - Software 0 01-06-2005 10:19 PM
Sample Driver Module incompatibility with Kernel version (or gcc version) jvs Linux - General 1 06-07-2002 02:40 AM

LinuxQuestions.org > Forums > Linux Forums > Linux - Distributions > Slackware

All times are GMT -5. The time now is 09:20 AM.

Main Menu
Advertisement
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration