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
γειά σου Απόστολος,
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
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
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
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
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
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
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
On 1 December 2013 15:44, Απόστολος Συρόπουλος
asyropoulos...@hotmail.comwrote:
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
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
On 28.11.2013 18:31, Απόστολος Συρόπουλος wrote:
[...]
I am proceeding slowly now since many things fail and I have to do them
manually. For example, the following fails
configure: configuring in CoinUtils
configure: running /bin/sh './configure'
The quoted -features=rvalueref compiler option is probably caused by the
ARCH_FLAGS define in main/solenv/inc/unxsoli4.mk
I suggest to unquote it. But why did it work for others? Did dmake
unquote automatically at one time?
I have no idea :-( However, I have managed to go further and now
On Fri, Nov 29, 2013 at 11:41 AM, Απόστολος Συρόπουλος
asyropoulos...@hotmail.com wrote:
The quoted -features=rvalueref compiler option is probably caused by the
ARCH_FLAGS define in main/solenv/inc/unxsoli4.mk
I suggest to unquote it. But why did it work for others? Did dmake
unquote
I dont know how you managed to get that directory.
I was manually building inside this folder...
the build system never add files or changes in the source directories. When
I look in
main/soltools/mkdepend on my system (after a complete build):
cd mkdepend/
ls
collectdircontent.cxx
On 28 November 2013 18:31, Απόστολος Συρόπουλος
asyropoulos...@hotmail.comwrote:
I dont know how you managed to get that directory.
I was manually building inside this folder...
the build system never add files or changes in the source directories.
When
I look in
On 27 November 2013 19:40, Απόστολος Συρόπουλος
asyropoulos...@hotmail.comwrote:
Hello,
I have come to the conclusion that OpenOffice cannot be configured (at
least easily)
to compile with GNU g++ under Solaris. So I have tried Solaris Studio.
Now I am
getting the following error message:
As with any makefile, the whole chain is checked, and when you are in
soltools/mkdepend it check the object files against the source, and the exe
against the object files.
I work on changing the build system, and I often cheat the make system by
doing touch obj file, that way its not
17 matches
Mail list logo