xplc-general — General discussion on XPLC

[xplc-general] [ xplc-Patches-3135553 ] build failure with --as-needed

[SourceForge.net <no...@so...>]

Patches item #3135553, was opened at 2010-12-12 05:15
Message generated for change (Tracker Item Submitted) made by sistpoty
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=301814&aid=3135553&group_id=1814

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Stefan Potyra (sistpoty)
Assigned to: Nobody/Anonymous (nobody)
Summary: build failure with --as-needed

Initial Comment:
Hi,

attached is a patch which solves a build failure with the linker flag --as-needed. Some background: --as-needed forces the order of libraries, which means that a shared object using symbols must occur on as argument to the linker in front of the file providing the symbol definitions. For xplc it's -ldl that is added in front of libxplc.so.

In the attached patch, I've updated config/rules.mk to allow to specify libraries in <name>_LDADD (automake uses the same convention), and have updated xplc/vars.mk to use libxplc_LDADD in case the libdl is to be used. Would be cool if you could integrate that patch. If there's s.th. wrong with the approach, please let me know.

Cheers,
   Stefan.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=301814&aid=3135553&group_id=1814

[xplc-general] [ xplc-Bugs-1875310 ] xplc over writes uuidgen provided by e2fsprogs

[SourceForge.net <no...@so...>]

Bugs item #1875310, was opened at 2008-01-19 09:26
Message generated for change (Comment added) made by stumbles
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=101814&aid=1875310&group_id=1814

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Dennis  (stumbles)
Assigned to: Nobody/Anonymous (nobody)
Summary: xplc over writes uuidgen provided by e2fsprogs

Initial Comment:
As the summary indicates there is a conflict of sorts between xplc and e2fsprogs. AFAIK most linux boxes will already have e2fsprogs installed which means uuidgen will already be present. I think over righting a system file such as this could cause a person to go down a false troubleshooting path, not to mention IMHO such over righting is a bit um, rude.

I don't know just how different xplc uses its version of uuidgen but would it not be better to use the one provided by e2fsprogs?

In any event, if the xplc version of uuidgen must be kept would it be to much trouble to rename it so as not to conflict with an existing system file?

Thanks. 

----------------------------------------------------------------------

>Comment By: Dennis  (stumbles)
Date: 2008-01-19 11:55

Message:
Logged In: YES 
user_id=53417
Originator: YES

I'm using Lunar-Linux (source based) the uses bash scripts for the build
process. I could alter it and toss xplc in /opt but some detection logic
for its presence would be the preferred way.... I'd think.

----------------------------------------------------------------------

Comment By: Simon Law (sfllaw)
Date: 2008-01-19 11:44

Message:
Logged In: YES 
user_id=196021
Originator: NO

If you're installing by hand, I'd highly suggest using
--prefix=/usr/local/stow/xplc and using GNU stow to manage it.

We may consider not installing uuidgen, if we detect that it's already
there.

----------------------------------------------------------------------

Comment By: Dennis  (stumbles)
Date: 2008-01-19 11:35

Message:
Logged In: YES 
user_id=53417
Originator: YES

No, I am using --prefix=/usr

----------------------------------------------------------------------

Comment By: Simon Law (sfllaw)
Date: 2008-01-19 11:27

Message:
Logged In: YES 
user_id=196021
Originator: NO

Surely, you're not installing with --prefix=/ !

For almost every sane configuration I can think of, you'll be installing
in /opt or /usr/local.  Since XPLC is meant to work across all platforms,
including ones without uuidgen, it makes sense for us to install it.

If you are packaging the software, please pull in an appropriate
implementation of uuidgen as a dependency and ignore XPLC's own copy.

----------------------------------------------------------------------

Comment By: Dennis  (stumbles)
Date: 2008-01-19 09:47

Message:
Logged In: YES 
user_id=53417
Originator: YES

Oh, forgot to note it had a problem with ln of libxplc.so and libxplc_s.a
when they already existed.

----------------------------------------------------------------------

Comment By: Dennis  (stumbles)
Date: 2008-01-19 09:46

Message:
Logged In: YES 
user_id=53417
Originator: YES

Here is a patch that removes the uuidgen stuff. Seems to work here but
could stand further scruteny.
File Added: xplc-0.3.13-rules.mk.patch

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=101814&aid=1875310&group_id=1814

[xplc-general] [ xplc-Bugs-1875310 ] xplc over writes uuidgen provided by e2fsprogs

[SourceForge.net <no...@so...>]

Bugs item #1875310, was opened at 2008-01-19 09:26
Message generated for change (Comment added) made by sfllaw
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=101814&aid=1875310&group_id=1814

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Dennis  (stumbles)
Assigned to: Nobody/Anonymous (nobody)
Summary: xplc over writes uuidgen provided by e2fsprogs

Initial Comment:
As the summary indicates there is a conflict of sorts between xplc and e2fsprogs. AFAIK most linux boxes will already have e2fsprogs installed which means uuidgen will already be present. I think over righting a system file such as this could cause a person to go down a false troubleshooting path, not to mention IMHO such over righting is a bit um, rude.

I don't know just how different xplc uses its version of uuidgen but would it not be better to use the one provided by e2fsprogs?

In any event, if the xplc version of uuidgen must be kept would it be to much trouble to rename it so as not to conflict with an existing system file?

Thanks. 

----------------------------------------------------------------------

Comment By: Simon Law (sfllaw)
Date: 2008-01-19 11:44

Message:
Logged In: YES 
user_id=196021
Originator: NO

If you're installing by hand, I'd highly suggest using
--prefix=/usr/local/stow/xplc and using GNU stow to manage it.

We may consider not installing uuidgen, if we detect that it's already
there.

----------------------------------------------------------------------

Comment By: Dennis  (stumbles)
Date: 2008-01-19 11:35

Message:
Logged In: YES 
user_id=53417
Originator: YES

No, I am using --prefix=/usr

----------------------------------------------------------------------

Comment By: Simon Law (sfllaw)
Date: 2008-01-19 11:27

Message:
Logged In: YES 
user_id=196021
Originator: NO

Surely, you're not installing with --prefix=/ !

For almost every sane configuration I can think of, you'll be installing
in /opt or /usr/local.  Since XPLC is meant to work across all platforms,
including ones without uuidgen, it makes sense for us to install it.

If you are packaging the software, please pull in an appropriate
implementation of uuidgen as a dependency and ignore XPLC's own copy.

----------------------------------------------------------------------

Comment By: Dennis  (stumbles)
Date: 2008-01-19 09:47

Message:
Logged In: YES 
user_id=53417
Originator: YES

Oh, forgot to note it had a problem with ln of libxplc.so and libxplc_s.a
when they already existed.

----------------------------------------------------------------------

Comment By: Dennis  (stumbles)
Date: 2008-01-19 09:46

Message:
Logged In: YES 
user_id=53417
Originator: YES

Here is a patch that removes the uuidgen stuff. Seems to work here but
could stand further scruteny.
File Added: xplc-0.3.13-rules.mk.patch

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=101814&aid=1875310&group_id=1814

[xplc-general] [ xplc-Bugs-1875310 ] xplc over writes uuidgen provided by e2fsprogs

[SourceForge.net <no...@so...>]

Bugs item #1875310, was opened at 2008-01-19 09:26
Message generated for change (Comment added) made by stumbles
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=101814&aid=1875310&group_id=1814

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Dennis  (stumbles)
Assigned to: Nobody/Anonymous (nobody)
Summary: xplc over writes uuidgen provided by e2fsprogs

Initial Comment:
As the summary indicates there is a conflict of sorts between xplc and e2fsprogs. AFAIK most linux boxes will already have e2fsprogs installed which means uuidgen will already be present. I think over righting a system file such as this could cause a person to go down a false troubleshooting path, not to mention IMHO such over righting is a bit um, rude.

I don't know just how different xplc uses its version of uuidgen but would it not be better to use the one provided by e2fsprogs?

In any event, if the xplc version of uuidgen must be kept would it be to much trouble to rename it so as not to conflict with an existing system file?

Thanks. 

----------------------------------------------------------------------

>Comment By: Dennis  (stumbles)
Date: 2008-01-19 11:35

Message:
Logged In: YES 
user_id=53417
Originator: YES

No, I am using --prefix=/usr

----------------------------------------------------------------------

Comment By: Simon Law (sfllaw)
Date: 2008-01-19 11:27

Message:
Logged In: YES 
user_id=196021
Originator: NO

Surely, you're not installing with --prefix=/ !

For almost every sane configuration I can think of, you'll be installing
in /opt or /usr/local.  Since XPLC is meant to work across all platforms,
including ones without uuidgen, it makes sense for us to install it.

If you are packaging the software, please pull in an appropriate
implementation of uuidgen as a dependency and ignore XPLC's own copy.

----------------------------------------------------------------------

Comment By: Dennis  (stumbles)
Date: 2008-01-19 09:47

Message:
Logged In: YES 
user_id=53417
Originator: YES

Oh, forgot to note it had a problem with ln of libxplc.so and libxplc_s.a
when they already existed.

----------------------------------------------------------------------

Comment By: Dennis  (stumbles)
Date: 2008-01-19 09:46

Message:
Logged In: YES 
user_id=53417
Originator: YES

Here is a patch that removes the uuidgen stuff. Seems to work here but
could stand further scruteny.
File Added: xplc-0.3.13-rules.mk.patch

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=101814&aid=1875310&group_id=1814

[xplc-general] [ xplc-Bugs-1875310 ] xplc over writes uuidgen provided by e2fsprogs

[SourceForge.net <no...@so...>]

Bugs item #1875310, was opened at 2008-01-19 09:26
Message generated for change (Comment added) made by sfllaw
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=101814&aid=1875310&group_id=1814

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Dennis  (stumbles)
Assigned to: Nobody/Anonymous (nobody)
Summary: xplc over writes uuidgen provided by e2fsprogs

Initial Comment:
As the summary indicates there is a conflict of sorts between xplc and e2fsprogs. AFAIK most linux boxes will already have e2fsprogs installed which means uuidgen will already be present. I think over righting a system file such as this could cause a person to go down a false troubleshooting path, not to mention IMHO such over righting is a bit um, rude.

I don't know just how different xplc uses its version of uuidgen but would it not be better to use the one provided by e2fsprogs?

In any event, if the xplc version of uuidgen must be kept would it be to much trouble to rename it so as not to conflict with an existing system file?

Thanks. 

----------------------------------------------------------------------

Comment By: Simon Law (sfllaw)
Date: 2008-01-19 11:27

Message:
Logged In: YES 
user_id=196021
Originator: NO

Surely, you're not installing with --prefix=/ !

For almost every sane configuration I can think of, you'll be installing
in /opt or /usr/local.  Since XPLC is meant to work across all platforms,
including ones without uuidgen, it makes sense for us to install it.

If you are packaging the software, please pull in an appropriate
implementation of uuidgen as a dependency and ignore XPLC's own copy.

----------------------------------------------------------------------

Comment By: Dennis  (stumbles)
Date: 2008-01-19 09:47

Message:
Logged In: YES 
user_id=53417
Originator: YES

Oh, forgot to note it had a problem with ln of libxplc.so and libxplc_s.a
when they already existed.

----------------------------------------------------------------------

Comment By: Dennis  (stumbles)
Date: 2008-01-19 09:46

Message:
Logged In: YES 
user_id=53417
Originator: YES

Here is a patch that removes the uuidgen stuff. Seems to work here but
could stand further scruteny.
File Added: xplc-0.3.13-rules.mk.patch

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=101814&aid=1875310&group_id=1814

[xplc-general] [ xplc-Bugs-1875310 ] xplc over writes uuidgen provided by e2fsprogs

[SourceForge.net <no...@so...>]

Bugs item #1875310, was opened at 2008-01-19 09:26
Message generated for change (Comment added) made by stumbles
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=101814&aid=1875310&group_id=1814

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Dennis  (stumbles)
Assigned to: Nobody/Anonymous (nobody)
Summary: xplc over writes uuidgen provided by e2fsprogs

Initial Comment:
As the summary indicates there is a conflict of sorts between xplc and e2fsprogs. AFAIK most linux boxes will already have e2fsprogs installed which means uuidgen will already be present. I think over righting a system file such as this could cause a person to go down a false troubleshooting path, not to mention IMHO such over righting is a bit um, rude.

I don't know just how different xplc uses its version of uuidgen but would it not be better to use the one provided by e2fsprogs?

In any event, if the xplc version of uuidgen must be kept would it be to much trouble to rename it so as not to conflict with an existing system file?

Thanks. 

----------------------------------------------------------------------

>Comment By: Dennis  (stumbles)
Date: 2008-01-19 09:47

Message:
Logged In: YES 
user_id=53417
Originator: YES

Oh, forgot to note it had a problem with ln of libxplc.so and libxplc_s.a
when they already existed.

----------------------------------------------------------------------

Comment By: Dennis  (stumbles)
Date: 2008-01-19 09:46

Message:
Logged In: YES 
user_id=53417
Originator: YES

Here is a patch that removes the uuidgen stuff. Seems to work here but
could stand further scruteny.
File Added: xplc-0.3.13-rules.mk.patch

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=101814&aid=1875310&group_id=1814

[xplc-general] [ xplc-Bugs-1875310 ] xplc over writes uuidgen provided by e2fsprogs

[SourceForge.net <no...@so...>]

Bugs item #1875310, was opened at 2008-01-19 09:26
Message generated for change (Comment added) made by stumbles
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=101814&aid=1875310&group_id=1814

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Dennis  (stumbles)
Assigned to: Nobody/Anonymous (nobody)
Summary: xplc over writes uuidgen provided by e2fsprogs

Initial Comment:
As the summary indicates there is a conflict of sorts between xplc and e2fsprogs. AFAIK most linux boxes will already have e2fsprogs installed which means uuidgen will already be present. I think over righting a system file such as this could cause a person to go down a false troubleshooting path, not to mention IMHO such over righting is a bit um, rude.

I don't know just how different xplc uses its version of uuidgen but would it not be better to use the one provided by e2fsprogs?

In any event, if the xplc version of uuidgen must be kept would it be to much trouble to rename it so as not to conflict with an existing system file?

Thanks. 

----------------------------------------------------------------------

>Comment By: Dennis  (stumbles)
Date: 2008-01-19 09:46

Message:
Logged In: YES 
user_id=53417
Originator: YES

Here is a patch that removes the uuidgen stuff. Seems to work here but
could stand further scruteny.
File Added: xplc-0.3.13-rules.mk.patch

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=101814&aid=1875310&group_id=1814

[xplc-general] [ xplc-Bugs-1875310 ] xplc over writes uuidgen provided by e2fsprogs

[SourceForge.net <no...@so...>]

Bugs item #1875310, was opened at 2008-01-19 09:26
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=101814&aid=1875310&group_id=1814

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Dennis  (stumbles)
Assigned to: Nobody/Anonymous (nobody)
Summary: xplc over writes uuidgen provided by e2fsprogs

Initial Comment:
As the summary indicates there is a conflict of sorts between xplc and e2fsprogs. AFAIK most linux boxes will already have e2fsprogs installed which means uuidgen will already be present. I think over righting a system file such as this could cause a person to go down a false troubleshooting path, not to mention IMHO such over righting is a bit um, rude.

I don't know just how different xplc uses its version of uuidgen but would it not be better to use the one provided by e2fsprogs?

In any event, if the xplc version of uuidgen must be kept would it be to much trouble to rename it so as not to conflict with an existing system file?

Thanks. 

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=101814&aid=1875310&group_id=1814

Re: [xplc-general] Shareable binaries between gnu g++ and Microsoft Visual C++

[Pierre P. <pph...@gm...>]

On 9/27/06, Lester Memmott <lme...@ya...> wrote:

> I found you are right.  The problem wasn't with g++ but was MSVC Instead.
> The default is not the COM calling convention.  Once I added the __stdcall
> modified to the method declarations in the MSVC code, I have MSVC and g++
> calling each others code.  Thanks!

Good to hear!

> Regarding a Cygwin-XPLC build, I didn't get very far down this path.  If I
> get some time I'll see if I can get it working.  If so, I'll post it back
> here.

Okay, thanks!

Re: [xplc-general] Shareable binaries between gnu g++ and Microsoft Visual C++

[Lester M. <lme...@ya...>]

I found you are right.  The problem wasn't with g++ but was MSVC Instead.  =
The default is not the COM calling convention.  Once I added the __stdcall =
modified to the method declarations in the MSVC code, I have MSVC and g++ c=
alling each others code.  Thanks!=0A=0ARegarding a Cygwin-XPLC build, I did=
n't get very far down this path.  If I get some time I'll see if I can get =
it working.  If so, I'll post it back here.=0A=0AThanks,=0ALM=0A=0APierre P=
haneuf <pph...@gm...>;  Wrote: =0A=0AI know there's a way, because, w=
ell, we're using the COM calling=0Aconventions that Microsoft themselves in=
vented, partly to work around=0Athis problem. Oddly enough, from what I hea=
rd, GCC has the COM calling=0Aconvention on all x86 platforms by default (i=
n version 3.0 and up),=0Awhile MSVC does *not*?!? There is either a global =
option, or a=0A"declspec" kind of thing you need to put beside the class or=
 method=0Adeclaration.=0A=0ASorry I do not have the exact info right at han=
d, my MSVC expert is=0Aaway at the moment. You can find yourself some COM-o=
riginated headers,=0Asuch as the DirectX ones, say, or anything that's gene=
rated from IDL=0Afiles, to see what you should be putting in the headers to=
 make it=0Awork, or search the documentation for things like "COM calling=
=0Aconvention". You might prefer not to use a global option, as the MSVC=0A=
way might be slightly more optimized, using a register for the "this"=0Apoi=
nter, but COM (and XPLC) being callable from C and other languages,=0Ait ca=
nnot use that optimization.=0A=0AIt's one of the things that I'm wanting to=
 write an IDL compiler for,=0Aso that you can write interfaces easily, and =
the IDL compiler takes=0Acare of putting the weird things to make the C/C++=
 compiler do the=0Aright thing.=0A=0A> PS.  I built the libraries with MSVC=
 .Net 2003 with no problem earlier=0A> today.  However, I'm having problems=
 building with Cygwin g++ 3.4.4.  Is=0A> there a Cygwin-XPLC FAQ posted any=
where?=0A=0ANo, unfortunately, those compiling on Windows have been using M=
SVC. If=0Ayou have some tips in that direction, it would be kind of you to =
let=0Aus know about it! Thank you!

Re: [xplc-general] Shareable binaries between gnu g++ and Microsoft Visual C++

[Pierre P. <pph...@gm...>]

On 9/26/06, Lester Memmott <lme...@ya...> wrote:

> > As long as your compiler generates COM-style vtables, that should work
> > just fine.  Of course, it has to be an XPLC library (or wrapper) for
> > this to work.
>
> Thanks for the reponse!  Yes, I'm assuming an XPLC client and compoent for
> this to work.  I looked into this more today and found that the vtables seem
> to be the same, however calling coventions between MSVC and g++ are
> different.  Specifically, the "this pointer" gets pushed on as the last item
> on the stack when using g++, but MSVC puts the "this pointer" in the ESI
> register.  This causes problems to the method called because it is off by 32
> bits (yes, it I'm writing 32 bit code not 64) when trying to access
> parameters and it gets the "this pointer" from the wrong place if mixing
> code built between the two compilers.
>
> Has anyone run up against this?
> Is there a way to force g++ to use the same calling convention (with regards
> to how the "this pointer" is handled) as MSVC?

I know there's a way, because, well, we're using the COM calling
conventions that Microsoft themselves invented, partly to work around
this problem. Oddly enough, from what I heard, GCC has the COM calling
convention on all x86 platforms by default (in version 3.0 and up),
while MSVC does *not*?!? There is either a global option, or a
"declspec" kind of thing you need to put beside the class or method
declaration.

Sorry I do not have the exact info right at hand, my MSVC expert is
away at the moment. You can find yourself some COM-originated headers,
such as the DirectX ones, say, or anything that's generated from IDL
files, to see what you should be putting in the headers to make it
work, or search the documentation for things like "COM calling
convention". You might prefer not to use a global option, as the MSVC
way might be slightly more optimized, using a register for the "this"
pointer, but COM (and XPLC) being callable from C and other languages,
it cannot use that optimization.

It's one of the things that I'm wanting to write an IDL compiler for,
so that you can write interfaces easily, and the IDL compiler takes
care of putting the weird things to make the C/C++ compiler do the
right thing.

> PS.  I built the libraries with MSVC .Net 2003 with no problem earlier
> today.  However, I'm having problems building with Cygwin g++ 3.4.4.  Is
> there a Cygwin-XPLC FAQ posted anywhere?

No, unfortunately, those compiling on Windows have been using MSVC. If
you have some tips in that direction, it would be kind of you to let
us know about it! Thank you!

Re: [xplc-general] Shareable binaries between gnu g++ and Microsoft Visual C++

[Lester M. <lme...@ya...>]

> As long as your compiler generates COM-style vtables, that should work=0A=
> just fine.  Of course, it has to be an XPLC library (or wrapper) for=0A> =
this to work.=0A=0AThanks for the reponse!  Yes, I'm assuming an XPLC clien=
t and compoent for this to work.  I looked into this more today and found t=
hat the vtables seem to be the same, however calling coventions between MSV=
C and g++ are different.  Specifically, the "this pointer" gets pushed on a=
s the last item on the stack when using g++, but MSVC puts the "this pointe=
r" in the ESI register.  This causes problems to the method called because =
it is off by 32 bits (yes, it I'm writing 32 bit code not 64) when trying t=
o access parameters and it gets the "this pointer" from the wrong place if =
mixing code built between the two compilers.  =0A=0AHas anyone run up again=
st this?  =0AIs there a way to force g++ to use the same calling convention=
 (with regards to how the "this pointer" is handled) as MSVC?=0A=0AThanks,=
=0ALM=0A=0APS.  I built the libraries with MSVC .Net 2003 with no problem e=
arlier today.  However, I'm having problems building with Cygwin g++ 3.4.4.=
  Is there a Cygwin-XPLC FAQ posted anywhere?

Re: [xplc-general] Shareable binaries between gnu g++ and Microsoft Visual C++

[Simon L. <sf...@la...>]

On Mon, Sep 25, 2006 at 02:21:09PM -0700, Lester Memmott wrote:
> Does XPLC allow binaries to be compiled with one compiler and used by 
> another? 
>  
> For example, if I have an XPLC DLL compiled in Microsoft Visual C++ 
> (MSVC), can it be used by an EXE or DLL compiled in gnu g++?  ...or 
> vise versa?  (Note:  I'm using Cygwin gcc 3.4.4 on Windows along with 
> MSVC .Net 2003). 

As long as your compiler generates COM-style vtables, that should work
just fine.  Of course, it has to be an XPLC library (or wrapper) for
this to work.

Cheers,
-- 
Simon Law                                 http://www.law.yi.org/~sfllaw/

[xplc-general] Shareable binaries between gnu g++ and Microsoft Visual C++

[Lester M. <lme...@ya...>]

Does XPLC allow binaries to be compiled with one compiler and used by =0Aan=
other? =0A =0AFor example, if I have an XPLC DLL compiled in Microsoft Visu=
al C++ =0A(MSVC), can it be used by an EXE or DLL compiled in gnu g++?  ...=
or =0Avise versa?  (Note:  I'm using Cygwin gcc 3.4.4 on Windows along with=
 =0AMSVC .Net 2003). =0A=0AThanks, =0ALM

Re: [xplc-general] C binding implementations

[Avery P. <ape...@ni...>]

On Thu, Aug 25, 2005 at 12:23:11PM -0400, Pierre Phaneuf wrote:

> Avery Pennarun wrote:
> 
> > My xplcidl actually implements this in a different way, avoiding the
> > horrible pain of manipulating stack frames and other stuff... but
> > potentially with a performance penalty.  (Hey, you're in a scripting
> > language, how much worse can it be?)
> 
> I don't recall the exact details... Didn't you generate a per-interface
> bit of code? The magic with xptcall is that you don't need any compiled
> code specific to the interface, you only need a description of the
> interface (which is delivered in the binary code, or in "typelib" files,
> and I plan on the XPLC version of the same being inlinable even in
> scripting languages).

Yes, you need a compiled bit of code for each interface: but if you're
delivering your typelib in "binary code" anyway, then it might as well just
be executable.  There's no fundamental difference.

Inlining that kind of stuff in scripting langugages is a bit funkier, but
I'm not sure that's a good idea anyway.  It reminds me of the old DATA
statement in BASIC.  Yeah, you could use it, and yeah, it was fine before
they invented disks, but...

> And did yours go both way (be able to implement an XPLC interface in a
> scripting language)?

The same concept could apply either way, although I only implemented one
direction (IMHO by far the most common one for apps/libraries I know of).

Have fun,

Avery

Re: [xplc-general] C binding implementations

[Pierre P. <pp...@lu...>]

Avery Pennarun wrote:

> My xplcidl actually implements this in a different way, avoiding the
> horrible pain of manipulating stack frames and other stuff... but
> potentially with a performance penalty.  (Hey, you're in a scripting
> language, how much worse can it be?)

I don't recall the exact details... Didn't you generate a per-interface
bit of code? The magic with xptcall is that you don't need any compiled
code specific to the interface, you only need a description of the
interface (which is delivered in the binary code, or in "typelib" files,
and I plan on the XPLC version of the same being inlinable even in
scripting languages).

And did yours go both way (be able to implement an XPLC interface in a
scripting language)?

-- 
Pierre Phaneuf
http://advogato.org/person/pphaneuf/
"Disobey. It's the law."

Re: [xplc-general] C binding implementations

[Avery P. <ape...@ni...>]

On Thu, Aug 25, 2005 at 11:55:32AM -0400, Pierre Phaneuf wrote:

> There *is* a platform dependent part that will need to be built
> eventually, which is a foreign function call layer, so that we can build
> stack frames and call into interfaces (so that we can call into any XPLC
> interfaces from scripting languages), as well as provide a proxy
> interface that will disassemble it's stack frames (so that scripting
> languages can implement XPLC interfaces). This layer could be shared by
> any scripting language binding. See Mozilla's xptcall:
> 
> http://www.mozilla.org/scriptable/xptcall-faq.html

My xplcidl actually implements this in a different way, avoiding the
horrible pain of manipulating stack frames and other stuff... but
potentially with a performance penalty.  (Hey, you're in a scripting
language, how much worse can it be?)

Have fun,

Avery

Re: [xplc-general] C binding implementations

[Pierre P. <pp...@lu...>]

lionel petit wrote:

> I read on the Avery's advogato page 
> (http://advogato.org/person/apenwarr/diary.html?start=35) that a
> successful try was made in making dangerous assumptions on the vtable
> layout in C++. It's the solution I have found before reading its
> paper... I know the vtable layout is compiler dependant and, for some
> of them, you have to add some padding to adjust the vtable. Despite
> this unpleasant padding, this solution is very interesting because
> there is as much overhead as in C++! What's your opinion on this and
> do you suggest other solutions? I would not like to use an
> intermediate binary format and have some generation of code at 
> execution or create bridges which redirect all calls to the
> component.

Ah, but Avery had underestimated my cunningness at the time... I had
replied to him in another Advogato post, but due to some disk problems,
my Advogato account is gone. Oops.

The trick is, I just declared that XPLC enforces a vtable layout. It
just so happens that I picked the same vtable layout that COM uses.
Which also happens to be the vtable layout that every compiler either
converged to, or have an attribute to use it for a particular class (and
it's descendants). So you can just assume COM vtable layout safely.

I basically let Microsoft do what they're good at, twisting arms (of the
compiler vendors, in this case). Thank you, Microsoft! :-)

Which compilers did you have to use different padding, by the way?

If you want to know more about all the details of making these things
work, the COM Specification is very interesting.

There *is* a platform dependent part that will need to be built
eventually, which is a foreign function call layer, so that we can build
stack frames and call into interfaces (so that we can call into any XPLC
interfaces from scripting languages), as well as provide a proxy
interface that will disassemble it's stack frames (so that scripting
languages can implement XPLC interfaces). This layer could be shared by
any scripting language binding. See Mozilla's xptcall:

http://www.mozilla.org/scriptable/xptcall-faq.html

-- 
Pierre Phaneuf
http://advogato.org/person/pphaneuf/
"Disobey. It's the law."

Re: [xplc-general] Re: strange behavior in xplc_ptr

[lionel p. <pt...@ip...>]

On Wednesday 17 August 2005 22:18, Pierre Phaneuf wrote:
> S=C3=A9bastien Roret wrote:
> > Well I see I wasn't enough specific. :) The current module loader in
> > xplc is dynamic. It finds all ".so" file in a directory and registers
> > the components in the module. In some cases, we need to link
> > statically all modules with our main. To do that we must collect all
> > module names, find a way to get the entire component list and
> > register each component to the component manager. I guess this kind
> > of feature isn't planned for tomorrow. :)
>
> The Module class, which is not exported, already allows for this. It
> takes the same data structure that goes in a module (XPLC_ModuleInfo)
> and a dynamic loader handle, which can be NULL. So you need to make an
> XPLC_ModuleInfo structure describing your static components, make a
> Module object and add it to the service manager.
>
> I would just need to figure out a decent interface for that and we could
> export it.
>
> So it's not strictly possible today, but would easily be. This was
> planned already, actually, to have a way to easily register static
> components.
>
> Note that there is already the static service handler, which is a bit
> more manual, but can also achieve this and is available right now.
>
> Finding the global component list is the trickier part, particularly in
> the face of static libraries. If you don't have static libraries, you
> can use static global C++ objects that registers components with the
> static service handler, and you're good to go. But here goes a warning
> that this doesn't work for static libraries, at least not without rather
> horrid and non-portable hacks (Avery knows about them in more detail,
> you could ask him).

What we have temporarily done, to be able to staticly load modules, is near=
=20
from the dynamic loading. We add~:
  - "virtual IServiceHandler* createModuleManager(const XPLC_ModuleInfo*=20
modulesInfos, unsigned int size)"=20
	to the IModuleManagerFactory
  - "virtual IModule* loadModule(const XPLC_ModuleInfo* aModuleInfo)"=20
	to the IModuleLoader interface.

With this, the manager is able to load each module by passing XPLC_ModuleIn=
fo=20
to the "loadModule" method of a loader.

The problematic point is to retrieve the list of XPLC_ModuleInfo. Each of o=
ur=20
modules is declared "extern" and has a unique name. It is compiled in a=20
separated library file. A global array of XPLC_ModuleInfo keeps a reference=
=20
on each of them. Then we only have to compile the executable with all=20
libraries and use the global array to register all our modules.

Regards,

=2D-=20
Lionel Petit

[xplc-general] C binding implementations

[lionel p. <pt...@ip...>]

Hi,

 I'm thinking of what is the best way to implement components in C with the 
least overhead than possible. 
 I read on the Avery's advogato page 
(http://advogato.org/person/apenwarr/diary.html?start=35) that a successful 
try was made in making dangerous assumptions on the vtable layout in C++. 
It's the solution I have found before reading its paper... I know the vtable 
layout is compiler dependant and, for some of them, you have to add some 
padding to adjust the vtable. Despite this unpleasant padding, this solution 
is very interesting because there is as much overhead as in C++! 
 What's your opinion on this and do you suggest other solutions? I would not 
like to use an intermediate binary format and have some generation of code at 
execution or create bridges which redirect all calls to the component.

Regards,

-- 
Lionel Petit

Re: [xplc-general] Re: strange behavior in xplc_ptr

[Avery P. <ape...@ni...>]

On Tue, Aug 23, 2005 at 02:39:15AM -0400, Pierre Phaneuf wrote:

> Well... You hacks rely on global constructors working, which doesn't 
> work portably.
> 
> On enlightened platforms such as Linux/gcc, they do, but on some odd and 
> not-so-odd platforms, they still don't work right in all circumstances 
> (for example, some only work if they are in the main binary, nothing in 
> shared library will work, other will work in shared libraries, but only 
> if they are linked to your binary, not if they are dynamically loaded, 
> etc, etc, etc).

But this discussion is about statically linking modules into your binary, so
global constructors really should work.  If some platforms still can't do
global constructors in the main binary, then they're living in the stone age
and they *certainly* don't implement C++.

(wvlinkerhack itself doesn't use global constructors.  But you'll have to
use them if you want the linked-in object files to auto-register themselves
with XPLC.)

Have fun,

Avery

[xplc-general] Re: strange behavior in xplc_ptr

[Pierre P. <pp...@lu...>]

Avery Pennarun wrote:

> Hey, my hacks aren't non-portable.  Horrid, yes.  Hacks, yes.  But
> it's just some #defines that generate extern references.  Nothing
> fancy. wvlinkerhack.h in wvstreams.

Well... You hacks rely on global constructors working, which doesn't 
work portably.

On enlightened platforms such as Linux/gcc, they do, but on some odd and 
not-so-odd platforms, they still don't work right in all circumstances 
(for example, some only work if they are in the main binary, nothing in 
shared library will work, other will work in shared libraries, but only 
if they are linked to your binary, not if they are dynamically loaded, 
etc, etc, etc).

This is just so much fun, I can't even begin to tell you! And yes, I'm 
disappointed, this would have been so much neater...

-- 
Pierre Phaneuf
http://www.livejournal.com/users/pphaneuf/
"Disobey. It's the law."

Re: [xplc-general] Re: strange behavior in xplc_ptr

[lionel p. <pt...@ip...>]

On Thursday 18 August 2005 20:59, Pierre Phaneuf wrote:
> lionel petit wrote:
>
> > To finish with xplc_ptr, I moved the operator=(xplc_ptr) in the
> > public part because we really need it.
>
> Why did I make that one private again?

I only found the following thread which talk about this :
http://sourceforge.net/mailarchive/message.php?msg_id=9293075
 
Apparently, it was rather an experiment than a final choice.

> > Mutate method has been updated. Now, the interface is only released
> > if the getInterface() returns a valid pointer.
>
> The templated global function? This is dangerous! Mutate is supposed to
> be usable quickly inline, in cases where you do not care about the
> object if it doesn't have the proper interface (which is the common case
> when an object doesn't have the interface you want). The point was to
> not need a temporary variable for those common cases, and now, we'd
> *always* need a temporary variable (in case it failed).

You're right, forgets this last point.

-- 
Lionel Petit

Re: [xplc-general] Re: strange behavior in xplc_ptr

[Avery P. <ape...@ni...>]

On Wed, Aug 17, 2005 at 03:37:42PM +0000, Sébastien Roret wrote:

> Well I see I wasn't enough specific. :) The current module loader in xplc
> is dynamic. It finds all ".so" file in a directory and registers the
> components in the module.  In some cases, we need to link statically all
> modules with our main. To do that we must collect all module names, find a
> way to get the entire component list and register each component to the
> component manager.  I guess this kind of feature isn't planned for
> tomorrow. :)

Ha, this is the behaviour we provide in WvStreams on top of xplc, which
Pierre thought was gross :)

Essentially, the way to do this is to have a static object in each module
with a constructor (running at app startup time).  The constructor registers
the module with the XPLC module system, almost as if it had been loaded by
the dynamic loader.

Other than global constructors, there is no way I know to just link files
together and have it all automatically work out.  Luckily, global
constructors are really easy to use :)

Beware, however: *.a libraries won't work with this method, because none of
the objects in the *.a have symbols that you directly link to from other
parts of the program.  You have to link in the *.o files directly (without
first aggregating them into a *.a) or else use something nasty like the
WvStreams "wvlinkerhack.h"

Have fun,

Avery

Re: [xplc-general] Re: strange behavior in xplc_ptr

[Avery P. <ape...@ni...>]

On Thu, Aug 18, 2005 at 04:07:54AM -0400, Pierre Phaneuf wrote:

> Finding the global component list is the trickier part, particularly in
> the face of static libraries. If you don't have static libraries, you
> can use static global C++ objects that registers components with the
> static service handler, and you're good to go. But here goes a warning
> that this doesn't work for static libraries, at least not without rather
> horrid and non-portable hacks (Avery knows about them in more detail,
> you could ask him).

Hey, my hacks aren't non-portable.  Horrid, yes.  Hacks, yes.  But it's just
some #defines that generate extern references.  Nothing fancy. 
wvlinkerhack.h in wvstreams.

Have fun,

Avery