diff mbox

Configuring gcc without symlink support

Message ID 4F29CDA0.5040805@ixiacom.com
State New
Headers show

Commit Message

Earl Chew Feb. 1, 2012, 11:41 p.m. UTC 
Some environments don't support symbolic links :-(


If ln -s is not supported, configure can figure it out, and as a last resort uses:

LN_S = cp -p

I've found two problems with this.

The first problem is that LN_S is not propagated past the top-level Makefile. This
can manifest as strange GCC_NO_EXECUTABLES messages:

	Link tests are not allowed after GCC_NO_EXECUTABLES

The patch (against an older gcc 4.2.4) addresses this first problem.


The second is that:

	cp -p $1 $2  mimics  ln -s $1 $2

only if $1 is an absolute path, or $2 does not contain any path separators.
This is not always true. For example:

gcc/gcc/config/t-slibgcc-elf-ver:       $(LN_S) $(SHLIB_SONAME) $(SHLIB_DIR)/$(SHLIB_SOLINK)

There doesn't seem to be any straightforward way around this
except diligence:

	cd $(SHLIB_DIR) && $(LN_S) $(SHLIB_SONAME) $(SHLIB_SOLINK)


Earl

Comments

Andris Pavenis Feb. 2, 2012, 6:11 a.m. UTC | #1 
On 02/02/2012 12:41 AM, Earl Chew wrote:
> Some environments don't support symbolic links :-(
>
>
> If ln -s is not supported, configure can figure it out, and as a last resort uses:
>
> LN_S = cp -p
>
> I've found two problems with this.
>
> The first problem is that LN_S is not propagated past the top-level Makefile. This
> can manifest as strange GCC_NO_EXECUTABLES messages:
>
> 	Link tests are not allowed after GCC_NO_EXECUTABLES
>
> The patch (against an older gcc 4.2.4) addresses this first problem.
>
>
> The second is that:
>
> 	cp -p $1 $2  mimics  ln -s $1 $2
>
> only if $1 is an absolute path, or $2 does not contain any path separators.
> This is not always true. For example:
>
> gcc/gcc/config/t-slibgcc-elf-ver:       $(LN_S) $(SHLIB_SONAME) $(SHLIB_DIR)/$(SHLIB_SOLINK)
>
> There doesn't seem to be any straightforward way around this
> except diligence:
>
> 	cd $(SHLIB_DIR)&&  $(LN_S) $(SHLIB_SONAME) $(SHLIB_SOLINK)

Additionally building in directory libada requires symlinking 
directories, so 'cp -p' in not enough. I have tried to use there
'cp -pR' instead.

Andris

PS. I have not tested with 4.7 yet, but with 4.6 it was so
diff mbox

Patch

--- gcc/gcc/Makefile.in.orig    2012-02-01 11:27:52.783587886 -0800
+++ gcc/gcc/Makefile.in 2012-02-01 11:56:37.973586113 -0800
@@ -1465,6 +1465,7 @@ 
        MULTILIB_OSDIRNAMES='$(MULTILIB_OSDIRNAMES)' \
        ASM_HIDDEN_OP='$(ASM_HIDDEN_OP)' \
        GCC_FOR_TARGET='$(GCC_FOR_TARGET)' \
+       LN_S='$(LN_S)' \
        mkinstalldirs='$(mkinstalldirs)' \
          $(SHELL) mklibgcc > tmp-libgcc.mk
        mv tmp-libgcc.mk libgcc.mk
--- gcc/Makefile.in.orig        2012-02-01 15:08:00.353579677 -0800
+++ gcc/Makefile.in     2012-02-01 15:09:38.196088006 -0800
@@ -486,7 +486,8 @@ 
        "`echo 'LANGUAGES=$(LANGUAGES)' | sed -e s'/[^=][^=]*=$$/XFOO=/'`" \
        "LEAN=$(LEAN)" \
        "CONFIG_SHELL=$(SHELL)" \
-       "MAKEINFO=$(MAKEINFO) $(MAKEINFOFLAGS)"
+       "MAKEINFO=$(MAKEINFO) $(MAKEINFOFLAGS)" \
+       "LN_S=$(LN_S)"

 # We leave this in just in case, but it is not needed anymore.
 RECURSE_FLAGS_TO_PASS = $(BASE_FLAGS_TO_PASS)