Thomas Lockhart | 12 Feb 2012 04:03
Favicon

Building for Mac OS X Lion

I'm trying to get code running on Mac OS X including omniORB and omniORBpy.

The current MacPorts ports are for 4.1.4 and 3.4, respectively, and 
fails to build on my recent MacBook with XCode-4.2.1. I've updated my 
copy of the port of omniORB to 4.1.6 and after setting DYLD_LIBRARY_PATH 
in the port script so the linker would find libraries in the build area 
I'm getting the following error:

/Developer/usr/bin/clang++ -o catior -L/opt/local/lib -arch x86_64 -pipe 
-O2 -arch x86_64 -fno-common -bind_at_load -L../../../../lib 
-L../../../../lib catior.o -lomniORB4 -lomnithread
Undefined symbols for architecture x86_64:
   "operator<<=(unsigned int&, cdrStream&)", referenced from:

_CORBA_Unbounded_Sequence<IOP::TaggedProfile>::operator<<=(cdrStream&) 
in catior.o

Which I see is indeed undefined in both catior.o and in 
libomniORB4.dylib (along with undefined operators for a few other int 
types). I'm guessing it is an implicit template issue but...

... when I look at libomniORB4.so on my Linux box I don't see any 
definition for operator<<=() with two arguments except for a strong 
symbol with "long double&" as the first argument. None with "unsigned int&".

Does this ring a bell with anyone? Any hints on where to look? Has 
anyone had success building with clang++ rather than gcc?

TIA

(Continue reading)

adeeshah | 28 Nov 2011 13:31
Picon

maximum size of -ORBgiopMaxMsgSize


Hi,

I have a omniorb server and client implementation and i set the
-ORBgiopMaxMsgSize on both to 10485760. But still sometime my corba server
crashed. And it usually happens when the size of the message is larger than
10485760. Can anyone tell me what is the maximum value that i can set for
-ORBgiopMaxMsgSize?

Adeel.
--

-- 
View this message in context: http://old.nabble.com/maximum-size-of--ORBgiopMaxMsgSize-tp32878030p32878030.html
Sent from the OmniORB - Dev mailing list archive at Nabble.com.
Thomas Lockhart | 8 Aug 2011 07:12
Favicon

RPM spec files for 4.1.6 and 3.6

I've done some light patching to get the as-shipped spec files happy 
with the new release. For some reason Fedora 15 seems to require that 
the library names be explicitly mentioned in the "provides" clause for 
the library package; I haven't run into this before and don't know if it 
is a change in rpm or a defect in FC15.

I've also parameterized the omniORB version number for the omniORBpy 
spec file since file names based on this version are mentioned farther 
down in the spec file.

                                         - Tom

Attachment (omniORB-spec-patches.tar.gz): application/x-gzip, 1942 bytes
_______________________________________________
omniORB-dev mailing list
omniORB-dev <at> omniorb-support.com
http://www.omniorb-support.com/mailman/listinfo/omniorb-dev
Floris Bruynooghe | 29 Mar 2011 22:18
Picon
Gravatar

Minor documentation patch

Hi

One of Debian's QA analysis efforts was to spot insecure usage of
PYTHONPATH, i.e. PYTHON=$PYTHONPATH:/some/path which could potentially
put the current working directory on the PYTHONPATH.  In OmniORBpy
this occurs only in the documentation, however they still regard that
as a security bug ;-).

As I'm always interested in keeping Debian's patches to a minimum
attached is the patch we applied to the documentation to fix this
issue, in case you would like to apply it upstream.

Regards
Floris

--

-- 
Debian GNU/Linux -- The Power of Freedom
www.debian.org | www.gnu.org | www.kernel.org
Attachment (pythonpath): application/octet-stream, 3013 bytes
_______________________________________________
omniORB-dev mailing list
omniORB-dev <at> omniorb-support.com
http://www.omniorb-support.com/mailman/listinfo/omniorb-dev
Naga Ram M Chavakula | 24 Nov 2010 14:00
Favicon

omniORB4.1.3 compilation error

Hi,

 

I got omniORB4.1.3 code from SVN, while I tried to make export, I get below error

 

making export in src/tool...

make[1]: Entering directory `/cygdrive/e/Nag/omniORB/src/tool'

making export in src/tool/omniidl...

make[2]: Entering directory `/cygdrive/e/Nag/omniORB/src/tool/omniidl'

making export in src/tool/omniidl/cxx...

make[3]: Entering directory `/cygdrive/e/Nag/omniORB/src/tool/omniidl/cxx'

make[3]: *** No rule to make target `/e/nag/omniorb/include/omniORB4/CORBA_sysde

p.h', needed by `idlc.d'.  Stop.

make[3]: Leaving directory `/cygdrive/e/Nag/omniORB/src/tool/omniidl/cxx'

make[2]: *** [export] Error 2

make[2]: Leaving directory `/cygdrive/e/Nag/omniORB/src/tool/omniidl'

make[1]: *** [export] Error 2

make[1]: Leaving directory `/cygdrive/e/Nag/omniORB/src/tool'

make: *** [export] Error 2

 

It is stopping while compiling idlc.d. Any suggestions how to resolve the issue

 

Thanks,

Naga Ram

 

_______________________________________________
omniORB-dev mailing list
omniORB-dev <at> omniorb-support.com
http://www.omniorb-support.com/mailman/listinfo/omniorb-dev
Naga Ram M Chavakula | 24 Nov 2010 10:09
Favicon

libwrapper compiler issue

Hi,

 

The  compilation of omniORB4.1.3 in XP with VC6 failed, I followed readme.win32 & did all necessary configuration.

I am getting below error while I run make export in the src folder as explained in readme file, I checked in static folder the files exist, but still libwrapper is causing below error

 

+ ../../../bin/x86_win32/libwrapper -gnuwin32 static/omnithread.lib static/nt.o

lib /OUT:static\omnithread.lib static\nt.o

lib: No such file or directory

make[2]: *** [static/omnithread"".lib] Error 1

make[2]: Leaving directory `/cygdrive/e/Nag/omniORB-4.1.3/omniORB-4.1.3/src/lib/

omnithread'

make[1]: *** [export] Error 2

make[1]: Leaving directory `/cygdrive/e/Nag/omniORB-4.1.3/omniORB-4.1.3/src/lib'

 

make: *** [export] Error 2

 

 

 

 

Thanks,

Naga Ram M Chavakula | Senior Project Manager

O: 608.448.3117|M: 0091.9885778079 | nagaram.chavakula <at> symphonycorp.com

Symphony Corporation | Hyderabad, A.P.India-500 082 | A SEI-CMMI Level 4 Company  

 We synchronize business, technology and people

" It is not difficult to be on TOP...It is difficult when you carry Truth,Commitment and Transparency with you"

 

_______________________________________________
omniORB-dev mailing list
omniORB-dev <at> omniorb-support.com
http://www.omniorb-support.com/mailman/listinfo/omniorb-dev
Mika Laitio | 13 Oct 2010 02:15
Favicon

patch to allow disabling the long double support

In some systems like mips or arm the gcc toolchain fails to build 
long double code that is generated from the corbaidl.idl
If we are in addition building in the cross compile environment, we must also call 
external omniidl instead of the just build one. Therfore the disabling of 
long double support from the just generated omniidl version would not 
work on crosscompile environment.

include/omniORB4/CORBA_sysdep_trad.h:
-#  define HAS_LongDouble
+#if defined(_GLIBCXX_USE_C99)
+	#  define HAS_LongDouble
+#endif

Therefore I created attached patch which adds "--disbale-longdouble" option to configure. (once
regenerated with autoreconf command) If --disable-longdouble is given, 
then -DDISABLE_LONGDOUBLE option is passed to omniidl when it is reguested 
to generate stups from corbaidl.idl. corbaidl.idl instead have new "ifndef 
DISABLE_LONGDOUBLE" check which surrounds the part of the idl which 
defines the long double sequence.

In addition of this patch, when crosscompiling for example to mips, I need 
to remove the $(TOOLBINDIR) from the omniidl path definition in 
mk/beforeauto.mk.in file so that my build systems omniidl will get called 
instead of this target system crosscompiled one.

Maybe another configure option for allowing to define the path to omniidl 
version used, would be a good idea? At the moment I do not have that 
available, but if that approach is good, I can try to create something.

Mika
diff -Naur omniorb_41_branch_orig/acinclude.m4 omniorb_41_branch_new/acinclude.m4
--- omniorb_41_branch_orig/acinclude.m4	2010-10-13 00:01:31.821617703 +0300
+++ omniorb_41_branch_new/acinclude.m4	2010-10-13 01:38:41.471615078 +0300
 <at>  <at>  -420,6 +420,18  <at>  <at> 
 fi
 ])
 
+dnl Disable support for long double even if the toolchain claims to support it. (does really not work on
mipsel or arm)
+AC_DEFUN([OMNI_DISABLE_LONGDOUBLE],
+[AC_CACHE_CHECK(whether to disable long double support even if toolchain supports it,
+omni_cv_enable_longdouble,
+[AC_ARG_ENABLE(longdouble,
+               AC_HELP_STRING([--disable-longdouble],
+                  [disable long double suppor (default enable-longdouble)]),
+               omni_cv_enable_longdouble=$enableval,
+               omni_cv_enable_longdouble=yes)
+])
+AC_SUBST(ENABLE_LONGDOUBLE, $omni_cv_enable_longdouble)
+])
 
 dnl
 dnl Tests from http://www.gnu.org/software/ac-archive/

diff -Naur omniorb_41_branch_orig/configure.ac omniorb_41_branch_new/configure.ac
--- omniorb_41_branch_orig/configure.ac	2010-10-13 00:01:20.549617644 +0300
+++ omniorb_41_branch_new/configure.ac	2010-10-13 01:14:17.435865139 +0300
 <at>  <at>  -134,7 +134,7  <at>  <at> 
 OMNI_DISABLE_THREAD_TRACING
 OMNI_DISABLE_IPV6_CHECK
 OMNI_DISABLE_ALLOCA
-
+OMNI_DISABLE_LONGDOUBLE
 
 dnl ** Compiler name
 
diff -Naur omniorb_41_branch_orig/idl/corbaidl.idl omniorb_41_branch_new/idl/corbaidl.idl
--- omniorb_41_branch_orig/idl/corbaidl.idl	2010-10-11 22:43:09.334511122 +0300
+++ omniorb_41_branch_new/idl/corbaidl.idl	2010-10-13 01:13:11.990614981 +0300
 <at>  <at>  -73,9 +73,11  <at>  <at> 
 #endif
   typedef sequence<float>              FloatSeq;
   typedef sequence<double>             DoubleSeq;
+#ifndef DISABLE_LONGDOUBLE
 #ifdef HAS_LongDouble
   typedef sequence<long double>        LongDoubleSeq;
 #endif
+#endif
   typedef sequence<string>             StringSeq;
   typedef sequence<wstring>            WStringSeq;
 
diff -Naur omniorb_41_branch_orig/mk/beforeauto.mk.in omniorb_41_branch_new/mk/beforeauto.mk.in
--- omniorb_41_branch_orig/mk/beforeauto.mk.in	2010-10-13 01:18:36.027617578 +0300
+++ omniorb_41_branch_new/mk/beforeauto.mk.in	2010-10-13 01:47:49.339615274 +0300
 <at>  <at>  -718,6 +718,10  <at>  <at> 
 NoStaticLibrary = 1
 endif
 
+ifeq ( <at> ENABLE_LONGDOUBLE <at> ,no)
+NoLongDouble = 1
+endif
+
 
 ###########################################################################
 #
diff -Naur omniorb_41_branch_orig/src/lib/omniORB/dir.mk omniorb_41_branch_new/src/lib/omniORB/dir.mk
--- omniorb_41_branch_orig/src/lib/omniORB/dir.mk	2010-10-13 01:07:48.069617556 +0300
+++ omniorb_41_branch_new/src/lib/omniORB/dir.mk	2010-10-13 02:02:30.616870659 +0300
 <at>  <at>  -11,6 +11,12  <at>  <at> 
 SUBDIRS += dynamic codesets connections
 endif
 
+ifdef NoLongDouble
+OPT_DISABLE_LONGDOUBLE="-DDISABLE_LONGDOUBLE"
+else
+OPT_DISABLE_LONGDOUBLE=""
+endif
+
 EXPORTHEADERS = omniORB4/distdate.hh \
                 omniORB4/Naming.hh \
                 omniORB4/corbaidl_defs.hh \
 <at>  <at>  -89,7 +95,7  <at>  <at> 
 
 omniORB4/corbaidl_defs.hh omniORB4/corbaidl_operators.hh omniORB4/corbaidl_poa.hh: corbaidl.idl
 	 <at> (dir=omniORB4; $(CreateDir))
-	$(OMNIORB_IDL) -v -nf -P -WbF -ComniORB4 $<
+	$(OMNIORB_IDL) -v -nf -P -WbF -ComniORB4 $(OPT_DISABLE_LONGDOUBLE) $<
 
 omniORB4/boxes_defs.hh omniORB4/boxes_operators.hh omniORB4/boxes_poa.hh: boxes.idl
 	 <at> (dir=omniORB4; $(CreateDir))
_______________________________________________
omniORB-dev mailing list
omniORB-dev <at> omniorb-support.com
http://www.omniorb-support.com/mailman/listinfo/omniorb-dev
Mika Laitio | 11 Oct 2010 21:55
Favicon

autoreconf patch

Hi

I checked out the 4.1 svn branch in order to test crosscompilation for 
mips with openwrt toolchain.

Therefore I wanted to reconfigure everything by running these 3 commands 
from the openwrt makefile. (still working on for creating it)

 	libtoolize --automake --force --copy
 	autoreconf --force --install
 	./configure --prefix=/usr/local

autoreconf command will however give a following error:

configure:4489: error: possibly undefined macro: PKG_CONFIG_LIBDIR
       If this token and others are legitimate, please use 
m4_pattern_allow.
       See the Autoconf documentation.
autoreconf: /usr/bin/autoconf failed with exit status: 1

Attached patch fixes it, would it be possible to apply it?
Note, I noticed a similar type of patch has also been added to 
openembedded by somebody.

Mika

diff -Naur omniorb_41_branch_orig/configure.ac omniorb_41_branch/configure.ac
--- omniorb_41_branch_orig/configure.ac	2010-10-11 22:17:59.552521620 +0300
+++ omniorb_41_branch/configure.ac	2010-10-11 22:18:15.304538752 +0300
 <at>  <at>  -10,6 +10,8  <at>  <at> 
 
 AC_CONFIG_HEADERS(include/omniORB4/acconfig.h)
 
+dnl to prevent error from autoreconf while crosscompiling
+m4_pattern_allow(PKG_CONFIG_LIBDIR)
 
 dnl ** CFLAGS / CXXFLAGS
 
_______________________________________________
omniORB-dev mailing list
omniORB-dev <at> omniorb-support.com
http://www.omniorb-support.com/mailman/listinfo/omniorb-dev
Christoph Becker | 1 Oct 2010 16:29

Suspicious omnithread problem

Hi,

my program got a core dump with signal 11  <at>  omnithread lib. But I
don't know why:

#0  0x084baca9 in virtual thunk to
CosNotifyChannelAdmin::_impl_SupplierAdmin::_dispatch(omniCallHandle&)
() at /usr/include/omnithread.h:648
648	static omni_thread::init_t omni_thread_init;

Any idea?

Cheers,
 Christoph
Floris Bruynooghe | 8 Aug 2010 15:44
Picon
Gravatar

Linking libCOS against libomniDynamic on all platforms

Hi

Attached is the patch I've made in Debian to link libCOS with
libomniDynamic and link libCOSDynamic with libCOS (in version 4.1.4).
Both these libraries use symbols from these libraries however the
default UNIX build did not bother resolving them because (I presume)
any application using them would be linking against these libs anyway.

Both AIX and Cygwin linkers where not happy with this and had
exceptions added to them however.  But it also turns out that the new
GOLD linker in GNU binutils is not too happy with leaving these
symbols not resolved either (though it's not a hard failure), see
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=558942.

So the attached patch does add the linking by default to any UNIX
platform.  Do you have any comments on this?  Is this a very bad idea
or is this something you'd accept upstream?  Is there a better way of
doing this?

Thanks
Floris

-- 
Debian GNU/Linux -- The Power of Freedom
www.debian.org | www.gnu.org | www.kernel.org
--- a/src/services/mklib/dir.mk
+++ b/src/services/mklib/dir.mk
 <at>  <at>  -121,13 +121,17  <at>  <at> 
 dynimps := $(skshared) $(patsubst $(DLLDebugSearchPattern),$(DLLNoDebugSearchPattern), \
          $(OMNIORB_LIB))
 else
-imps := $(OMNIORB_LIB_NODYN)
-dynimps := $(OMNIORB_LIB)
+# Link COS with omniDynamic and COSDynamic with COS so all symbols are
+# resolved at link time.  Leaving symbols unresolved is ok for the normal
+# GNU and SysV linkers but not for more restrictive linkers like GOLD.
+# $(soext) is used in the $(skshared) target.
+soext := $(OMNIORB_MAJOR_VERSION).so.$(OMNIORB_MINOR_VERSION).$(OMNIORB_MICRO_VERSION)
+imps := $(OMNIORB_LIB_NODYN) -lomniDynamic$(OMNIORB_MAJOR_VERSION)
+dynimps := $(OMNIORB_LIB) -Lshared -lCOS$(OMNIORB_MAJOR_VERSION)
 endif

 ifdef AIX
-# AIX thinks the skeleton stubs depend on omniDynamic and also that
-# COSDynamic depends on COS.
+# AIX has special library names.
 oov = $(OMNIORB_MAJOR_VERSION)$(OMNIORB_MINOR_VERSION)
 oovm = $(oov)$(OMNIORB_MICRO_VERSION)
 imps := -lomniORB$(oov) -lomniDynamic$(oov) $(OMNITHREAD_LIB)
 <at>  <at>  -149,8 +153,9  <at>  <at> 
 $(skshared): $(patsubst %, shared/%, $(COS_SK_OBJS))
 	 <at> (namespec="$(sknamespec)"; extralibs="$(imps) $(extralibs)"; \
          $(MakeCXXSharedLibrary))
+	ln -s libCOS$(soext) shared/libCOS$(OMNIORB_MAJOR_VERSION).so

-$(dynskshared): $(patsubst %, shared/%, $(COS_DYNSK_OBJS))
+$(dynskshared): $(skshared) $(patsubst %, shared/%, $(COS_DYNSK_OBJS))
 	 <at> (namespec="$(dynsknamespec)"; extralibs="$(dynimps)"; \
          $(MakeCXXSharedLibrary))

_______________________________________________
omniORB-dev mailing list
omniORB-dev <at> omniorb-support.com
http://www.omniorb-support.com/mailman/listinfo/omniorb-dev
Haitham | 3 Aug 2010 20:29
Picon

Modify omniORB to use blocking connect only


Hi, 

I am trying to modify the implementation of omniORB so that it will use
blocking socket connect only, I modified the tcpAddress.c file but I am
still getting "Failed to set socket to non-blocking mode: " from the trace
file, my question is, is there any other place that I need to modify?

Regards
--Haitham
--

-- 
View this message in context: http://old.nabble.com/Modify-omniORB-to-use-blocking-connect-only-tp29338626p29338626.html
Sent from the OmniORB - Dev mailing list archive at Nabble.com.

Gmane