Re: amaya for fedora 8?

Previous Topic Next Topic
classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view

Re: amaya for fedora 8?

Irene Vatton-2
On Tuesday 08 January 2008 16:39, Matej Cepl wrote:

> On 2008-01-08, 01:42 GMT, Martin Duerst wrote:
> > I think your comment is very important. But to make it more
> > valuable,
> > could you be more specific, e.g. giving examples of what's broken
> > with the build system, or which system libraries should or shouldn't
> > be used but are not,...
> I am just in the process of trying to rebuild Amaya on Fedora 8,
> and I cannot say that I am successful -- SPEC file (packaging
> metadata for .rpm packages) is
> (non-functional
> source package is
> Log of whole build process is
I send you the last amaya_wx.spec file I used to generate amaya-9.99 from the
source file amaya-fullsrc-9.99.tgz

> What I try to do is to emulate Debian package (and apply its
> patches), which try to use system libraries of libpng, libjpeg,
> raptor, redland, libwww and some small fixes (something
> security-related and build problems on 64bit machines). Whole
> debian diff against upstream package (where some non-free files
> were removed) is
>gz Apparently, the only imporantant patches are those in
> debian/patches directory.
> There are two problems which I see:
> 1) around line 2188 of the rpmbuild-log.txt are problems with
>    compilation of TemplateT.TRA. I have no clue what they are
>    about, but I will deal with them only when I will fix the
>    second problem.
Amaya needs to compile schemas which are descriptions of dtds.
The first error occurs there:
        cd ../../amaya; THOTDIR=`pwd`/.. ;export THOTDIR; \
Incorrect file: HTML.STR.STR
Cannot read structure schema/bin/sh: line 5: 20696 Segmentation fault      

Hum, I guess there is a problem with the shell or a problem with the Makefile
file. Are you sure there is no Control M in the file? That could
break down the building.

> 2) When bin/amaya_bin is being linked (line 2919 and its
>    surroundings) linking crashes (version of system libwww is
>    5.4.1):
>    query.o: In function `AHTProfile_newAmaya':
>    /home/matej/redhat/BUILD/Amaya/WX/amaya/../../amaya/query.c:2430:
>    undefi ned reference to `HTTransportInit()'
>    /home/matej/redhat/BUILD/Amaya/WX/amaya/../../amaya/query.c:2469:
>    undefined reference to `HTTransferEncoderInit(_HTList*)'
>    /home/matej/redhat/BUILD/Amaya/WX/amaya/../../amaya/query.c:2487:
>    undefined reference to `HTMIMEInit()'
>    collect2: ld returned 1 exit status
>    Apparently problem may be related to the fact that query.c
>    (which is C++ source file, not plain C one as would extension
>    suggest) somehow mangles need for C-library v. C++-library.
> Any ideas, what's going on, please?
query.c is c code that could be compiled with a C++ compiler.
I guess the linker didn't find out the the set of libwww libraries.

> Now, to be exact about answering your questions:
> 1) "Broken" is probably too strong word, but I don't like the
>    idea of separate tree in %{prefix}/Amaya -- libraries should
>    go to /usr/lib{,64}, binaries to /usr/bin, non-arch specific
>    files to /usr/share, system-wide configuration to /etc, etc.
>    but it shouldn't be all stuffed in one separate tree.

I tried to use /usr/lib instead of /usr/share that without success, rpmbuild
is too obscure for me. If you have the solution please let me know.
And as I know /usr/bin/firefox is a script and not a binary.

> 2) What is IMHO broken (aside from small issues like C++ files
>    having .c extension etc.) is that basically the patches
>    available in Debian (allowing to use --enable-system-{name of
>    the library} and similar stuff) is not part of the upstream
>    tarball. If the particular version of ABI is required, just
>    say so, but including multi-megabyte library (and not only
>    once) inside of the tarball (wx) is just broken, and (I guess)
>    one of the reasons why many distros (aside from the ones
>    managed by maniacs like Debian Developers -- that's meant as
>    a praise) don't include amaya anymore (in Fedora world it was
>    dropped more than year and half ago and I cannot find it on
>    SuSE website either -- which I am not much experienced with,
>    so I may be wrong).
>    For example, reading
> it seems
>    Gentoo folks have amaya in their databases but given comments
>    by maintainers like
> I don't see
>    much happines about it, and it seems to be orphaned on Gentoo
>    as well. (note: I am not Gentoo user, but when three out of
>    four distros I have searched dropped Amaya, there seems to be
>    some problem).
If you need only amaya source please use amaya-src-R.V.tgz
But pay attention: You may use the system libwww library provided you compile
without the webdav option if the library is not compiled with that option.
There is a problem with the the system Mesa library: the compiling works, but
the application will crash immediately. I ignore why, but there is no problem
with our compiled mesa version.

> 3) I have tried
>    (when it was available, it isn't anymore -- BTW, why are not
>    src.rpm packages available?) is a temporary space. Today you can
check the last snapshot:

>    and it did work exceedingly
>    poorly with AIGLX display, but even without that I had black
>    rectangles randomly happening all over the edited document, so
>    much so, that it was almost unusable. So, the reason why
>    I spent many hours trying to package amaya was that I would
>    love to have any amaya at all ;-).

That explains why we use our static library versions.

> Thanks,
> Matěj

Irène Vatton @ INRIA Rhône-Alpes

amaya_wx.spec (3K) Download Attachment