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