freedce-dcomdev — Discussions about developing the DCOM aspect of FreeDCE

Re: [FreeDCE-DCOMdev] Hello, and first question

[<to...@tu...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hello all,

I'm new on this list and (of course :) already with the first question:

A customer (with whom I have been implementing building control
applications) has asked me whether we can interface to OPC. Some
research led me to [1] and thus to OLE, COM and DCOM.

Since I don't Windows [2], I stumbled upon your project. I know very
little about COM/DCOM ald all that (the last programs I wrote on Windows
platforms were for DDE, that was about Windows 3.1 era :) I ask you:

Do I have a fighting chance of implementing something like an OPC
interface on top of freedce/dcom? Or should I leave this to the Windows
folks?

- ----------------------------------------------------------------------
[1] <http://en.wikipedia.org/wiki/OLE_for_process_control>
[2] Our server runs on GNU/Linux. The client workstations are Windows,
    but that is not my domain :)

Regards
- -- tomás
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFGieV/Bcgs9XrR2kYRAgffAJ9+o+r8tCXAgk+RtYOcTTCWB/5+iwCdHAqS
qF7eM9wQUk0jNdZqEUG6q0g=
=jW2m
-----END PGP SIGNATURE-----

Re: [FreeDCE-DCOMdev] now convulsiv

[Krysten F. <co...@sa...>]

Hi,

VIxAGxRA $3. 35
CIxALxIS $3. 75
VAxLIxUM $1. 30
AMxBIxEN $2. 90
SOxMA    $1. 15

and many other

http://www.rx555*com ( Do not forget to replace "*" with "." )

--
What do they think theyre doing, annoying senior Ministry members? 
Percy hissed, watching Fred and George suspiciously. No respect... 
Ludo Bagman shook off Fred and George fairly quickly, however, and,

Re: [FreeDCE-DCOMdev] dcom

[Thomas <Tho...@we...>]

Hello Marcel, 

you can use FreeDCE for DCE-RPC communication. There is an example 
application. Have a look at the demos (echo-server/client in freedce/demos/).

There are also some books about DCE:
"Understanding DCE" ISBN: 1-56592-005-8
"Guide to Writing DCE Applications" ISBN: 1565920457

kind regards,
Thomas

On Friday 27 May 2005 17:55, Marcel Vale wrote:
> Dear sir madame,
>
> I have downloaded the linux-dcerpc-1.1.tar.bz2 in order to implement
> DCOM. How can I use this? Are there already some programming examples?
> I tried to download the document rpc-internals.pdf but this is not
> accessable.
>
> Best regards,
>
> Marcel Vale
>
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by Yahoo.
> Introducing Yahoo! Search Developer Network - Create apps using Yahoo!
> Search APIs Find out how you can build Yahoo! directly into your own
> Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005
> _______________________________________________
> FreeDCE-DCOMdev mailing list
> Fre...@li...
> https://lists.sourceforge.net/lists/listinfo/freedce-dcomdev

[FreeDCE-DCOMdev] dcom

[Marcel V. <m....@tr...>]

Dear sir madame,

I have downloaded the linux-dcerpc-1.1.tar.bz2 in order to implement
DCOM. How can I use this? Are there already some programming examples?
I tried to download the document rpc-internals.pdf but this is not
accessable.

Best regards,

Marcel Vale

[FreeDCE-DCOMdev] patches for freedce cvs - not for faint-hearted [NTLMSSP, MSRPC]

[Luke K. C. L. <lk...@lk...>]

loic, freedce'ers, opendce'ers, samba-tng'ers and samba-tech'ers, hi,

okay this is from some stuff i have had kicking about since 2001.
i'm relaying it here for people who may be interested.

basically it revives freedce to the point where it is almost actually
useful for development work as an MSRPC-compatible development
environment.

the only issues to resolve to make a usefulrelease: out-sourcing
of authentication to some sort of NT Domain Clone authentication
server, and making the "Named Pipes" transport inherit the
authentication context.

FUNDING FOR THIS STRATEGICALLY IMPORTANT PROJECT WOULD HELP LOTS OF PEOPLE.


patches are obtainable at http://hands.com:~lkcl

freedce-patch.txt and ncklib-auth.tgz.

it's patches against freedce.sf.net cvs main, _not_ the dce-rpc 1.1
release just made by loic last month.

therefore, some of the issues (like --enable-dcom or --disable-dcom)
_may_ have been fixed in that release - but not in freedce cvs main.

merging the dce-rpc 1.1 release into cvs main is going to take
time, expertise and effort that at present is not available.


if i had cvs access to freedce.sf.net, this would be the cvs commit
message:

1) adding expression so that size_is( data_len / 2) and
   length_is( (data_len + 7) & ~7) etc. will work *gibber*

   it's not my code, i can't recall where it came from.

   it is essential for both dcom and MSRPC interoperability.

   the /2 is essential for correctly transferring UCS-2 unicode
   strings.

   the 8-byte aligmnent is essential for dcom in transferring
   data blobs.

   apparently.

2) adding gss-api auth.  again - no clue where it comes from.

3) adding ntlmssp auth.  this is mine, but is now "public domain",
   at least the bits of it that _are_ mine are public domain (e.g.
   excluding the smbdes.c code etc.)

   it's hardcoded to workgroup WORKGROUP, principle name HIGHFIELD,
   username TEST and password TEST.
   
   once there exists client-side library implementing the NETLOGON api,
   (which is a trivial couple-of-days job _if_ access to the
   netlogon.idl file is available) then this plugin will of course have
   an easy mechanism to be able to do "outsourced" authentication.

   if anyone can think of a better way to do this, please say so.

   e.g. would it be better to bounce the authentication off to winbindd?

   e.g. revive pam_ntdom?

   e.g. write a simple special interface (root-only-accessible) that sends domain+user+pass?

   e.g. write an IDL file, create a service (which needs to be
   root-only accessible) that does the above?

   etc.

4) correcting AUTH3 pdu problems, client-side.

   this is a little scary because i really don't have a clue as to how
   the state machine really works: i can only guess.

   i've made three simple changes, the exact implications of
   which i can only guess at, and all i can say is "they seem
   to work".

   you know the difference between amateur and professional: amateur is
   happy it worked once, professional is happy it never fails.

   well, this is "amateur" and i am _very_ happy :)

   ... but, like all open source, it's good enough for "first version".

5) removing dcom *AGAIN* because it's not properly / totally
   autoconf'd and doesn't compile properly in cvs main with either
   --enable-dcom _or_ --disable-dcom.

6) updating uuid-gen which appears to now have a g++ stl compile-related
   error.

7) removing *AGAIN* the defaults which make dceidl stop everything from
   compiling without warnings (g++ is the default instead of gcc)

   this really needs to be dealt with properly by giving dceidl
   a "-cpp" argument which is used in Makefiles where it is
   needed, rather than being the default behaviour.

   if it hasn't already.
   
   i haven't really checked to be honest: as you are no doubt aware,
   i'm in "get it working" mode.

8) adding in a couple of essential - but hard-coded - name service
   resolutions into what would otherwise be a "dummy" DCE library.

   these are the points at which the DCE 1.2.2 code would add "real"
   functionality.

   except that the DCE 1.2.2 code would add "real" DCE-related
   functionality - it wouldn't add MSRPC/WINS resolver functionality,
   which this [unattributed] patch _does_ add even if not very well.

   oops :)

9) yaccisms.  yukk :)  now compiles with flex 2.5.X series.

10) adding "implicit handles" to the IDL syntax, which are presently
    missing.  these are ESSENTIAL.

	and i can't remember who added it.

11) disabled atfork because you can guarantee a crash if you
    don't disable it.



when i say "can't remember", it's been four years, and the
only other two people i remember who worked on this were Wez
Furlong and Luke Howard.



build prerequisites are:

- patience.

- autoconf 2.13 NOT 2.5whatever.

  [debianites: apt-get install autoconf2.13]

- dce-rpc 1.1 dcethreads library released last month on
  http://sf.net/projects/freedce, but you MUST export
  LD_ASSUME_KERNEL=2.4.19 if you are using a 2.6 kernel.

  i _do_ have a badly-fixed freedce dcethreads library -
  which doesn't entirely work either (passes tests 1 and 2) -
  which doesn't suffer from the "atfork" segfault problem that
  the dce-rpc 1.1 dcethreads library does (test_atfork1 doesn't
  compile), but it _does_ suffer from some other exception
  handling issues, but it passes enough of the tests in the
  dcethreads suite to actually be useable.

  just :)

  anyone interested in using hacked code, let me know, i can
  prepare a patch :)

- samba TNG built with ./configure.nonpsec.developer because
  this DISABLES the security-context transfer mechanism of
  the "Named Pipe" outsourcing system in samba-tng, which is
  presently NOT implemented in freedce.

  yet.

  so, for those people who have been following the tng-technical
  discussions between myself and jelmer, the semantics of
  freedce's "Named Pipe" system are at present identical to
  samba 4's "ncalrpc" transport NOT the samba-tng's "ncalrpc"
  transport, and consequently you must build samba-tng with
  ./configure.nonpsec.developer to give it [effectively]
  the same semantics as samba 4's "ncalrpc" transport.

- on termination of a service (e.g. rpcd) you must MANUALLY delete
  /usr/local/samba/var/locks/.msrpc/<the endpoint mapper socket name>
  before restarting the service.

  yes, i know.

  it's due to the way that unix domain sockets work, and that the
  FreeDCE code ncalrpc implementation uses the standard BSD transport
  as a temporary hack.  this obviously has to change.

  any advice here greatly appreciated.
  
  l.

-- 
--
<a href="http://lkcl.net">http://lkcl.net</a>
--

Re: [FreeDCE-DCOMdev] Freedce releases ...

[Wez F. <we...@th...>]

freedce is under a free-for-any-use-don't-blame-us-if-it-breaks
OSF license (check out the source for details).

However, it depends on dcethreads which is under a GPL license,
which effectively promotes freedce to GPL too (and your application).

You can purchase the real DCE stuff from the OSF if you have
a LOT of $$$, but note that they are very slowly moving towards
licensing it under the GPL too; check out opendce.org.
Both of these options require porting to linux.

Now, when it comes to the GPL, you would normally run for the
hills, but since the interface is an open standard, you should
be safe to link any code you like to freedce and not be tainted
by the GPL--other vendors have the same library with the same
interface available, so you don't solely depend on the GPL'd
code.

If you fix/port dcethreads to your platform, you would still
need to "make available on request" the source for that part
if you distribute your code.

--Wez.

----- Original Message ----- 
From: Eric Laplace <erl>
To: fre...@li...
Cc: erl
Sent: Tuesday, April 20, 2004 5:48 PM
Subject: [FreeDCE-DCOMdev] Freedce releases ...


Hi,

I'm trying to find a DCE RPC implementation that runs on LynOs RTOS from
LinuxWorks.
It proposes only POSIX thread library (none the linux thread library).

here after are questions I'm wondering:

General questions:

1) What  freeDCE package can we use (for commercial purpose) ?
2) What is the exact License terms of freeDCE package(s)  (reading the
COPYING / README files of version (1.1.0.7)  I'm still have doubts) ?
3) If not free, where/how can we obtain a price sheet ?


Technical questions:

4) It seems that freeDCE relies on a DCEthread Library. Do you confirm this?
5) Since that DCEThread Libray/package is not free for commercial use;
    so, is there an other way to make a complete freeDCE package (freeDCE+
POSIX thread support) ?
6) Can you confirm that DCEthread interface belongs to Public Domain?


Thanks by advance.
kind regards


___________________________________________________________
              Eric LAPLACE                           R&D
E-Mail : er...@oc...                          Océ Print Logic Technologies
tel        : 33-01-48-98-81-00                1 , rue Jean Lemoine
fax       : 33-01-48 98 54 50                94015 Créteil cedex France
___________________________________________________________

[FreeDCE-DCOMdev] Freedce releases ...

[Eric L. <erl> <er...@oc...>]

Hi,

I'm trying to find a DCE RPC implementation that runs on LynOs RTOS from =
LinuxWorks.
It proposes only POSIX thread library (none the linux thread library).

here after are questions I'm wondering:

General questions:

1) What  freeDCE package can we use (for commercial purpose) ?
2) What is the exact License terms of freeDCE package(s)  (reading the =
COPYING / README files of version (1.1.0.7)  I'm still have doubts) ?
3) If not free, where/how can we obtain a price sheet ?


Technical questions:

4) It seems that freeDCE relies on a DCEthread Library. Do you confirm =
this?
5) Since that DCEThread Libray/package is not free for commercial use;
    so, is there an other way to make a complete freeDCE package =
(freeDCE+ POSIX thread support) ?
6) Can you confirm that DCEthread interface belongs to Public Domain?


Thanks by advance.
kind regards


___________________________________________________________
              Eric LAPLACE                           R&D     =20
E-Mail : er...@oc...                          Oc=E9 Print Logic =
Technologies=20
tel        : 33-01-48-98-81-00                1 , rue Jean Lemoine
fax       : 33-01-48 98 54 50                94015 Cr=E9teil cedex =
France               =20
___________________________________________________________

[FreeDCE-DCOMdev] Please help me

[Zsido J. <Zs...@ko...>]

Hi everyone, 
    When trying to compile/configure the FreeDCE-1.1.0.7 there is a
    request for the dcethreads:
	configure: error: freedce requires libdcethreads!
    ok, but when I want to configure libdcethreads, i have problems again.
(dcethreads-2.0.2)
	./configure runs without errors, but at make I got the following
	problems:
pthread_dceexc.c: In function `pthd4exc_join':
pthread_dceexc.c:265: pointers are not permitted as case values
pthread_dceexc.c: In function `pthd4exc_mutexattr_create':
pthread_dceexc.c:293: warning: concatenation of string literals with 
__FUNCTION__ is deprecated
    The last two lines ( just like) appears many times
    I saw that warnings are treated as errors.
    There was a warning because the compiler couldn't find the prototype
    of abort() function, so I added a prototype in that file, this problem 
seems solved.
	

        May be my system configurations wrong, my compiler incompatible?
    I have a Linux RedHat 9.
    gcc version 3.2.2 20030222 (Red Hat Linux 3.2.2-5)

    I hope this information is enoungh to send me a little help.
    Will be useful also if you send me some URL's where I can get
    some informations about FreeDCE

Thank you, ZsJoska.

______________________________________________________________________
Do you want a free e-mail for life ? Get it at http://www.kolozsvar.ro/

[FreeDCE-DCOMdev] DCEThreads Problem

[Manikandan MJ <man...@vi...>]

Hi All,

I've tried to install the latest version of the FreeDCE on Linux Red Hat 7.0
and i'm facing the following problems.
I am not able to install DceThreads Library due to some reasons. Has anyone
tried to install and got it installed succesfully? Pls reply.

Thanx and Rgds
Mani

[FreeDCE-DCOMdev] (no subject)

[Marinela P. <mar...@si...>]

subscribe

Re: [FreeDCE-DCOMdev] Support of MIDL

[Wez F. <we...@th...>]

Hi James,

The FreeDCE idl compiler needs modifying to be able to fully support
the microsoft extensions.
There has been some work done on this, but currently everyone is too
busy with other work to finish the job.

Sorry,

--Wez.

On 07/30/02, "James Michael DuPont" <mdu...@ya...> wrote:
> Dear All,
> 
> I wanted to know if you have tried compiling 
> Microsoft IDL with OpenDCE? 
> 
> Thanks,
> 
> Mike
> 
> 
> =====
> James Michael DuPont
> http://introspector.sourceforge.net/
> 
> __________________________________________________
> Do You Yahoo!?
> Yahoo! Health - Feel better, live better
> http://health.yahoo.com
> 
> 
> -------------------------------------------------------
> This sf.net email is sponsored by: Dice - The leading online job board
> for high-tech professionals. Search and apply for tech jobs today!
> http://seeker.dice.com/seeker.epl?rel_code=31
> _______________________________________________
> FreeDCE-DCOMdev mailing list
> Fre...@li...
> https://lists.sourceforge.net/lists/listinfo/freedce-dcomdev

[FreeDCE-DCOMdev] Support of MIDL

[James M. D. <mdu...@ya...>]

Dear All,

I wanted to know if you have tried compiling 
Microsoft IDL with OpenDCE? 

Thanks,

Mike


=====
James Michael DuPont
http://introspector.sourceforge.net/

__________________________________________________
Do You Yahoo!?
Yahoo! Health - Feel better, live better
http://health.yahoo.com

[FreeDCE-DCOMdev] global variables declaration

[isaac p. <vs...@ac...>]

SUBJECT:  [FreeDCE-DCOMdev] global variables declaration 

Hello,

i have looke on the source code , and could not find the declaration of the
3 global variables :
mgmt_v1_0_c_epv , mgmt_v1_0_c_ifspec , mgmt_v1_0_s_ifspec.

1. what module is responsible of those global declarations.

2. are they part of the rpcd daemon ?

Thanks in advance .

Mr Isaac Perez

Mr Isaac Perez

[FreeDCE-DCOMdev] global variables declaration

[isaac p. <vs...@ac...>]

Hello,

i have looke on the source code , and could not find the declaration of the
3 global variables :
mgmt_v1_0_c_epv , mgmt_v1_0_c_ifspec , mgmt_v1_0_s_ifspec.

1. what module is responsible of those global declarations.

2. are they part of the rpcd daemon ?

Thanks in advance .

Mr Isaac Perez

[FreeDCE-DCOMdev] global variable declaration...

[isaac p. <vs...@ac...>]

Hello,

i have looke on the source code , and could not find the declaration of the
3 global variables :
mgmt_v1_0_c_epv , mgmt_v1_0_c_ifspec , mgmt_v1_0_s_ifspec.

1. what module is responsible of those global declarations.

2. are they part of the rpcd daemon ?

Thanks in advance .

Mr Isaac Perez

[FreeDCE-DCOMdev] Project status ?

[Yann D. <yd...@fr...>]

I see no sign of activity here since July 2001.  Is this project dead ?
Does anyone know of recent activity on the DCE codebase ?

-- 
Yann Dirson <Yan...@fr...>                 http://www.alcove.com/
Technical support manager                Responsable de l'assistance technique
Senior Free-Software Consultant          Consultant senior en Logiciels Libres
Debian developer (di...@de...)                        Développeur Debian

RE: [FreeDCE-DCOMdev] DCOM/OPC implementation

[Wez F. <we...@th...>]

Hi Todd,

The DCOM part of FreeDCE still needs all of the in-process COM code as a
base, before it can be implemented fully.

A new project has very recently been set up on sourceforge, called OpenCOM
and we will be working with them to this end - but there is quite a way to
go.

This sounds like bad news for you, but you might be able to get away with
using the DCE only side of things, provided that you will only ever be
talking across a network with those devices, and that your Linux code will
only ever be a client.  If that sounds right for you, check out this
article: http://www.idevresource.com/com/library/articles/comonlinux.zip

Good luck!

--Wez.



>  Hi.
>
> I have recently begun working on a new project at work that
> involves writing
> OPC servers.  OPC (OLE for Process Control), is a specific set of COM/DCOM
> interfaces that are designed for inter-device communication for
> manufacturing systems.  The specs are available at
> http://www.opcfoundation.org.
>
> I've been programming for Linux for years, and am not looking forward to
> having to develop a large amount of software under Windows.  The
> majority of
> my team feels likewise.  However, the devices with which we have to
> communicate only seem to support OPC as an interface, and while we did
> discover there is a commercial product available that provides OPC
> functionality under Linux, it is not open source, requires
> runtime licensing
> fees, is only compatible with certain kernel versions, and has some other
> drawbacks.
>
> What we need is really an open source implementation of DCOM, and that led
> me to discover FreeDCE.  There haven't been any recent posts concerning
> DCOM, so I thought I would ask:  What is the current state of DCOM
> implementation in FreeDCE, and what can I do to help?
>
> _______________________________________________
> FreeDCE-DCOMdev mailing list
> Fre...@li...
> http://lists.sourceforge.net/lists/listinfo/freedce-dcomdev
>
>

[FreeDCE-DCOMdev] DCOM/OPC implementation

[Moyer, T. (TMOYER) <TM...@ar...>]

 Hi.

I have recently begun working on a new project at work that involves writing
OPC servers.  OPC (OLE for Process Control), is a specific set of COM/DCOM
interfaces that are designed for inter-device communication for
manufacturing systems.  The specs are available at
http://www.opcfoundation.org.

I've been programming for Linux for years, and am not looking forward to
having to develop a large amount of software under Windows.  The majority of
my team feels likewise.  However, the devices with which we have to
communicate only seem to support OPC as an interface, and while we did
discover there is a commercial product available that provides OPC
functionality under Linux, it is not open source, requires runtime licensing
fees, is only compatible with certain kernel versions, and has some other
drawbacks.

What we need is really an open source implementation of DCOM, and that led
me to discover FreeDCE.  There haven't been any recent posts concerning
DCOM, so I thought I would ask:  What is the current state of DCOM
implementation in FreeDCE, and what can I do to help?

[FreeDCE-DCOMdev] Re: FreeDCE compilation on Mandrake Linux

[Wez F. <we...@th...>]

Paul-Andre Panon:
> I have been experiencing some compilation
> problems on Linux Mandrake 7.0 and
> 7.1. I haven't tried with 7.2 yet.
> ... patch for Makefile.in included ...

I've retrieved the patch from the archives.
For some reason I didn't receive your message via the mailing list.

I aim to take a look at it, (and other patches) some time today.

--Wez.

[FreeDCE-DCOMdev] FreeDCE compilation on Mandrake Linux

[Panon, Paul-A. <Pau...@Si...>]

I have been experiencing some compilation problems on Linux Mandrake 7.0 and
7.1. I haven't tried with 7.2 yet.
The bison and other components work fine. The problem seems to be with the
c++ compiler when compiling c++ modules in the uuid directory. The problem
is that these versions of Mandrake (and maybe Redhat too?) don't seem to use
the include path for the new c++ includes for egcs. Those are only available
under the "compat-..." forms of the command:

$ gcc -v
Reading specs from /usr/lib/gcc-lib/i586-mandrake-linux/2.95.3/specs
gcc version 2.95.3 19991030 (prerelease)

$ compat-egcs -v
Reading specs from /usr/lib/gcc-lib/i586-mandrake-linux/egcs-2.91.66/specs
gcc driver version 2.95.3 19991030 (prerelease) executing gcc version
egcs-2.91.66 

$ g++ -v
Reading specs from /usr/lib/gcc-lib/i586-mandrake-linux/2.95.3/specs
gcc version 2.95.3 19991030 (prerelease)

$ compat-egcs++ -v
Reading specs from /usr/lib/gcc-lib/i586-mandrake-linux/egcs-2.91.66/specs
gcc driver version 2.95.3 19991030 (prerelease) executing gcc version
egcs-2.91.66

I am not sure how I would get autoconf or configure to identify that it is
supposed to use the compat-* compilers.
In the meantime, I have hacked the uuid Makefile.in to have the following
change

--- Makefile.in Wed Mar  7 13:40:17 2001
+++ Makefile.in.bak     Wed Mar  7 13:38:18 2001
@@ -91,7 +91,6 @@

 CFLAGS = -g -Wall -W -O -pipe -Werror
 INCLUDES =  $(dce_includes)
-CXXINCLUDES =

 SUFFIXES = .idl

@@ -132,8 +131,8 @@
 uuid_DEPENDENCIES =  libuuid.la
 uuid_LDFLAGS =
 CXXFLAGS = @CXXFLAGS@
-CXXCOMPILE = $(CXX) $(DEFS) $(INCLUDES) $(CXXINCLUDES) $(AM_CPPFLAGS)
$(CPPFLAGS) $(AM_CXXFLAGS) $(CXXFLAGS)
-LTCXXCOMPILE = $(LIBTOOL) --mode=compile $(CXX) $(DEFS) $(INCLUDES)
$(CXXINCLUDES) $(AM_CPPFLAGS) $(CPPFLAGS) $(AM_CXXFLAGS) $(CXXFLAGS)
+CXXCOMPILE = $(CXX) $(DEFS) $(INCLUDES) $(AM_CPPFLAGS) $(CPPFLAGS)
$(AM_CXXFLAGS) $(CXXFLAGS)
+LTCXXCOMPILE = $(LIBTOOL) --mode=compile $(CXX) $(DEFS) $(INCLUDES)
$(AM_CPPFLAGS) $(CPPFLAGS) $(AM_CXXFLAGS) $(CXXFLAGS)
 CXXLD = $(CXX)
 CXXLINK = $(LIBTOOL) --mode=link $(CXXLD) $(AM_CXXFLAGS) $(CXXFLAGS)
$(LDFLAGS) -o $@
 COMPILE = $(CC) $(DEFS) $(INCLUDES) $(AM_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS)
$(CFLAGS)

and pass the CXXINCLUDES path on the make command line.  

Paul-Andre Panon
Sierra Systems
1177 West Hastings Street, Suite 2500
Vancouver, BC  V6E 2K3
Main: 604.688.1371
Fax:  604.688.6482
www.SierraSystems.com

RE: [FreeDCE-DCOMdev] FreeDCE compliation fail. Help.

[Wez F. <we...@th...>]

On 2001-03-02 04:57:26, <jj...@th...> wrote:
> I, finally, succeeded in compling FreeDCE in my Linux box.
> I modified some files in 'idl' directory as follow : 

> Before:
> CFLAGS = -g -Wall -W -O -pipe -Werror -DMIA
> After:
> CFLAGS = -g -Wall -W -O -pipe -DMIA

The -Werror flag is to ensure that the code builds without warnings
(it promotes warnings to errors).
I think maybe we should add a configure option to relax this flag if
people are having problems with it.
 
> Before:
> find_rule:  __attribute__((__unused__))  /* we branch to this label
> when backing up */  
> After 
> find_rule:  /*  we branch to this label when backing up */  

__attribute__ is a gcc extension, but for some reason it seemed to be the
cause of your problem, even though you are using gcc.
 
> I downloaded latest CVS version and , I guess, 
> some version mismatch of complier or something on my Linux box with
> yours
> caused the problem..... 

Did you successfully compile the latest CVS version without having to
make the changes above?

If not, please let me see the exact error messages - I need to know so
that I can account for it in our configure process.
 
> Now I have ported my dce application running on HP-UX to Linux platform 
> and I am testing it now. Hope it works...

In theory it should - the codebase is of mature status.
 
--Wez.

RE: [FreeDCE-DCOMdev] FreeDCE compliation fail. Help.

[<jj...@th...>]

Hi, Wez!!
After a few days of struggling with compling problem, 
I, finally, succeeded in compling FreeDCE in my Linux box.

I'd like to tell you how...
I modified some files in 'idl' directory as follow : 

(1) idl/Makefile
Line 90 
Before:
CFLAGS = -g -Wall -W -O -pipe -Werror -DMIA

After:
CFLAGS = -g -Wall -W -O -pipe -DMIA

(2) idl/acf_l.c (result of FLEXing acf_l.l) 
Line 775 
Before:
find_rule:  __attribute__((__unused__))  /* we branch to this label
when backing up */  

After 
find_rule:  /*  we branch to this label when backing up */  

(3) idl/nidl_l.c (result of FLEXing nidl_l.l)
Line 1003
Before:
find_rule:  __attribute__((__unused__))  /* we branch to this label
when backing up */  

After 
find_rule:  /*  we branch to this label when backing up */  

Then every thing went ok!!

I downloaded latest CVS version and , I guess, 
some version mismatch of complier or something on my Linux box with
yours
caused the problem..... 

Now I have ported my dce application running on HP-UX to Linux platform 
and I am testing it now. Hope it works...

Thanks.

-----Original Message-----
From: Wez Furlong [mailto:we...@th...]
Sent: Thursday, March 01, 2001 4:04 AM
To: jj...@th...
Cc: fre...@li...
Subject: Re: [FreeDCE-DCOMdev] FreeDCE compliation fail. Help.


On 2001-02-28 06:08:15, <jj...@th...> wrote:
> I succeeded in DceThreads compilation but could not compile FreeDCE in
> my Linux box.
> The 'acf_l.c' file which is a result of FLEXing 'acf_l.l' file in
'idl'
> directory caused the problem.
> I downloaded the cvs repository and compiled the source, but the same
> result. (acf_l.c caused the same problem)

I cannot reproduce the problem.
Please checkout the latest CVS version and try that (some build issues
were fixed, but none directly related to acf_l.l.
 
> $ uname -a
> Linux se 2.2.15 #1 Mon Jun 5 19:35:24 KST 2000 i686 unknown
> $ gcc -v
> Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/egcs-
2.91.66/specs
> gcc version egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)
> $ flex -V
> flex version 2.5.4

Just for the sake of being complete what about:

$ bison -V

and also the configure command you used, and the error messages
from the compiler.

--Wez.


_______________________________________________
FreeDCE-DCOMdev mailing list
Fre...@li...
http://lists.sourceforge.net/lists/listinfo/freedce-dcomdev

Re: [FreeDCE-DCOMdev] Status of FreeDCE

[Wez F. <we...@th...>]

Sorry that I have been "idle" lately; many many other things have been
occupying my time.

On 2001-02-15 22:07:22, "Eric Bresie" <eb...@us...> wrote:
> Hey guys...I was just curious what the status of the Free DCE project is?

The status is officially this:
The FreeDCE code compiles, builds and runs and is considered mature code.

The DCOM stuff is in very early development, but has not been moving very
fast at all lately.  It's mostly conceptual at this time.

> The RMC on Sourceforge has been trying to work with it and seem to
> continually have problems with compiling it.

RMC?
I'm guessing remote method call, but I'm not sure if that makes sense... ;-)
 
> I was having problems compiling it with the buildconf continually saying
> that I had dcethreads when (at the time) I had not even installed that
> component, which in turn caused the DCETHREADINCLUDE variable to be set to
> "not required" which was used as -Inot required which caused an error when
> compiling the idl portion.  This is probably some OS/Compiler environment
> problem on my end, but I am always interested for more info.

Can you try the latest CVS; I have recenly applied a patch that seems like
it will fix most peoples problems?

If you run into problems let me know more about your build environment and
the problems you encounter.
 
--Wez.

Re: [FreeDCE-DCOMdev] FreeDCE compliation fail. Help.

[Wez F. <we...@th...>]

On 2001-02-28 06:08:15, <jj...@th...> wrote:
> I succeeded in DceThreads compilation but could not compile FreeDCE in
> my Linux box.
> The 'acf_l.c' file which is a result of FLEXing 'acf_l.l' file in 'idl'
> directory caused the problem.
> I downloaded the cvs repository and compiled the source, but the same
> result. (acf_l.c caused the same problem)

I cannot reproduce the problem.
Please checkout the latest CVS version and try that (some build issues
were fixed, but none directly related to acf_l.l.
 
> $ uname -a
> Linux se 2.2.15 #1 Mon Jun 5 19:35:24 KST 2000 i686 unknown
> $ gcc -v
> Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/egcs-2.91.66/specs
> gcc version egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)
> $ flex -V
> flex version 2.5.4

Just for the sake of being complete what about:

$ bison -V

and also the configure command you used, and the error messages
from the compiler.

--Wez.

[FreeDCE-DCOMdev] FreeDCE compliation fail. Help.

[<jj...@th...>]

Hello.

I would like to get some help from you.
My company has a plan to use FreeDCE as a base middleware platform in
out internet service. 
I downloaded tarball of FreeDCE and DceThreads from sourceforge.

I succeeded in DceThreads compilation but could not compile FreeDCE in
my Linux box.
The 'acf_l.c' file which is a result of FLEXing 'acf_l.l' file in 'idl'
directory caused the problem.
I downloaded the cvs repository and compiled the source, but the same
result. (acf_l.c caused the same problem)

The environment of my Linux Box follows:

$ uname -a
Linux se 2.2.15 #1 Mon Jun 5 19:35:24 KST 2000 i686 unknown

$ gcc -v
Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/egcs-2.91.66/specs
gcc version egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)

$ flex -V
flex version 2.5.4

Thanks in advance.

=================================================
Jongjin Choi
Thinkware Systems Corporation (http://www.thinkwaresys.com)
e-mail : jj...@th...
Tel(office): +82-2-571-9162 (222)
ICQ : 76009376
=================================================