--enable-auto-image-base linker option for Cygwin

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

--enable-auto-image-base linker option for Cygwin

James R. Phillips-3
Cygwin maintainers periodically grouse about needing the rebase utility, and
recently have proposed use of --enable-auto-image-base as a linker option, in
the hopes of reducing or eliminating dll address base collisions, thus
eliminating the need for rebase.

AFAICT, this would require adding "-wl,--enable-auto-image-base" to the
SH_LDFLAGS defined for cygwin/mingw in configure.in.

Is this feasible, and is it worth doing?

I have not seen the "failing fork()" issue that necessitates use of rebase with
the cygwin build 2.1.71-1.  I have seen it in the past, though, for earlier
builds that were not official cygwin packages.

Reply | Threaded
Open this post in threaded view
|

--enable-auto-image-base linker option for Cygwin

John W. Eaton-6
On  8-Jul-2005, James R. Phillips wrote:

| Cygwin maintainers periodically grouse about needing the rebase utility, and
| recently have proposed use of --enable-auto-image-base as a linker option, in
| the hopes of reducing or eliminating dll address base collisions, thus
| eliminating the need for rebase.
|
| AFAICT, this would require adding "-wl,--enable-auto-image-base" to the
| SH_LDFLAGS defined for cygwin/mingw in configure.in.
|
| Is this feasible, and is it worth doing?
|
| I have not seen the "failing fork()" issue that necessitates use of rebase with
| the cygwin build 2.1.71-1.  I have seen it in the past, though, for earlier
| builds that were not official cygwin packages.

I can apply the following change if it solves a real problem.  Is
there any disadvantage to making this change?

jwe


ChangeLog:

2005-07-14  John W. Eaton  <[hidden email]>

        * configure.in (SH_LDFLAGS): Add -Wl,--enable-auto-image-base for
        Cygwin and MinGW.


Index: configure.in
===================================================================
RCS file: /cvs/octave/configure.in,v
retrieving revision 1.479
diff -u -r1.479 configure.in
--- configure.in 15 Jun 2005 03:45:47 -0000 1.479
+++ configure.in 14 Jul 2005 17:29:24 -0000
@@ -850,7 +850,7 @@
     SHLEXT=dll
     SHLLIB=dll.a
     SHLBIN=dll
-    SH_LDFLAGS="-shared -Wl,--export-all-symbols -Wl,--enable-auto-import"
+    SH_LDFLAGS="-shared -Wl,--export-all-symbols -Wl,--enable-auto-import -Wl,--enable-auto-image-base"
     SHLLINKEXT=.dll
     SONAME_FLAGS='-Wl,--out-implib=$@.a'
     library_path_var=PATH

Reply | Threaded
Open this post in threaded view
|

Re: --enable-auto-image-base linker option for Cygwin

James R. Phillips-2
In reply to this post by James R. Phillips-3
--- "John W. Eaton"  wrote:
>
> I can apply the following change if it solves a real problem.  Is
> there any disadvantage to making this change?
>

It is hard for me to characterize the problem as real, because I haven't seen
it on this build.  However, the design of the cygwin fork() is such that it
isn't able to rule out the possibility of dll address collisions, leading to
failure of the fork.  The change is such that it should reduce the probability
of such collisions.  At this point I would classify it as a beneficial change
to prevent a potential issue.

There is currently no downside to the change that I am aware of.  cgf has made
some changes to cygwin ld in the past week to eliminate what were some possible
downsides.

Would it be possible to also add this linker option to the set of default
options that are used for cygwin in the mkoctfile script?  It does not appear
to me that this configuration change will propagate into the makoctfile
defaults.

In any case, I think the way to handle this is to add the change to whatever
set of changes you are going to make for the next point release.  Please don't
think this is significant enough on its own to merit a new octave point
release.

Thanks,

Jim Phillips

Reply | Threaded
Open this post in threaded view
|

Re: --enable-auto-image-base linker option for Cygwin

John W. Eaton-6
On 14-Jul-2005, James R. Phillips wrote:

| --- "John W. Eaton"  wrote:
| >
| > I can apply the following change if it solves a real problem.  Is
| > there any disadvantage to making this change?
| >
|
| It is hard for me to characterize the problem as real, because I haven't seen
| it on this build.  However, the design of the cygwin fork() is such that it
| isn't able to rule out the possibility of dll address collisions, leading to
| failure of the fork.  The change is such that it should reduce the probability
| of such collisions.  At this point I would classify it as a beneficial change
| to prevent a potential issue.
|
| There is currently no downside to the change that I am aware of.  cgf has made
| some changes to cygwin ld in the past week to eliminate what were some possible
| downsides.
|
| Would it be possible to also add this linker option to the set of default
| options that are used for cygwin in the mkoctfile script?  It does not appear
| to me that this configuration change will propagate into the makoctfile
| defaults.

I think the change I proposed should also affect mkoctfile because
mkoctfile has

: ${DL_LDFLAGS=%OCTAVE_CONF_MKOCTFILE_DL_LDFLAGS%}

and the rules in Makeconf.in and Makefile.in will substitute the value
of

  $(MKOCTFILE_DL_LDFLAGS)

for

  %OCTAVE_CONF_MKOCTFILE_DL_LDFLAGS%

and configure.in has

  DL_LDFLAGS='$(SH_LDFLAGS)'
  MKOCTFILE_DL_LDFLAGS='$(DL_LDFLAGS)'

so the default value of DL_LDFLAGS in mkoctfile should be the same as
SH_LDFLAGS unless we specifically set DL_LDFLAGS or
MKOCTFILE_DL_LDFLAGS to something different in configure.in (some
platforms do, but not Cygwin).

| In any case, I think the way to handle this is to add the change to whatever
| set of changes you are going to make for the next point release.  Please don't
| think this is significant enough on its own to merit a new octave point
| release.

OK.

I've checked in the changes.

Thanks,

jwe