Opened 21 years ago
Closed 13 years ago
#775 closed defect (fixed)
libtool locks will never work in AFS
Reported by: | Owned by: | ||
---|---|---|---|
Priority: | normal | Milestone: | 2.0.0 |
Component: | build | Version: | 1.3.0cvs |
Severity: | minor | Keywords: | |
Cc: | lasgouttes@… |
Description (last modified by )
I am attempting to compile lyx 1.2.1 in AFS, and the make process enters an
infinite loop when trying to compile src/mathed/textpainter.C with the error
message "Waiting for textpainter.o.lock to be removed". I deleted the error
redirection of the ln line (approx. line 773, "until $run ln \"$0\"
\"$lockfile\" 2>/dev/null; do") in the libtool at the root of the source tree
and got the error message "ln: creating hard link `textpainter.o.lock' to
`../../libtool': Invalid cross-device link". Because of how AFS works, it is
not possible to create hard links between files in separate directories, this is
the error that occurs when you try. I changed the "ln" to "ln -s" and it seems
to work fine. Interestingly, when looking through libtool, I found the lines:
# Whether we need hard or soft links.
LN_S="ln -s"
at about line 75. This was on a host running RedHat 7.3 and OpenAFS 1.2.4.
Thanks
Change History (11)
comment:1 by , 21 years ago
comment:2 by , 21 years ago
I've only ever seen this with lyx, which is why I started here. If I should be
bugging the GNU project, I will.
comment:3 by , 21 years ago
Owner: | changed from | to
---|
There are several issues here, as far as I understand:
- I indeed see the same problem with afs, and I guess the solution that you propose will work. Note that compiling with --disable-libtool-lock also works.
- when I began to investigate this, I noticed that the situation was worse than that: it seems that the libtool tries to do this locking is that the test looking whether the compiler supports -c and -o at the same time fails with gcc. I just took a look, and it seems that the code does
save_CFLAGS="$CFLAGS"
CFLAGS="$CFLAGS -o out/conftest2.$ac_objext"
and then proceeds to compile with a _C++_ compiler. The chances of success
are slim to say the least :)
OK, I have taken a look at the libtool cvs repository now, and it seems that
this bug has been fixed 3 weeks ago. Good.
So we still have the afs problem to solve. It seems that latest cvs still has
this problem, so reporting the bug is a good idea. Could you do it for us?
I would be grateful.
John, this has to do with lyx in the sense that the bug is in the libtool
thingies we distribute. I propose to keep the bug open until this is solved.
comment:6 by , 21 years ago
Yes: see there
http://article.gmane.org/gmane.comp.gnu.libtool.bugs/1188
I don't this got fixed yet.
comment:7 by , 19 years ago
Owner: | changed from | to
---|
comment:9 by , 15 years ago
Description: | modified (diff) |
---|---|
Keywords: | fixedintrunk added |
Milestone: | → 2.0.0 |
Since we do not use libtool anymore this is fixed in trunk.
comment:10 by , 15 years ago
Priority: | high → normal |
---|
comment:11 by , 13 years ago
Keywords: | fixedintrunk removed |
---|---|
Resolution: | → fixed |
Status: | new → closed |
2.0.0 is ready
Well, this sounds like it has nothing to do with lyx.