Re: Issuew building with prepackaged stuff (was Re: Problem building main/sal/cppunittester)
Hello Pedro,
On Tue, Nov 08, 2011 at 01:21:09PM -0800, Pedro Giffuni wrote:
> > looking at https://issues.apache.org/ooo/show_bug.cgi?id=118574
> > IMHO the solution is not acceptable: you cannot include a
> > header that is not used at all in that file.
> > None of the files you've patched so far
> > uses wchar.h directly, so the issue is with the BSD port
> > and should be fixed there.
> >
>
> I agree that this issue seems to be particular of the
> FreeBSD port.
> I discussed this with Maho@ a while ago and we decided we
> will keep the patch in our local port.
>
> > Notice that your issue is because your using your system's
> > libxml2:
> >
> > libxml/encoding.h includes /usr/local/include/iconv.h if
> > LIBXML_ICONV_ENABLED is defined. So you see that error on
> > every OOo file
> > that includes a libxml header that in turn includes
> > libxml/encoding.h
> >
> > On Fedora, building with system libxml works fine, I don't
> > get that
> > error. In fact, /usr/local/include/iconv.h has no line 114
> > and it does
> > not use mbstate_t at all.
> > I wonder how your system's iconv.h looks like, does it use
> > mbstate_t at
> > all? Is your system's libxml configured with
> > LIBXML_ICONV_ENABLED?
> >
>
> I am using libiconv-1.13.1 and libxml2-2.7.8.
> libxml is configured to use libiconv.
>
> It sure uses mbstate_t:
>
> /usr/local/include/iconv.h
>
> ...
> /* A type that holds all memory needed by a conversion descriptor.
>A pointer to such an object can be used as an iconv_t. */
> typedef struct {
> void* dummy1[28];
> #if 1
> mbstate_t dummy2;
> #endif
> } iconv_allocation_t;
> ...
>
> This doesn't seem to be BSD specific though, shouldn't
> everyone be using libiconv with libxml2 ?
on Fedora, iconv comes built-in with glibc:
~]$ sudo yum whatprovides /usr/include/iconv.h
glibc-headers-2.14-5.x86_64 : Header files for development usin standard C
libraries.
Repo: installed
Matched from:
Other : Provides-match: /usr/include/iconv.h
* there is no standalone libiconv
* iconv.h is only 56 lines long, and does not use mbstate_t at all
http://bit.ly/uLImuD
So this is a BSD issue.
Regards
--
Ariel Constenla-Haile
La Plata, Argentina
pgpVr0ipyAEzA.pgp
Description: PGP signature
Re: Issuew building with prepackaged stuff (was Re: Problem building main/sal/cppunittester)
Hi Ariel;
Thanks for looking.
--- On Tue, 11/8/11, Ariel Constenla-Haile wrote:
> Hello Pedro,
>
...
>
> looking at https://issues.apache.org/ooo/show_bug.cgi?id=118574
> IMHO the solution is not acceptable: you cannot include a
> header that is not used at all in that file.
> None of the files you've patched so far
> uses wchar.h directly, so the issue is with the BSD port
> and should be fixed there.
>
I agree that this issue seems to be particular of the
FreeBSD port.
I discussed this with Maho@ a while ago and we decided we
will keep the patch in our local port.
> Notice that your issue is because your using your system's
> libxml2:
>
> libxml/encoding.h includes /usr/local/include/iconv.h if
> LIBXML_ICONV_ENABLED is defined. So you see that error on
> every OOo file
> that includes a libxml header that in turn includes
> libxml/encoding.h
>
> On Fedora, building with system libxml works fine, I don't
> get that
> error. In fact, /usr/local/include/iconv.h has no line 114
> and it does
> not use mbstate_t at all.
> I wonder how your system's iconv.h looks like, does it use
> mbstate_t at
> all? Is your system's libxml configured with
> LIBXML_ICONV_ENABLED?
>
I am using libiconv-1.13.1 and libxml2-2.7.8.
libxml is configured to use libiconv.
It sure uses mbstate_t:
/usr/local/include/iconv.h
...
/* A type that holds all memory needed by a conversion descriptor.
A pointer to such an object can be used as an iconv_t. */
typedef struct {
void* dummy1[28];
#if 1
mbstate_t dummy2;
#endif
} iconv_allocation_t;
...
This doesn't seem to be BSD specific though, shouldn't
everyone be using libiconv with libxml2 ?
cheers,
Pedro.
Re: Issuew building with prepackaged stuff (was Re: Problem building main/sal/cppunittester)
Hello Pedro, On Fri, Nov 04, 2011 at 07:56:53PM -0700, Pedro Giffuni wrote: > > /usr/ports/editors/openoffice.org-3-devel/work/ooo/main/unoxml/source/dom/node.cxx:28: > > > /usr/local/include/iconv.h:114: error: 'mbstate_t' > > does not name a type > > > ... > > > _ > > > > > > but I already know how to fix those :). > > > > how are you fixing them? Looks like a system header issue, > > not OOo problem... > > > > The problem is only caused when the libxml/tree.h is included, > so this seems to work: > > +#include // for std::mbstate_t > #include > > What is really weird is that this is specific to OpenOffice, > it doesn't happen in other ports, including LibreOffice. looking at https://issues.apache.org/ooo/show_bug.cgi?id=118574 IMHO the solution is not acceptable: you cannot include a header that is not used at all in that file. None of the files you've patched so far uses wchar.h directly, so the issue is with the BSD port and should be fixed there. Notice that your issue is because your using your system's libxml2: libxml/encoding.h includes /usr/local/include/iconv.h if LIBXML_ICONV_ENABLED is defined. So you see that error on every OOo file that includes a libxml header that in turn includes libxml/encoding.h On Fedora, building with system libxml works fine, I don't get that error. In fact, /usr/local/include/iconv.h has no line 114 and it does not use mbstate_t at all. I wonder how your system's iconv.h looks like, does it use mbstate_t at all? Is your system's libxml configured with LIBXML_ICONV_ENABLED? Regards -- Ariel Constenla-Haile La Plata, Argentina pgpyjFOoxjqt3.pgp Description: PGP signature
Re: Issuew building with prepackaged stuff (was Re: Problem building main/sal/cppunittester)
--- On Fri, 11/4/11, Ariel Constenla-Haile wrote: ... > /usr/ports/editors/openoffice.org-3-devel/work/ooo/main/unoxml/source/dom/node.cxx:28: > > /usr/local/include/iconv.h:114: error: 'mbstate_t' > does not name a type > > ... > > _ > > > > but I already know how to fix those :). > > how are you fixing them? Looks like a system header issue, > not OOo problem... > The problem is only caused when the libxml/tree.h is included, so this seems to work: +#include // for std::mbstate_t #include What is really weird is that this is specific to OpenOffice, it doesn't happen in other ports, including LibreOffice. Pedro. > Regards > -- > Ariel Constenla-Haile > La Plata, Argentina >
Re: Issuew building with prepackaged stuff (was Re: Problem building main/sal/cppunittester)
On Thu, Nov 03, 2011 at 06:41:18PM -0700, Pedro Giffuni wrote: > --- On Thu, 11/3/11, Ariel Constenla-Haile wrote: > ... > > Gbuild does not find libsaxfx.so, so it tries to build. > > > > > > http://svn.apache.org/viewvc/incubator/ooo/trunk/main/solenv/gbuild/platform/freebsd.mk?view=markup#l264 > > > > remove fi and fx from gb_Library_OOOEXT > > > > This should work. > > > > Yes, that was definitely it!! A huge Thank You!! > > I am still finding stuff like this: > > ... > from > /usr/ports/editors/openoffice.org-3-devel/work/ooo/main/unoxml/source/dom/node.cxx:28: > /usr/local/include/iconv.h:114: error: 'mbstate_t' does not name a type > ... > _ > > but I already know how to fix those :). how are you fixing them? Looks like a system header issue, not OOo problem... Regards -- Ariel Constenla-Haile La Plata, Argentina pgpYUmODamBLY.pgp Description: PGP signature
Re: Issuew building with prepackaged stuff (was Re: Problem building main/sal/cppunittester)
--- On Thu, 11/3/11, Ariel Constenla-Haile wrote: ... > Gbuild does not find libsaxfx.so, so it tries to build. > > > http://svn.apache.org/viewvc/incubator/ooo/trunk/main/solenv/gbuild/platform/freebsd.mk?view=markup#l264 > > remove fi and fx from gb_Library_OOOEXT > > This should work. > Yes, that was definitely it!! A huge Thank You!! I am still finding stuff like this: ... from /usr/ports/editors/openoffice.org-3-devel/work/ooo/main/unoxml/source/dom/node.cxx:28: /usr/local/include/iconv.h:114: error: 'mbstate_t' does not name a type ... _ but I already know how to fix those :). Cheers, Pedro. ps. If you can, try to visit BSDDay Argentina http://www.bsdday.org.ar/
Re: Issuew building with prepackaged stuff (was Re: Problem building main/sal/cppunittester)
Hello Pedro On Thu, Nov 03, 2011 at 01:02:36PM -0700, Pedro Giffuni wrote: > FWIW; > > There seem to be problems when using some libraries externally. > > I solved another issue in BZ 118574, but it seems weird that no > one else hit it before so I would like someone with better C++ > skills to review it. > > Now I am stuck here: > > cheers, > > Pedro. > > Building module unoxml > = > > Entering /usr/ports/editors/openoffice.org-3-devel/work/ooo/main/unoxml/prj > > cd .. && gmake -s -r -j1 compile without -s to get more verbose output > [ info ALL ] LinkTarget Library/libsaxfx.so not defined: Assuming headers to > be there! > [ info ALL ] LinkTarget Library/libxml2.so not defined: Assuming headers to > be there! > [ build DEP ] LNK:Library/libunoxmlfx.so > [ info ALL ] LinkTarget Library/librdf.so not defined: Assuming headers to > be there! > [ info ALL ] LinkTarget Library/libxslt.so not defined: Assuming headers to > be there! > [ build DEP ] LNK:Library/libunordffx.so > /usr/local/bin/gcp: missing destination file operand after > `/usr/ports/editors/openoffice.org-3-devel/work/ooo/main/solver/340/unxfbsdx.pro/lib/libsaxfx.so' > Try `/usr/local/bin/gcp --help' for more information. > gmake: *** > [/usr/ports/editors/openoffice.org-3-devel/work/ooo/main/solver/340/unxfbsdx.pro/lib/libsaxfx.so] > Error 1 > ... the copy command takes two arguments, source and destination. Something is wrong there because its getting only one. Run make without -s . My guess (I don't have BSD to test): an issue with the DLLPOSTFIX clean-up. unoxml only builds two libraries: unoxml and unordf. In modules ported to gbuild you know this by looking at the files named Library_XXX.mk The sax library is a dependency for unoxml; see gb_Library_add_linked_libs in unoxml/Library_unoxml.mk The problem here is that gbuild composes the library name from sax to libsaxfx.so : lib sax fx <--- DLLPOSTFIX! .so The sax library has already been built in sax module, in the old build system, with the DLLPOSTFIX cleaned, so that it's named simply libsax.so. Gbuild does not find libsaxfx.so, so it tries to build. http://svn.apache.org/viewvc/incubator/ooo/trunk/main/solenv/gbuild/platform/freebsd.mk?view=markup#l264 remove fi and fx from gb_Library_OOOEXT This should work. Regards -- Ariel Constenla-Haile La Plata, Argentina pgpzHDf5jzklg.pgp Description: PGP signature
