Opened 21 years ago

Closed 13 years ago

#775 closed defect (fixed)

libtool locks will never work in AFS

Reported by: nejedlo@… Owned by: nobody@…
Priority: normal Milestone: 2.0.0
Component: build Version: 1.3.0cvs
Severity: minor Keywords:
Cc: lasgouttes@…

Description (last modified by Jean-Marc Lasgouttes)

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 levon, 21 years ago

Well, this sounds like it has nothing to do with lyx.

comment:2 by nejedlo@…, 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 Jean-Marc Lasgouttes, 21 years ago

Owner: changed from Lars Gullik Bjønnes to Jean-Marc Lasgouttes

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:4 by levon, 21 years ago

Version: 1.2.11.3.0cvs

-> NEW then.

comment:5 by levon, 21 years ago

Did this get reported to the libtool folks ?

comment:6 by Jean-Marc Lasgouttes, 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 Jean-Marc Lasgouttes, 19 years ago

Owner: changed from Jean-Marc Lasgouttes to nobody@…

comment:8 by Uwe Stöhr, 18 years ago

Cc: lasgouttes@… added

John, JMarc, what's the status of this bug?

comment:9 by Jean-Marc Lasgouttes, 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 ps, 15 years ago

Priority: highnormal

comment:11 by ps, 13 years ago

Keywords: fixedintrunk removed
Resolution: fixed
Status: newclosed

2.0.0 is ready

Note: See TracTickets for help on using tickets.