Ticket #799 (new bug)

Opened 13 years ago

Last modified 11 years ago

Configure should explicitly check for symbolic link capability on Linux

Reported by: Austin_Hastings Owned by:
Priority: minor Milestone:
Component: configure Version: 1.3.0
Severity: medium Keywords: ntfs symbolic links
Cc: Language:
Patch status: Platform: linux

Description

I'm running linux for Parrot work, but the underlying filesystem is NTFS, mounted r/w. This means that Configure.pl will detect my system as being linux, but it also means that symlinks don't work in the build area (ironically, they DO work in /usr/**, but not in /home/austin/parrot). When evaluating capabilities, Configure.pl should check to ensure that symlinks work. Presently, the build fails when trying to link a versioned .so to an unversioned on inside blib/lib. (I work around this by cp'ing it, and restart the make.)

Change History

in reply to: ↑ description   Changed 13 years ago by jkeenan

Replying to Austin_Hastings:

When evaluating capabilities, Configure.pl should check to ensure that symlinks work. Presently, the build fails when trying to link a versioned .so to an unversioned on inside blib/lib. (I work around this by cp'ing it, and restart the make.)

1. Can you point to specific code in the configuration system which uses symlinks?

2. Is this a Linux-specific problem? Or is it a problem that could occur on any symlink-capable OS that has the filesystem restrictions you described?

Thank you very much.

kid51

follow-up: ↓ 4   Changed 13 years ago by Austin_Hastings

In my ~/parrot/Makefile, I have this block:

$(LIBPARROT_SHARED) : $(O_FILES)
        $(MKPATH) blib/lib
        $(LD) $(LD_SHARE_FLAGS) $(LDFLAGS) -o $@ -Wl,-soname=libparrot$(SHARE_EX
T).$(SOVERSION) \
                $(O_FILES) $(C_LIBS) $(ICU_SHARED)
        ( cd blib/lib ; ln -sf libparrot$(SHARE_EXT).$(SOVERSION) libparrot$(SHARE_EXT) )

The eventual result is an attempt to link libparrot.so.1.3.0 to libparrot.so. This fails since links are unsupported. In a no-links environment, copy is probably the way to go, if it even needs to be done at all.

I also have this one:

release : MANIFEST MANIFEST.generated
        [ -d parrot-$(VERSION) ] || ln -s $(CUR_DIR) parrot-$(VERSION)
        @$(RM_F) MANIFEST.real
        mv MANIFEST MANIFEST.real
        grep -v DEVELOPING MANIFEST.real > MANIFEST
        $(PERL) -lane 'print"parrot-$(VERSION)/$$F[0]"unless!length||/#/' MANIFEST | \
    tar -zcv -T - -f parrot-$(VERSION).tar.gz
        mv MANIFEST.real MANIFEST
        rm parrot-$(VERSION)

But I have never tried make release so it doesn't impact me. (Yet.)

  Changed 13 years ago by Austin_Hastings

As to whether this is a linux-specific problem, I think it is not. Any *nix O/S that can mount NTFS -- which is nearly all of them, thanks to ntfs-3g -- is vulnerable to this failure. I suspect it is likely to occur primarily in my own scenario: a *nix OS in some kind of VM being hosted on top of Windows.

in reply to: ↑ 2   Changed 13 years ago by jkeenan

Replying to Austin_Hastings:

I created the following patch:

Index: config/gen/makefiles/root.in
===================================================================
--- config/gen/makefiles/root.in        (revision 39874)
+++ config/gen/makefiles/root.in        (working copy)
@@ -894,7 +894,7 @@
 #IF(win32 and cc==gcc):                -Wl,--out-implib=libparrot.lib \
                $(O_FILES) $(C_LIBS) $(ICU_SHARED)
 #IF(win32):    if exist $@.manifest mt.exe -nologo -manifest $@.manifest -outputresource:$@;2
-#IF(libparrot_shared_alias):   ( cd @blib_dir@ ; ln -sf @libparrot_shared@ @libparrot_shared_alias@ )
+#IF(libparrot_shared_alias):   ( cd @blib_dir@ ; $(CP) @libparrot_shared@ @libparrot_shared_alias@ )
 
 
 $(INSTALLABLECONFIG) : $(SRC_DIR)/install_config$(O) $(PARROT_CONFIG) $(PBC_TO_EXE)
@@ -2215,7 +2215,7 @@
 ###############################################################################
 
 release : MANIFEST MANIFEST.generated
-       [ -d parrot-$(VERSION) ] || ln -s $(CUR_DIR) parrot-$(VERSION)
+       [ -d parrot-$(VERSION) ] || $(CP) $(CUR_DIR) parrot-$(VERSION)
        @$(RM_F) MANIFEST.real
        mv MANIFEST MANIFEST.real
        grep -v DEVELOPING MANIFEST.real > MANIFEST

On a regular Linux system, I then configured Parrot with --prefix=/topdir/pseudoinstall so I could observe what happens during an installation. I then called make && make install && make install-dev. I confirmed that something worked by switching to topdir/pseudoinstall and calling ./bin/parrot --version, with favorable results. However, I don't know what else should be tested to demonstrate this works.

[snip]

I also have this one:

> release : MANIFEST MANIFEST.generated
>         [ -d parrot-$(VERSION) ] || ln -s $(CUR_DIR) parrot-$(VERSION)
>         @$(RM_F) MANIFEST.real
>         mv MANIFEST MANIFEST.real
>         grep -v DEVELOPING MANIFEST.real > MANIFEST
>         $(PERL) -lane 'print"parrot-$(VERSION)/$$F[0]"unless!length||/#/' MANIFEST | \
>     tar -zcv -T - -f parrot-$(VERSION).tar.gz
>         mv MANIFEST.real MANIFEST
>         rm parrot-$(VERSION)

But I have never tried make release so it doesn't impact me. (Yet.)

I, too, have never really tried make release. When I did so -- in the same sandbox where I had just configured and built -- I did not get good results:

$ make release
[ -d parrot-1.3.0-devel ] || /usr/local/bin/perl -MExtUtils::Command -e cp . parrot-1.3.0-devel
mv MANIFEST MANIFEST.real
grep -v DEVELOPING MANIFEST.real > MANIFEST
/usr/local/bin/perl -lane 'print"parrot-1.3.0-devel/$F[0]"unless!length||/#/' MANIFEST | \
    tar -zcv -T - -f parrot-1.3.0-devel.tar.gz
tar: parrot-1.3.0-devel/CREDITS: Cannot stat: Not a directory
tar: parrot-1.3.0-devel/ChangeLog: Cannot stat: Not a directory
tar: parrot-1.3.0-devel/Configure.pl: Cannot stat: Not a directory

...

Now, it's quite likely I'm not calling make release correctly. But, in any event, I wouldn't advise immediately applying my patch, if only because we're having a lot of discussion now about make install issues and I don't know where this problem/patch fit into that.

kid51

  Changed 13 years ago by jkeenan

  Changed 11 years ago by jkeenan

In the two years since last activity in this ticket, I think we've resolve the make release problems described in comments 2 and 4.

But I'm not sure that we've addressed the problem described by the OP, i.e., we need to explicitly check for symbolic link capability on mounted filesystems.

Any bright ideas?

Thank you very much.

kid51

Note: See TracTickets for help on using tickets.