You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@openoffice.apache.org by Απόστολος Συρόπουλος <as...@hotmail.com> on 2013/12/01 15:44:04 UTC
RE: soltools need(s) to be rebuilt
Hello again,
I have downloaded the source code and I have reconfigured etc.
What I have observed so far is that there are a number of
utilities that consist of C and C++ source files. In all these cases,
the build script uses the C compile and so obviously it fails to build
the object files. For example,
=============
Building module soltools
=============
Entering /extra/sources/OpenOffice/aoo4/main/soltools/mkdepend
mkout -- version: 1.8
Compiling: soltools/mkdepend/cppsetup.c
cc: Warning: illegal use of -features option, illegal item ignored: rvalueref
cc: Warning: illegal use of -features option, empty value ignored
Compiling: soltools/mkdepend/ifparser.c
cc: Warning: illegal use of -features option, illegal item ignored: rvalueref
cc: Warning: illegal use of -features option, empty value ignored
Compiling: soltools/mkdepend/include.c
cc: Warning: illegal use of -features option, illegal item ignored: rvalueref
cc: Warning: illegal use of -features option, empty value ignored
Compiling: soltools/mkdepend/main.c
cc: Warning: illegal use of -features option, illegal item ignored: rvalueref
cc: Warning: illegal use of -features option, empty value ignored
Compiling: soltools/mkdepend/parse.c
cc: Warning: illegal use of -features option, illegal item ignored: rvalueref
cc: Warning: illegal use of -features option, empty value ignored
"parse.c", line 43: warning: identifier redeclared: find_includes
current : function() returning int
previous: function(pointer to struct filepointer {pointer to char f_p, pointer to char f_base, pointer to char f_end, long f_len, long f_line}, pointer to struct inclist {pointer to char i_incstring, pointer to char i_file, pointer to pointer to struct inclist {..} i_list, int i_listlen, unsigned char i_defchecked, unsigned char i_notified, unsigned char i_marked, unsigned char i_searched, unsigned char i_included_sym}, pointer to struct inclist {pointer to char i_incstring, pointer to char i_file, pointer to pointer to struct inclist {..} i_list, int i_listlen, unsigned char i_defchecked, unsigned char i_notified, unsigned char i_marked, unsigned char i_searched, unsigned char i_included_sym}, int, unsigned char, pointer to struct IncludesCollection {}, pointer to struct symhash {array[64] of pointer to struct pair {..} s_pairs}) returning int : "def.h", line 169
"parse.c", line 43: warning: Prototype mismatch in arg 5 for function find_includes:
function : old style declaration unsigned char promoted to int
prototype: unsigned char
Compiling: soltools/mkdepend/pr.c
cc: Warning: illegal use of -features option, illegal item ignored: rvalueref
cc: Warning: illegal use of -features option, empty value ignored
"pr.c", line 42: warning: identifier redeclared: add_include
current : function() returning void
previous: function(pointer to struct filepointer {pointer to char f_p, pointer to char f_base, pointer to char f_end, long f_len, long f_line}, pointer to struct inclist {pointer to char i_incstring, pointer to char i_file, pointer to pointer to struct inclist {..} i_list, int i_listlen, unsigned char i_defchecked, unsigned char i_notified, unsigned char i_marked, unsigned char i_searched, unsigned char i_included_sym}, pointer to struct inclist {pointer to char i_incstring, pointer to char i_file, pointer to pointer to struct inclist {..} i_list, int i_listlen, unsigned char i_defchecked, unsigned char i_notified, unsigned char i_marked, unsigned char i_searched, unsigned char i_included_sym}, pointer to char, unsigned char, unsigned char, pointer to struct IncludesCollection {}, pointer to struct symhash {array[64] of pointer to struct pair {..} s_pairs}) returning void : "def.h", line 176
"pr.c", line 42: warning: Prototype mismatch in arg 5 for function add_include:
function : old style declaration unsigned char promoted to int
prototype: unsigned char
"pr.c", line 42: warning: Prototype mismatch in arg 6 for function add_include:
function : old style declaration unsigned char promoted to int
prototype: unsigned char
Compiling: soltools/mkdepend/collectdircontent.cxx
"/extra/sources/OpenOffice/aoo4/main/soltools/mkdepend/collectdircontent.hxx", line 6: Error: Could not open include file<set>.
"/extra/sources/OpenOffice/aoo4/main/soltools/mkdepend/collectdircontent.hxx", line 7: Error: Could not open include file<map>.
"/extra/sources/OpenOffice/aoo4/main/soltools/mkdepend/collectdircontent.hxx", line 8: Error: Could not open include file<string>.
"/extra/sources/OpenOffice/aoo4/main/soltools/mkdepend/collectdircontent.hxx", line 17: Error: Could not open include file<iostream>.
"/extra/sources/OpenOffice/aoo4/main/soltools/mkdepend/collectdircontent.hxx", line 21: Warning: Implicit int is not supported in C++.
"/extra/sources/OpenOffice/aoo4/main/soltools/mkdepend/collectdircontent.hxx", line 21: Error: Template set is not defined.
"/extra/sources/OpenOffice/aoo4/main/soltools/mkdepend/collectdircontent.hxx", line 22: Warning: Implicit int is not supported in C++.
"/extra/sources/OpenOffice/aoo4/main/soltools/mkdepend/collectdircontent.hxx", line 22: Error: Template map is not defined.
"/extra/sources/OpenOffice/aoo4/main/soltools/mkdepend/collectdircontent.hxx", line 22: Error: Use ";" to terminate declarations.
"/extra/sources/OpenOffice/aoo4/main/soltools/mkdepend/collectdircontent.hxx", line 22: Error: A declaration was expected instead of ",".
"/extra/sources/OpenOffice/aoo4/main/soltools/mkdepend/collectdircontent.hxx", line 22: Warning: Implicit int is not supported in C++.
"/extra/sources/OpenOffice/aoo4/main/soltools/mkdepend/collectdircontent.hxx", line 22: Error: "," expected instead of ">".
"/extra/sources/OpenOffice/aoo4/main/soltools/mkdepend/collectdircontent.hxx", line 23: Error: DirMap is not defined.
"/extra/sources/OpenOffice/aoo4/main/soltools/mkdepend/collectdircontent.hxx", line 23: Error: value_type is not defined.
"/extra/sources/OpenOffice/aoo4/main/soltools/mkdepend/collectdircontent.hxx", line 24: Warning: Implicit int is not supported in C++.
"/extra/sources/OpenOffice/aoo4/main/soltools/mkdepend/collectdircontent.hxx", line 24: Error: Template pair is not defined.
"/extra/sources/OpenOffice/aoo4/main/soltools/mkdepend/collectdircontent.hxx", line 24: Error: Use ";" to terminate declarations.
"/extra/sources/OpenOffice/aoo4/main/soltools/mkdepend/collectdircontent.hxx", line 24: Error: A declaration was expected instead of ",".
"/extra/sources/OpenOffice/aoo4/main/soltools/mkdepend/collectdircontent.hxx", line 24: Warning: Implicit int is not supported in C++.
"/extra/sources/OpenOffice/aoo4/main/soltools/mkdepend/collectdircontent.hxx", line 24: Error: "," expected instead of ">".
"/extra/sources/OpenOffice/aoo4/main/soltools/mkdepend/collectdircontent.hxx", line 29: Error: Type name expected instead of "DirMap".
"/extra/sources/OpenOffice/aoo4/main/soltools/mkdepend/collectdircontent.hxx", line 32: Error: Type name expected instead of "PathFilePair".
"/extra/sources/OpenOffice/aoo4/main/soltools/mkdepend/collectdircontent.hxx", line 32: Error: Use ";" to terminate declarations.
"/extra/sources/OpenOffice/aoo4/main/soltools/mkdepend/collectdircontent.hxx", line 33: Error: Use ";" to terminate declarations.
"/extra/sources/OpenOffice/aoo4/main/soltools/mkdepend/collectdircontent.hxx", line 33: Warning: Implicit int is not supported in C++.
"/extra/sources/OpenOffice/aoo4/main/soltools/mkdepend/collectdircontent.hxx", line 33: Error: ")" expected instead of "&".
"/extra/sources/OpenOffice/aoo4/main/soltools/mkdepend/collectdircontent.hxx", line 36: Error: Type name expected instead of "string".
"/extra/sources/OpenOffice/aoo4/main/soltools/mkdepend/collectdircontent.cxx", line 3: Error: PathFilePair is not defined.
"/extra/sources/OpenOffice/aoo4/main/soltools/mkdepend/collectdircontent.cxx", line 3: Warning: Implicit int is not supported in C++.
"/extra/sources/OpenOffice/aoo4/main/soltools/mkdepend/collectdircontent.cxx", line 3: Error: ")" expected instead of "&".
"/extra/sources/OpenOffice/aoo4/main/soltools/mkdepend/collectdircontent.cxx", line 4: Error: string is not defined.
"/extra/sources/OpenOffice/aoo4/main/soltools/mkdepend/collectdircontent.cxx", line 4: Error: Cannot use const char* to initialize int.
Compilation aborted, too many Error messages.
dmake: Error code 2, while making '../unxsoli4.pro/obj/collectdircontent.obj'
1 module(s):
soltools
need(s) to be rebuilt
Reason(s):
ERROR: error 65280 occurred while making /extra/sources/OpenOffice/aoo4/main/soltools/mkdepend
When you have fixed the errors in that module you can resume the build by running:
build --all:soltools
I would really appreciate it if anyone could explain why the build script does not pick the
correct compiler? Here collectdircontent.cxx is being compiled with the C compiler while
it is a CC file.
Regards,
A.S.
--
Apostols Syropoulos
Xanthi, Greece
RE: soltools need(s) to be rebuilt
Posted by Απόστολος Συρόπουλος <as...@hotmail.com>.
>
> Many of those projects have RTTI or C++ exceptions disabled, so problems
> with typeinfo visibility may not show up there.
>
I have figured out that I need to use GCC with the Solaris linker to avoid all
these problems. BTW, the GCC people suggest people who use their
compiler on Solaris to avoid using the GNU linker. So when I switched to
the Solaris linker, all these problems disappeared. So the file
solenv/gbuild/platform/solaris.mk
need to modified in order to compile with GCC. As it stands, it assumes
the compilation on Solaris is done using Solaris Studio!
>
> They certainly will be. I'm looking forward to have "unxsogi" as a
> platform with an out of the box build experience again.
>
Me too :-)
A.S.
--
Apostols Syropoulos
Xanthi, Greece
Re: soltools need(s) to be rebuilt
Posted by Herbert Duerr <hd...@alice.de>.
Hi Απόστολος,
On 09.12.2013 19:30, Απόστολος Συρόπουλος wrote:
> I have noticed that visibility does not work in Solaris with gcc.
> The compiler complains that it is not defined or available to
> this platform. Since I have compiled gcc myself chances are
> that I did something wrong... However, I have compiled Qt
> with this compiler, the TeX distribution and many many other
> things and all work as expected...
Many of those projects have RTTI or C++ exceptions disabled, so problems
with typeinfo visibility may not show up there.
By the way: do the command lines for compiling individual AOO source
files mention any options regarding rtti or visibility?
>> The manual interventions are good to experiment with different solution
>> approaches. When the experiments provided a clearer picture the solenv
>> makefiles for the "unxsogi" platform should be updated so all that could
>> work out of the box. We have so many libraries that it would be quite
>> painful if one had to do many of them manually.
>>
>
> I totally agree! But I keep notes of what I do so I hope these notes
> would be useful when I will hopefully finish.
They certainly will be. I'm looking forward to have "unxsogi" as a
platform with an out of the box build experience again.
Herbert
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
RE: soltools need(s) to be rebuilt
Posted by Απόστολος Συρόπουλος <as...@hotmail.com>.
>
> Speaking of symbol visibility on unxsogi platforms there is an
> interesting comment in
> main/solenv/inc/unxsogi.mk
> regarding that topic. In
> main/sal/inc/sal/types.h
> In that file there is some magic going on with that visibility and I'm
> quite sure that the Solaris+gcc specific checks need to be updated to
> work with newer versions of these tools.
>
Hello,
I have noticed that visibility does not work in Solaris with gcc.
The compiler complains that it is not defined or available to
this platform. Since I have compiled gcc myself chances are
that I did something wrong... However, I have compiled Qt
with this compiler, the TeX distribution and many many other
things and all work as expected...
>
> The manual interventions are good to experiment with different solution
> approaches. When the experiments provided a clearer picture the solenv
> makefiles for the "unxsogi" platform should be updated so all that could
> work out of the box. We have so many libraries that it would be quite
> painful if one had to do many of them manually.
>
I totally agree! But I keep notes of what I do so I hope these notes
would be useful when I will hopefully finish.
All the best,
A.S.
--
Apostols Syropoulos
Xanthi, Greece
Re: soltools need(s) to be rebuilt
Posted by Herbert Duerr <hd...@apache.org>.
On 08.12.2013 20:38, Απόστολος Συρόπουλος wrote:
> [...]
> This way I managed to build the missing libraries. I continued but
> building stopped at:
>
> build --all:binaryurp
>
> The following commands "helped" me to build the library:
>[...]
>
> Now it stops as follows:
>[...]
> Entering /extra/sources/OpenOffice/aoo4/main/eventattacher/source
> [...]
> : ERROR: ld.so.1: checkdll: fatal: relocation error: file ../unxsogi.pro/lib/check_libevtatt.so: symbol _ZTIN4cppu11OWeakObjectE: referenced symbol not found
The demangled name of this symbol means
typeinfo for cppu::OWeakObject
AFAIK it should come from cppuhelper. Experts on cppuhelper or typeinfo
visibility are invited to help us outhere...
Speaking of symbol visibility on unxsogi platforms there is an
interesting comment in
main/solenv/inc/unxsogi.mk
regarding that topic. In
main/sal/inc/sal/types.h
In that file there is some magic going on with that visibility and I'm
quite sure that the Solaris+gcc specific checks need to be updated to
work with newer versions of these tools.
> I guess I can use a similar trick to continue, but the question is: Is this the right way to build these libraries?
The manual interventions are good to experiment with different solution
approaches. When the experiments provided a clearer picture the solenv
makefiles for the "unxsogi" platform should be updated so all that could
work out of the box. We have so many libraries that it would be quite
painful if one had to do many of them manually.
Herbert
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
RE: soltools need(s) to be rebuilt
Posted by Απόστολος Συρόπουλος <as...@hotmail.com>.
>
> You are making great progress! Congratulations!
>
Thank you Herbert!
>
> I wouldn't be surprised if exporting all the symbols of this library
> would work just as well. The reduction of the exported symbols to just
> the method mentioned above and its parameter types may just be cosmetic.
> Again: experts on this topic are invited to join.
>
Based on this remark I did the following:
$build --all:cppu
$ cd ../cppu/source
$ cp ../unxsogi.pro/misc/cppu.libunsafe_uno_uno_3.cmd .
$ bash cppu.libunsafe_uno_uno_3.cmd
$ cp ../unxsogi.pro/misc/cppu.libaffine_uno_uno_4.cmd .
$ bash cppu.libaffine_uno_uno_4.cmd
$ cp ../unxsogi.pro/misc/cppu.liblog_uno_uno_5.cmd .
$ bash cp cppu.liblog_uno_uno_5.cmd
This way I managed to build the missing libraries. I continued but
building stopped at:
build --all:binaryurp
The following commands "helped" me to build the library:
$ cd main/binaryurp/source
$ cp ../unxsogi.pro/misc/binaryurp.binaryurp.uno_1.cmd .
$ bash binaryurp.binaryurp.uno_1.cmd
Now it stops as follows:
=============
Building module eventattacher
=============
Entering /extra/sources/OpenOffice/aoo4/main/eventattacher/source
mkout -- version: 1.8
Making: all_evtatt.dpslo
Compiling: eventattacher/unxsogi.pro/misc/evtatt_version.c
Compiling: eventattacher/source/eventattacher.cxx
Making: evtatt.lib
Making: libevtatt.so
: ERROR: ld.so.1: checkdll: fatal: relocation error: file ../unxsogi.pro/lib/check_libevtatt.so: symbol _ZTIN4cppu11OWeakObjectE: referenced symbol not found
dmake: Error code 1, while making '../unxsogi.pro/lib/libevtatt.so'
1 module(s):
eventattacher
need(s) to be rebuilt
Reason(s):
ERROR: error 65280 occurred while making /extra/sources/OpenOffice/aoo4/main/eventattacher/source
When you have fixed the errors in that module you can resume the build by running:
build --all:eventattacher
I guess I can use a similar trick to continue, but the question is: Is this the right way to build these libraries?
Best regards,
A.S.
--
Apostols Syropoulos
Xanthi, Greece
Re: soltools need(s) to be rebuilt
Posted by Herbert Duerr <hd...@apache.org>.
γειά σου Απόστολος,
>> I have to admit that I have no clue about libxmlsec's detailed configure
>> requirements, so I'm afraid I can't help here much. But with the
>> knowledge that licrypto comes from openssl, with libxmlsec complaining
>> about the one openssl is providing maybe some changed linker or build
>> options could suffice. I'm sure you're on the right track with the
>> unxsogi.mk changes you suggest below.
>>
>
> Finally, I have managed to build the library. Whether it is a good one, this
> is something that I will discover when I will finish.
You are making great progress! Congratulations!
> Now I have another problem. When compiling cppu I I get the following error message:
>
> Entering /extra/sources/OpenOffice/aoo4/main/cppu/util
>
> dmake: /extra/sources/OpenOffice/aoo4/main/solenv/inc/target.mk: line 545: Warning: -- Macro `SHL2TARGETN' redefined after use
I'm no expert on these makefiles, but the $(SHL2TARGETN) target there
looks redundant because it is usually already defined in
main/solenv/inc/_tg_shl.mk
and the SHL2TARGETN define is done in
main/solenv/inc/target.mk
If the one defined in the main/cppu/util/makefile.mk just redefines
whats already there maybe it can be safely removed.
On the other hand make "just" warns about it. Does the build really
break here?
> [...]
> dmake: Error: -- `uno_purpenvhelper.map' not found, and can't be made
The purpenvhelper.map is another piece of black magic that I know not
much about. People knowing more about it are invited to join...
What I know about it is that it limits the symbol exports of that
particular library to basically only one function:
cppu::helper::purpenv::Environment_initWithEnterable( uno_Environment*,
cppu::Enterable *);
I wouldn't be surprised if exporting all the symbols of this library
would work just as well. The reduction of the exported symbols to just
the method mentioned above and its parameter types may just be cosmetic.
Again: experts on this topic are invited to join.
> [...]
> Of course there is no uno_purpenvhelper.map file. The code that is responsible for this is inside main/cppu/util/makefile.mk:
> [...]
> SHL2VERSIONMAP:=uno_purpenvhelper$(COMID).map
In main/cppu/source/helper/purpenv/export.mk there is a similar line and
there seems to be a heck of a lot of "cleanup potential" :-/ Makefile
experts are invited...
>From the error message mentioning "uno_purpenvhelper.map" and the recipe
above I see that the COMID define is apparently not set. AFAIK it is
supposed to be set in main/solenv/inc/tg_compv.mk. Maybe one of the many
conditions in there needs to be tweaked for your platform. If you are
building with gcc then COMID should probably be "gcc3" and with a little
bit of luck the already existing uno_purpenvhelpergcc3.map file may
already work.
Hope that helps,
Herbert
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
RE: soltools need(s) to be rebuilt
Posted by Απόστολος Συρόπουλος <as...@hotmail.com>.
Dear Herbert,
>
> I have to admit that I have no clue about libxmlsec's detailed configure
> requirements, so I'm afraid I can't help here much. But with the
> knowledge that licrypto comes from openssl, with libxmlsec complaining
> about the one openssl is providing maybe some changed linker or build
> options could suffice. I'm sure you're on the right track with the
> unxsogi.mk changes you suggest below.
>
Finally, I have managed to build the library. Whether it is a good one, this
is something that I will discover when I will finish.
Now I have another problem. When compiling cppu I I get the following error message:
Entering /extra/sources/OpenOffice/aoo4/main/cppu/util
dmake: /extra/sources/OpenOffice/aoo4/main/solenv/inc/target.mk: line 545: Warning: -- Macro `SHL2TARGETN' redefined after use
Compiling: cppu/unxsogi.pro/misc/uno_cppu_version.c
Compiling: cppu/unxsogi.pro/misc/uno_purpenvhelper_version.c
Making: libuno_cppu.so.3
dmake: Error: -- `uno_purpenvhelper.map' not found, and can't be made
Under main/cppu/util I see the following .map files:
cppu.map
uno_purpenvhelperC52.map
uno_purpenvhelperwntgcc.map
purpenvhelper3MSC.map
uno_purpenvhelpergcc3.map
unsafe_os2.map
Of course there is no uno_purpenvhelper.map file. The code that is responsible for this is inside main/cppu/util/makefile.mk:
SHL2TARGET := $(NAMEpurpenv_helper)
DEF2NAME := $(SHL2TARGET)
.IF "$(GUI)$(COM)"=="WNTGCC"
SHL2VERSIONMAP:=uno_purpenvhelper$(COMID).map
.ELIF "$(GUI)"=="OS2"
SHL2VERSIONMAP:=uno_purpenvhelperwntgcc.map
.ELSE
SHL2VERSIONMAP:=$(SHL2TARGET).map <------ We are here
.ENDIF # "$(GUI)$(COM)"=="WNTGCC"
SHL2DEF := $(MISC)$/$(SHL2TARGET).def
Do you or anybody else have any idea which is the correct file to use?
Regards,
Apostolos
--
Apostols Syropoulos
Xanthi, Greece
Re: soltools need(s) to be rebuilt
Posted by Herbert Duerr <hd...@apache.org>.
Hi Απόστολος,
Απόστολος Συρόπουλος wrote:
>> Did it build with these configure options? Except for the minor nit that
>> --with-openssl is set twice, it looks good to me. The option has been
>> set as "no" and as "/usr", but AFAIK the "no" should win.
>
> The problem is that when configuring without the "/usr" value, the configure script
> stops and complains that there is no libcrypto!
> [...]
I have to admit that I have no clue about libxmlsec's detailed configure
requirements, so I'm afraid I can't help here much. But with the
knowledge that licrypto comes from openssl, with libxmlsec complaining
about the one openssl is providing maybe some changed linker or build
options could suffice. I'm sure you're on the right track with the
unxsogi.mk changes you suggest below.
> Now. I am building using the unxsogi.mk file. This is something the
> building tools have chosen.
That "unxsogi" choice is AFAIK generated from different pieces of
information:
- "unx" stands for a Unix platform
- "so" for solaris
- "g" for the gnu-compiler
- "i" for an intel-x86 32bit cpu
>From all that I know from about your configuration the platform name
"unxsogi" sounds like the right one.
> However, I have noticed that this file does not
> contain any LINKFLAGSRUNPATH variables
> [...]
> I feel that unxsogi.mk is incomplete but then again I might be wrong.
I'm sure the unxsogi.mk file needs some maintenance. It was last updated
in 2007 when the build environment was different and gcc3 roamed the earth.
> I have added the following lines in this file
> [...many interesting makefile changes...]
Thanks for finding solutions to the build problems on the unxsogi platform!
> but I guess I need to reconfigure so this lines will be used in the building process, right?
If in doubt a reconfigure and a clean build is always the right thing to
do. Please be aware that the unxsogi.mk is only for modules still using
the dmake build system. Modules already using the gnumake build system
have their solaris specific
main/solenv/gbuild/platform/solaris.mk
instead, which probably needs some adjustments too.
Herbert
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
RE: soltools need(s) to be rebuilt
Posted by Απόστολος Συρόπουλος <as...@hotmail.com>.
Hello Herbert,
>
> Did it build with these configure options? Except for the minor nit that
> --with-openssl is set twice, it looks good to me. The option has been
> set as "no" and as "/usr", but AFAIK the "no" should win.
>
The problem is that when configuring without the "/usr" value, the configure script
stops and complains that there is no libcrypto!
> > There is a libcrypto.a in /extra/sources/OpenOffice/aoo4/main/solver/410/unxsogi.pro/lib
> > but this cannot be used to build a shared object (at least that's what the linkers say).
>
> That libcrypto.a comes from openssl and if libxmlsec was configured with
> the "--with-openssl=no" option it shouldn't be needed anyway.
Sounds quite reasonable but the configure script, as I have mentioned above,
complains. Now. I am building using the unxsogi.mk file. This is something the
building tools have chosen. However, I have noticed that this file does not
contain any LINKFLAGSRUNPATH variables and so when building idlc, I get
the following error:
Making: idlc
unx
/opt/gnu/bin/gld: warning: libstore.so.3, needed by /extra/sources/OpenOffice/aoo4/main/solver/410/unxsogi.pro/lib/libreg.so, not found (try using -rpath or -rpath-link)
I feel that unxsogi.mk is incomplete but then again I might be wrong. I have added the following lines in this file
LINKFLAGSRUNPATH_URELIB=-Wl,-z,origin -Wl,-rpath,\''$$ORIGIN'\'
LINKFLAGSRUNPATH_UREBIN=-Wl,-z,origin -Wl,-rpath,\''$$ORIGIN'\'
#LINKFLAGSRUNPATH_UREBIN=-Wl,-z,origin -Wl,-rpath,\''$$ORIGIN/../lib:$$ORIGIN'\'
#TODO: drop $ORIGIN once no URE executable is also shipped in OOo
LINKFLAGSRUNPATH_OOO=-Wl,-z,origin -Wl,-rpath,\''$$ORIGIN'\'
LINKFLAGSRUNPATH_SDK=-Wl,-z,origin -Wl,-rpath,\''$$ORIGIN'\'
LINKFLAGSRUNPATH_BRAND=-Wl,-z,origin -Wl,-rpath,\''$$ORIGIN'\'
#LINKFLAGSRUNPATH_OOO=-Wl,-z,origin -Wl,-rpath,\''$$ORIGIN:$$ORIGIN/../ure-link/lib'\'
#LINKFLAGSRUNPATH_SDK=-Wl,-z,origin -Wl,-rpath,\''$$ORIGIN/../../ure-link/lib'\'
#LINKFLAGSRUNPATH_BRAND=-Wl,-z,origin -Wl,-rpath,\''$$ORIGIN:$$ORIGIN/../basis-link/program:$$ORIGIN/../basis-link/ure-link/lib'\'
LINKFLAGSRUNPATH_OXT=
LINKFLAGSRUNPATH_BOXT=-Wl,-z,origin -Wl,-rpath,\''$$ORIGIN'\'
#LINKFLAGSRUNPATH_BOXT=-Wl,-z,origin -Wl,-rpath,\''$$ORIGIN/../../../basis-link/program'\'
LINKFLAGSRUNPATH_NONE=
but I guess I need to reconfigure so this lines will be used in the building process, right?
Best regards,
Apostolos
Re: soltools need(s) to be rebuilt
Posted by Herbert Duerr <hd...@apache.org>.
Hi Απόστολος,
On 04.12.2013 21:28, Απόστολος Συρόπουλος wrote:
> I am still struggling... Now I was trying to build libxmlsec and the
> configuration parameters did not give the expected result. I had
> to enter manually the following command
>
> ./configure ADDCFLAGS= CPPFLAGS= --with-pic --disable-shared --disable-crypto-dl --with-libxslt=no --with-openssl=no --with-gnutls=no LIBXML2LIB=-lxml2 --enable-pkgconfig=no --with-openssl=/usr --with-nss=/extra/sources/OpenOffice/aoo4/main/solver/410/unxsogi.pro --with-nspr=/extra/sources/OpenOffice/aoo4/main/solver/410/unxsogi.pro
>
> in order to build the libraries. Is this OK?
Did it build with these configure options? Except for the minor nit that
--with-openssl is set twice, it looks good to me. The option has been
set as "no" and as "/usr", but AFAIK the "no" should win.
> There is a libcrypto.a in /extra/sources/OpenOffice/aoo4/main/solver/410/unxsogi.pro/lib
> but this cannot be used to build a shared object (at least that's what the linkers say).
That libcrypto.a comes from openssl and if libxmlsec was configured with
the "--with-openssl=no" option it shouldn't be needed anyway.
Herbert
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
RE: soltools need(s) to be rebuilt
Posted by Απόστολος Συρόπουλος <as...@hotmail.com>.
Hello,
I am still struggling... Now I was trying to build libxmlsec and the
configuration parameters did not give the expected result. I had
to enter manually the following command
./configure ADDCFLAGS= CPPFLAGS= --with-pic --disable-shared --disable-crypto-dl --with-libxslt=no --with-openssl=no --with-gnutls=no LIBXML2LIB=-lxml2 --enable-pkgconfig=no --with-openssl=/usr --with-nss=/extra/sources/OpenOffice/aoo4/main/solver/410/unxsogi.pro --with-nspr=/extra/sources/OpenOffice/aoo4/main/solver/410/unxsogi.pro
in order to build the libraries. Is this OK? There is a libcrypto.a in /extra/sources/OpenOffice/aoo4/main/solver/410/unxsogi.pro/lib
but this cannot be used to build a shared object (at least that's what the linkers say).
Regards,
A.S.
--
Apostols Syropoulos
Xanthi, Greece
RE: soltools need(s) to be rebuilt
Posted by Απόστολος Συρόπουλος <as...@hotmail.com>.
>
> I suggest to look into main/sal/osl/unx/util.c. The check for a
> __SUNPRO_C define in line 316 looks suspicious. Is this define still
> active in newer compilers for your platform? If not please change the
> check so that this part of the code becomes active.
>
> You also said you switched compilers. Please make sure that there are no
> object files around that were build for the other compiler.
>
Hello Herbert,
This suggestion helped me to solve this problem. Thank you! Now the next problem is
that I am gettiing an error similar to the one reported in the URL that follows:
https://lists.gnu.org/archive/html/bug-binutils/2011-09/msg00054.html
The problem of course is that I have to build with the GNU linker instead of
the Solaris linker. I have temporally set that the system linker is the
Solaris linker and this solved this problem. Of course I have idea where
the libraries of the nss module are used and how this will affect the
building process. Also, I have no idea why one should use the GNU linker
on Solaris when the GCC people advise not to use it with GCC.
A.S.
--
Apostols Syropoulos
Xanthi, Greece
Re: soltools need(s) to be rebuilt
Posted by Herbert Duerr <hd...@apache.org>.
On 01.12.2013 20:26, Απόστολος Συρόπουλος wrote:
> After reading the reply by jan I. I decided to try again with GCC.
> Now, compilation proceeds with no stupid problems as before.
> BTW, main/soltools/adjustvisibility/adjustvisibility.c does not
> compile with g++ but it compiles with CC so this is the only
> thing I had to do manually. However, now compilation stops
> as follows:
> [...]
> : ERROR: ld.so.1: checkdll: fatal: relocation error: file ../unxsogi.pro/lib/check_libuno_sal.so.3: symbol osl_isSingleCPU: referenced symbol not found
> [...]
> I see that file interlck_x86.s is old... but I have no idea why linking fails. Any ideas and/or suggestions?
I suggest to look into main/sal/osl/unx/util.c. The check for a
__SUNPRO_C define in line 316 looks suspicious. Is this define still
active in newer compilers for your platform? If not please change the
check so that this part of the code becomes active.
You also said you switched compilers. Please make sure that there are no
object files around that were build for the other compiler.
Herbert
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
RE: soltools need(s) to be rebuilt
Posted by Απόστολος Συρόπουλος <as...@hotmail.com>.
After reading the reply by jan I. I decided to try again with GCC.
Now, compilation proceeds with no stupid problems as before.
BTW, main/soltools/adjustvisibility/adjustvisibility.c does not
compile with g++ but it compiles with CC so this is the only
thing I had to do manually. However, now compilation stops
as follows:
Entering /extra/sources/OpenOffice/aoo4/main/sal/osl/unx
tr -d "\015" < asm/interlck_x86.s > ../../unxsogi.pro/misc/interlck_x86.s
/usr/bin/gas -o ../../unxsogi.pro/obj/interlck.o ../../unxsogi.pro/misc/interlck_x86.s
touch ../../unxsogi.pro/obj/interlck.obj
Making: cpposl.lib
/usr/bin/gas -o ../../unxsogi.pro/slo/interlck.o ../../unxsogi.pro/misc/interlck_x86.s
touch ../../unxsogi.pro/slo/interlck.obj
Making: cpposl.lib
dmake: Warning: -- Target [../../unxsogi.pro/misc/s_interlck.dpcc] was made but the time stamp has not been updated.
dmake: Warning: -- Target [../../unxsogi.pro/misc/o_interlck.dpcc] was made but the time stamp has not been updated.
Entering /extra/sources/OpenOffice/aoo4/main/sal/textenc
Entering /extra/sources/OpenOffice/aoo4/main/sal/osl/all
Entering /extra/sources/OpenOffice/aoo4/main/sal/util
Making: sal.lib
Making: asal.lib
Making: libsal.a
ar: creating ../unxsogi.pro/lib/libsal.a
Making: libuno_sal.so.3
: ERROR: ld.so.1: checkdll: fatal: relocation error: file ../unxsogi.pro/lib/check_libuno_sal.so.3: symbol osl_isSingleCPU: referenced symbol not found
dmake: Error code 1, while making '../unxsogi.pro/lib/libuno_sal.so.3'
1 module(s):
sal
need(s) to be rebuilt
Reason(s):
ERROR: error 65280 occurred while making /extra/sources/OpenOffice/aoo4/main/sal/util
When you have fixed the errors in that module you can resume the build by running:
build --all:sal
I see that file interlck_x86.s is old... but I have no idea why linking fails. Any ideas and/or suggestions?
Rgds,
A.S.
--
Apostols Syropoulos
Xanthi, Greece
Re: soltools need(s) to be rebuilt
Posted by jan i <ja...@apache.org>.
On 1 December 2013 15:44, Απόστολος Συρόπουλος
<as...@hotmail.com>wrote:
> Hello again,
>
> I have downloaded the source code and I have reconfigured etc.
> What I have observed so far is that there are a number of
> utilities that consist of C and C++ source files. In all these cases,
> the build script uses the C compile and so obviously it fails to build
> the object files. For example,
>
> =============
> Building module soltools
> =============
>
> Entering /extra/sources/OpenOffice/aoo4/main/soltools/mkdepend
>
> mkout -- version: 1.8
> Compiling: soltools/mkdepend/cppsetup.c
> cc: Warning: illegal use of -features option, illegal item ignored:
> rvalueref
> cc: Warning: illegal use of -features option, empty value ignored
>
This can be something as simple as your cc not supporting --features.
You have to look at the actual cc statement (it copied to stdout), to get
an idea whats wrong.
> Compiling: soltools/mkdepend/ifparser.c
> cc: Warning: illegal use of -features option, illegal item ignored:
> rvalueref
> cc: Warning: illegal use of -features option, empty value ignored
> Compiling: soltools/mkdepend/include.c
> cc: Warning: illegal use of -features option, illegal item ignored:
> rvalueref
> cc: Warning: illegal use of -features option, empty value ignored
> Compiling: soltools/mkdepend/main.c
> cc: Warning: illegal use of -features option, illegal item ignored:
> rvalueref
> cc: Warning: illegal use of -features option, empty value ignored
> Compiling: soltools/mkdepend/parse.c
> cc: Warning: illegal use of -features option, illegal item ignored:
> rvalueref
> cc: Warning: illegal use of -features option, empty value ignored
> "parse.c", line 43: warning: identifier redeclared: find_includes
> current : function() returning int
> previous: function(pointer to struct filepointer {pointer to char f_p,
> pointer to char f_base, pointer to char f_end, long f_len, long f_line},
> pointer to struct inclist {pointer to char i_incstring, pointer to char
> i_file, pointer to pointer to struct inclist {..} i_list, int i_listlen,
> unsigned char i_defchecked, unsigned char i_notified, unsigned char
> i_marked, unsigned char i_searched, unsigned char i_included_sym}, pointer
> to struct inclist {pointer to char i_incstring, pointer to char i_file,
> pointer to pointer to struct inclist {..} i_list, int i_listlen, unsigned
> char i_defchecked, unsigned char i_notified, unsigned char i_marked,
> unsigned char i_searched, unsigned char i_included_sym}, int, unsigned
> char, pointer to struct IncludesCollection {}, pointer to struct symhash
> {array[64] of pointer to struct pair {..} s_pairs}) returning int :
> "def.h", line 169
> "parse.c", line 43: warning: Prototype mismatch in arg 5 for function
> find_includes:
> function : old style declaration unsigned char promoted to int
> prototype: unsigned char
>
This is normally caused be wrong compiler options, or an unsupported
compiler.
To me it looks at if you should change your ./configure statement. Look in
wiki.openoffice.org for different options.
> Compiling: soltools/mkdepend/pr.c
> cc: Warning: illegal use of -features option, illegal item ignored:
> rvalueref
> cc: Warning: illegal use of -features option, empty value ignored
> "pr.c", line 42: warning: identifier redeclared: add_include
> current : function() returning void
> previous: function(pointer to struct filepointer {pointer to char f_p,
> pointer to char f_base, pointer to char f_end, long f_len, long f_line},
> pointer to struct inclist {pointer to char i_incstring, pointer to char
> i_file, pointer to pointer to struct inclist {..} i_list, int i_listlen,
> unsigned char i_defchecked, unsigned char i_notified, unsigned char
> i_marked, unsigned char i_searched, unsigned char i_included_sym}, pointer
> to struct inclist {pointer to char i_incstring, pointer to char i_file,
> pointer to pointer to struct inclist {..} i_list, int i_listlen, unsigned
> char i_defchecked, unsigned char i_notified, unsigned char i_marked,
> unsigned char i_searched, unsigned char i_included_sym}, pointer to char,
> unsigned char, unsigned char, pointer to struct IncludesCollection {},
> pointer to struct symhash {array[64] of pointer to struct pair {..}
> s_pairs}) returning void : "def.h", line 176
> "pr.c", line 42: warning: Prototype mismatch in arg 5 for function
> add_include:
> function : old style declaration unsigned char promoted to int
> prototype: unsigned char
> "pr.c", line 42: warning: Prototype mismatch in arg 6 for function
> add_include:
> function : old style declaration unsigned char promoted to int
> prototype: unsigned char
> Compiling: soltools/mkdepend/collectdircontent.cxx
> "/extra/sources/OpenOffice/aoo4/main/soltools/mkdepend/collectdircontent.hxx",
> line 6: Error: Could not open include file<set>.
> "/extra/sources/OpenOffice/aoo4/main/soltools/mkdepend/collectdircontent.hxx",
> line 7: Error: Could not open include file<map>.
> "/extra/sources/OpenOffice/aoo4/main/soltools/mkdepend/collectdircontent.hxx",
> line 8: Error: Could not open include file<string>.
> "/extra/sources/OpenOffice/aoo4/main/soltools/mkdepend/collectdircontent.hxx",
> line 17: Error: Could not open include file<iostream>.
> "/extra/sources/OpenOffice/aoo4/main/soltools/mkdepend/collectdircontent.hxx",
> line 21: Warning: Implicit int is not supported in C++.
> "/extra/sources/OpenOffice/aoo4/main/soltools/mkdepend/collectdircontent.hxx",
> line 21: Error: Template set is not defined.
> "/extra/sources/OpenOffice/aoo4/main/soltools/mkdepend/collectdircontent.hxx",
> line 22: Warning: Implicit int is not supported in C++.
> "/extra/sources/OpenOffice/aoo4/main/soltools/mkdepend/collectdircontent.hxx",
> line 22: Error: Template map is not defined.
> "/extra/sources/OpenOffice/aoo4/main/soltools/mkdepend/collectdircontent.hxx",
> line 22: Error: Use ";" to terminate declarations.
> "/extra/sources/OpenOffice/aoo4/main/soltools/mkdepend/collectdircontent.hxx",
> line 22: Error: A declaration was expected instead of ",".
> "/extra/sources/OpenOffice/aoo4/main/soltools/mkdepend/collectdircontent.hxx",
> line 22: Warning: Implicit int is not supported in C++.
> "/extra/sources/OpenOffice/aoo4/main/soltools/mkdepend/collectdircontent.hxx",
> line 22: Error: "," expected instead of ">".
> "/extra/sources/OpenOffice/aoo4/main/soltools/mkdepend/collectdircontent.hxx",
> line 23: Error: DirMap is not defined.
> "/extra/sources/OpenOffice/aoo4/main/soltools/mkdepend/collectdircontent.hxx",
> line 23: Error: value_type is not defined.
> "/extra/sources/OpenOffice/aoo4/main/soltools/mkdepend/collectdircontent.hxx",
> line 24: Warning: Implicit int is not supported in C++.
> "/extra/sources/OpenOffice/aoo4/main/soltools/mkdepend/collectdircontent.hxx",
> line 24: Error: Template pair is not defined.
> "/extra/sources/OpenOffice/aoo4/main/soltools/mkdepend/collectdircontent.hxx",
> line 24: Error: Use ";" to terminate declarations.
> "/extra/sources/OpenOffice/aoo4/main/soltools/mkdepend/collectdircontent.hxx",
> line 24: Error: A declaration was expected instead of ",".
> "/extra/sources/OpenOffice/aoo4/main/soltools/mkdepend/collectdircontent.hxx",
> line 24: Warning: Implicit int is not supported in C++.
> "/extra/sources/OpenOffice/aoo4/main/soltools/mkdepend/collectdircontent.hxx",
> line 24: Error: "," expected instead of ">".
> "/extra/sources/OpenOffice/aoo4/main/soltools/mkdepend/collectdircontent.hxx",
> line 29: Error: Type name expected instead of "DirMap".
> "/extra/sources/OpenOffice/aoo4/main/soltools/mkdepend/collectdircontent.hxx",
> line 32: Error: Type name expected instead of "PathFilePair".
> "/extra/sources/OpenOffice/aoo4/main/soltools/mkdepend/collectdircontent.hxx",
> line 32: Error: Use ";" to terminate declarations.
> "/extra/sources/OpenOffice/aoo4/main/soltools/mkdepend/collectdircontent.hxx",
> line 33: Error: Use ";" to terminate declarations.
> "/extra/sources/OpenOffice/aoo4/main/soltools/mkdepend/collectdircontent.hxx",
> line 33: Warning: Implicit int is not supported in C++.
> "/extra/sources/OpenOffice/aoo4/main/soltools/mkdepend/collectdircontent.hxx",
> line 33: Error: ")" expected instead of "&".
> "/extra/sources/OpenOffice/aoo4/main/soltools/mkdepend/collectdircontent.hxx",
> line 36: Error: Type name expected instead of "string".
> "/extra/sources/OpenOffice/aoo4/main/soltools/mkdepend/collectdircontent.cxx",
> line 3: Error: PathFilePair is not defined.
> "/extra/sources/OpenOffice/aoo4/main/soltools/mkdepend/collectdircontent.cxx",
> line 3: Warning: Implicit int is not supported in C++.
> "/extra/sources/OpenOffice/aoo4/main/soltools/mkdepend/collectdircontent.cxx",
> line 3: Error: ")" expected instead of "&".
> "/extra/sources/OpenOffice/aoo4/main/soltools/mkdepend/collectdircontent.cxx",
> line 4: Error: string is not defined.
> "/extra/sources/OpenOffice/aoo4/main/soltools/mkdepend/collectdircontent.cxx",
> line 4: Error: Cannot use const char* to initialize int.
> Compilation aborted, too many Error messages.
> dmake: Error code 2, while making '../
> unxsoli4.pro/obj/collectdircontent.obj'
>
> 1 module(s):
> soltools
> need(s) to be rebuilt
>
> Reason(s):
>
> ERROR: error 65280 occurred while making
> /extra/sources/OpenOffice/aoo4/main/soltools/mkdepend
>
> When you have fixed the errors in that module you can resume the build by
> running:
>
> build --all:soltools
>
> I would really appreciate it if anyone could explain why the build script
> does not pick the
> correct compiler? Here collectdircontent.cxx is being compiled with the C
> compiler while
> it is a CC file.
>
configure.in will look in the path to see if can find a c compiler, if not
it defaults to mingw.
Look at the configure output, that tells you which compiler is being used.
rgds
jan I.
>
> Regards,
> A.S.
>
>
> --
> Apostols Syropoulos
> Xanthi, Greece
>
>
>
>