Nabble - xplc

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

2008-01-19T08:55:12Z

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

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
xplc-general mailing list
xplc-general@...
https://lists.sourceforge.net/lists/listinfo/xplc-general

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

2008-01-19T08:44:11Z

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

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
xplc-general mailing list
xplc-general@...
https://lists.sourceforge.net/lists/listinfo/xplc-general

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

2008-01-19T08:35:59Z

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

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
xplc-general mailing list
xplc-general@...
https://lists.sourceforge.net/lists/listinfo/xplc-general

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

2008-01-19T08:27:32Z

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

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
xplc-general mailing list
xplc-general@...
https://lists.sourceforge.net/lists/listinfo/xplc-general

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

2008-01-19T06:47:50Z

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

2008-01-19T06:46:09Z

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

2008-01-19T06:26:28Z

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

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
xplc-general mailing list
xplc-general@...
https://lists.sourceforge.net/lists/listinfo/xplc-general

Re: Shareable binaries between gnu g++ and Microsoft Visual C++

2006-10-02T03:05:50Z

On 9/27/06, Lester Memmott <lmemmott@...> 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!

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
xplc-general mailing list
xplc-general@...
https://lists.sourceforge.net/lists/listinfo/xplc-general

Re: Shareable binaries between gnu g++ and Microsoft Visual C++

2006-09-27T09:47:24Z

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!

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.

Thanks,

Pierre Phaneuf <pphaneuf@...>; Wrote:

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!

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
xplc-general mailing list
xplc-general@...
https://lists.sourceforge.net/lists/listinfo/xplc-general

Re: Shareable binaries between gnu g++ and Microsoft Visual C++

2006-09-26T01:46:50Z

On 9/26/06, Lester Memmott <lmemmott@...> 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?

Re: Shareable binaries between gnu g++ and Microsoft Visual C++

2006-09-25T20:07:49Z

> 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?

Thanks,

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?

Re: Shareable binaries between gnu g++ and Microsoft Visual C++

2006-09-25T15:36:20Z

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/

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
xplc-general mailing list
xplc-general@...
https://lists.sourceforge.net/lists/listinfo/xplc-general

Shareable binaries between gnu g++ and Microsoft Visual C++

2006-09-25T15:21:09Z

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).

Thanks,
LM