[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: w32 ports of Libtool
From: |
Peter Rosin |
Subject: |
Re: w32 ports of Libtool |
Date: |
Mon, 10 Mar 2008 10:04:45 +0100 |
User-agent: |
Mutt/1.5.12-2006-07-14 |
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