On Sat, 9 Sep 2000, Marc Lehmann <pcg@xxxxxxxx> wrote:
> On Thu, Sep 07, 2000 at 06:13:07PM +0200, Raphael Quinet <quinet@xxxxxxxxxx> wrote:
> > the user installing the package is not the same as the one building
> > it. Some of these problems have been mentioned by Michael J. Hammel
> > two weeks ago ("install issue over NFS").
>
> AFAICR this was stricly perl-related. Since Sven hacked the
> perl-po-process into using the "standard" mechanism now it *should*
> work. Could anybody re-run the test to verify that this indeed works now?
I cannot get the latest CVS version (firewall problems) but I will
test again as soon as 1.1.26 is out. Anyway, the problems with
libgimpi.a are not specific to Perl and the CVS Changelog from Bonsai
does not mention any recent changes to the corresponding files, so I
assume that this part is still broken.
> > - Due to some strange hacks in libgimp/Makefile, the libgimp library
> > requires that you use "make" twice in order to have its dependencies
> > satisfied (the "evil hack" mentioned in that file does not seem to
> > work for me, although I am using GNU make).
>
> Does this only happen on parallel builds or on normals builds as
> well? I only gte problems when doing parallel builds (there is a
> still-open-bug-report about the latter problem).
I suppose that you are refering to this bug that you reported in May:
http://bugs.gnome.org/db/11/11900.html
My problem happens on normal builds: "make" with no arguments. This
is GNU make 3.78.1 running on Solaris 2.6. I have seen the same
problem happening under several versions of Linux (also running GNU
make) and other version of Solaris, so I think that the bug affects
almost everybody. Actually, I would like to know if there is anybody
who does *not* have this problem.
Here is how to test it:
- Get a clean source tree (extract the released .tar.gz file in an
empty directory or do a "make distclean" if you are using CVS).
- Run "./configure" with your favourite options. But do not use the
option "--disable-static" because the bug is probably related to
the static libraries.
- Type "make" once.
- Type "make" a second time. If *anything* is rebuilt (specifically,
libgimp/libgimpi.a and app/gimp), then you are affected by the bug.
> > - The Perl plug-in incorrectly uses the installed header files instead
> > of using the ones coming with the package. This means that although
>
> This comes up again and again, however, this bug has been fixed many many
> many months ago.
I am sure that the bug was still there in 1.1.24 (released at the end
of June), because all Perl scripts crashed with a dynamic linking
error (missing symbol) due to the changes in libgimp. I don't know if
it is still in 1.1.25 because the Gimp header files didn't change much
since the previous version so I didn't see any errors when I installed
the new version over the old one. Do you know if the bug was fixed
between 1.1.24 and 1.1.25?
> > the Makefiles would be the best solution but this is probably not so
> > easy, especially if I do not understand the reason why these hacks
> > were inserted in the build system. Could anybody enlighten me?
>
> AFAIK, at least the libgimp hacks come from the fact that libtool has had
> (and still has) various bugs and design problems, and also has problems on
> various platforms.
As I said in my previous message, I am willing to help fixing these
bugs, but I currently do not understand what problems the libgimpi.a
hacks are trying to solve. Is there any reason for that or is it just
because it worked once and nobody dared touching it later?
> The (former) perl-po problems come from the fact that libintl doesn't
> support perl, nor can it be configured without serious hacking to support
> perl. What was recently done was to screw standalone po-support for perl
> and make it a "only when built inside the gimp tree"-feature, so that, at
> least for gimp-1.2, there are chances of working properly, at the cost of
> not being able to upgrade until I reinvented the old mechanism again.
Well, it's a pity to break one of the two options, but I think that it
is better to get the compilation inside the Gimp tree working properly
even if it means that the upgrade would be a bit more difficult.
-Raphael
