Re: w32 ports of Libtool

[Peter Rosin]

On Mon, Mar 10, 2008 at 08:50:16AM +0100, Duft Markus wrote:
> Peter Rosin wrote:
> > On Sun, Mar 09, 2008 at 02:53:20PM +0100, Ralf Wildenhues wrote:
> >> Hello Peter, Markus,
> >> 
> >> in order to give some perspective for both of your w32 ports of
> >> Libtool: when we make the switch to git as primary repo, we intend
> >> to import your patch series in topic branches to allow for easier
> >> work and integration of them into the master tree (and to hopefully
> >> synchronize any issues of them with each other).
> 
> Cool, something moving :)
> 
> > Ok, in preparation for this, I re-scanned the wgcc patch from last
> > month and found no conflicts with my patch series. But that is hardly
> > surprising since my patches only trigger stuff from inside mingw
> > constructs (or is transparent) and the wgcc stuff is inside
> > winnt*/__PARITY__ constructs. 
> 
> Yes, i think my patches should be pretty much encapsulated. The only
> thing i can think of is the .exe handling stuff for cygwin/mingw, which
> i killed for parity, but thats only a few lines.

Those changes are only active if $host matches winnt* so I think there
will be no conflict (but I haven't tested).

> > If I would have added my testsuite tweaks there would certainly be
> > clashes, but from a cursory look the changes to the testsuite from
> > Markus is probably helping my patches more that not so I'll just work
> > from there.
> 
> The testsuite should pretty much work on win32 with my patch. But you
> may require some extra dllimport/dllexport stuff, which parity handles
> (partially) transparently. But parity will definitely be able to use the
> testsuite if it is usable on win32 without parity...
> 
> > 
> > And the wgcc patch could perhaps(?) use the compile_tag variable from
> > my patch series to add -xc++ for C++ compiles.
> 
> Parity detects the source type by extension automatically, but maybe
> there are cases where this would help, yes.

I was referring to the following hunk, but a closer examination reveals
that this has nothing to do with what my compile_tag variable does.
Sorry for the confusion...

@@ -1070,8 +1070,19 @@
          esac
        done
 
+  #
+  # if parity is used as compiler, we need to use -xc++ to force
+  # the C file into C++ to be able to use non-const initializers
+  # for variables (other variables from shared libraries for example)
+  #
+  case "$CC" in
+  *parity*)
+    PARITY_CFLAGS="-xc++"
+    ;;
+  esac
+
        # Now compile the dynamic symbol file.
-       func_show_eval '(cd $output_objdir && $LTCC$symtab_cflags 
-c$no_builtin_flag$pic_flag_for_symtable "$my_dlsyms")' 'exit $?'
+       func_show_eval '(cd $output_objdir && $LTCC$symtab_cflags 
$PARITY_CFLAGS -c$no_builtin_flag$pic_flag_for_symtable "$my_dlsyms")' 'exit $?'
 
        # Clean up the generated files.
        func_show_eval '$RM "$output_objdir/$my_dlsyms" "$nlist" "${nlist}S" 
"${nlist}T"'

(minor notes for the wgcc patch:
 1. I would drop the PARITY_CFLAGS variable and instead use
            symtab_cflags="$symtab_cflags -xc++"
    in the parity case for the above hunk.
 2. You seem to have a non-standard tab width (2?), and are thus messing
    up the indentation. Please use 8 column tabs.
)

> Another thing: maybe it would be cool in some cases to use lib.exe for
> parity too if it is found, and ar only as fallback. The reason is, that
> the system ar from interix is sometimes failing to build libraries with
> C++ objects inside (microsoft's name mangling maybe?). Newer ars seem to
> work fine (but sometimes spit warnings), but i cannot put binutils as a
> prerequisite for parity (also since some part of binutils must be
> deativated, since they don't work).

You could test with the first patch in my MSVC series [1] and reconfigure
with AR=lib. I'm not sure how that will work in the absence(?) of path
translations (which are handled automatically by msys) but it's worth a
shot.

Cheers,
Peter

[1] http://savannah.gnu.org/file/lib-as-archiver.patch?file_id=15170