[haiku-development] Re: 32bit-wchar_t branch has been merged into trunk - full rebuild necessary
- From: "Ingo Weinhold" <ingo_weinhold@xxxxxx>
- To: haiku-development@xxxxxxxxxxxxx
- Date: Tue, 07 Jul 2009 21:43:03 +0200
-------- Original-Nachricht --------
> Datum: Tue, 07 Jul 2009 20:50:37 +0200
> Von: Oliver Tappe <zooey@xxxxxxxxxxxxxxx>
> On 2009-07-07 at 19:44:22 [+0200], Ingo Weinhold <ingo_weinhold@xxxxxx>
> wrote:
> >
> > -------- Original-Nachricht --------
> > > Datum: Tue, 07 Jul 2009 12:36:57 +0200
> > > Von: Oliver Tappe <zooey@xxxxxxxxxxxxxxx>
> >
> > > I have just merged the work on wchar_t (and some more) into r31443 of
> the
> > > trunk, as a
> > > result you need to update to that or a later revision and then rebuild
> > > everything,
> > > i.e. the buildtools and haiku itself.
> > >
> > > Please tell if you encounter any peculiarities.
> >
> > Subversion doesn't work out of the box anymore. It is linked against
> > "libiconv.so.2", but the library is installed only as "libiconv.so".
> Adding a
> > symlink solves the problem. Tested under gcc4/gcc2 hybrid, but I guess
> it's a
> > universal problem with the new libiconv package.
>
> Yes, it doesn't contain any shared library anymore, such that the other
> one
> (from /system/lib) is found, but that one has no version spec links with
> it,
> nor does it actually work (since I have missed that several of our
> internal
> code contains WCHAR_T size definitions in their config.h).
>
> I have tried to rebuild the libiconv optional package with those shared
> libraries, but so far failed to do so - libtool insists on not being able
> to
> create shared libraries. Maybe that has something to do with the
> runtime_loader
> problems that I've mentioned earlier today ...
Normally the problem is just that the build system of the package has been
generated by older autotools versions. So re-generating the build system should
help. Many projects have a script to do that (bootstrap, autogen.sh), but
oftentimes it is in their repository, but not included in the distributed
source tarballs, or it doesn't work properly when the build system files do
already exist.
> Anyway, as I find it cumbersome that we provide a system-libiconv.so and
> an
> optional package, too, I am currently upgrading the internal libiconv to
> the
> current version and make it support being relocated in the filesystem
> (which
> AFAICS is the reason why the optional package has been created in the
> first
> place).
Good idea.
> Naturally, this will not solve the problem of the optional packages that
> depend
> on libiconv.so.2. I have no idea where the .2 is coming from, actually, as
> the
> current version of libiconv is 1.13 !?!
I wondered too, but it's only their weird versioning scheme. In fact we might
even want to use the libiconv.so.2 name and soname to avoid compatibility
problems that might occur when other versions are installed.
CU, Ingo
Other related posts:
