Discussion:
[omniORB] DIR_CPPFLAGS im omniOrb-4.1.0
Will Denissen
2007-09-24 18:21:07 UTC
Permalink
Dear Duncan,

In omniOrb-4.1.0 several dir.mk files contain DIR_CPPFLAGS that are appended
with -D<key>=<value>, where value is a string.
Depending on the definition of CXX as 1) an executable g++ or 2) a script
wrapped around a g++, the results of the
gmake command is different; 1) succeeds and 2) crashes.

Is there any string passing method which makes these DIR_CPPFLAGS
independent of the CXX definition?
Can this fix be incorporated in the coming version 4.1.1?

Best regards,

Will Denissen
--
The information contained in this communication and any attachments is confidential and may be privileged, and is for the sole use of the intended recipient(s). Any unauthorized review, use, disclosure or distribution is prohibited. Unless explicitly stated otherwise in the body of this communication or the attachment thereto (if any), the information is provided on an AS-IS basis without any express or implied warranties or liabilities. To the extent you are relying on this information, you are doing so at your own risk. If you are not the intended recipient, please notify the sender immediately by replying to this message and destroy all copies of this message and any attachments. ASML is neither liable for the proper and complete transmission of the information contained in this communication, nor for any delay in its receipt.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.omniorb-support.com/pipermail/omniorb-list/attachments/20070924/8c847631/attachment.htm
Duncan Grisby
2007-10-01 21:34:13 UTC
Permalink
Post by Will Denissen
In omniOrb-4.1.0 several dir.mk files contain DIR_CPPFLAGS that are appended
with -D<key>=<value>, where value is a string.
Depending on the definition of CXX as 1) an executable g++ or 2) a script
wrapped around a g++, the results of the
gmake command is different; 1) succeeds and 2) crashes.
Is there any string passing method which makes these DIR_CPPFLAGS
independent of the CXX definition?
What exactly is the issue? Which makefiles fail? And what's in your
script? Does it perhaps include an invocation of g++ like

g++ $@

or maybe

g++ $*

If so, does it work if you change it to

g++ "$@"

?

Cheers,

Duncan.
--
-- Duncan Grisby --
-- ***@grisby.org --
-- http://www.grisby.org --
Will Denissen
2007-10-04 19:03:38 UTC
Permalink
Dear Duncan,

The problem concentrated around our wrapper script.
It contained something like:

...
eval g++ ${options}
...

and this forced a reinterpretation of the expansion of ${options} (i.e.
removing ' and "). As a side effect the string passing options get
corrupted.
Changing the wrapper into something like:

...
g++ ${options}
...

solved the problem.

Sorry for the interruption of you work.

Will.
-----Original Message-----
Sent: Monday, October 01, 2007 5:34 PM
To: Will Denissen
Subject: Re: [omniORB] DIR_CPPFLAGS im omniOrb-4.1.0
Post by Will Denissen
In omniOrb-4.1.0 several dir.mk files contain DIR_CPPFLAGS that are
appended with -D<key>=<value>, where value is a string.
Depending on the definition of CXX as 1) an executable g++ or 2) a
script wrapped around a g++, the results of the gmake command is
different; 1) succeeds and 2) crashes.
Is there any string passing method which makes these DIR_CPPFLAGS
independent of the CXX definition?
What exactly is the issue? Which makefiles fail? And what's
in your script? Does it perhaps include an invocation of g++ like
or maybe
g++ $*
If so, does it work if you change it to
?
Cheers,
Duncan.
--
-- Duncan Grisby --
-- http://www.grisby.org --
--
The information contained in this communication and any attachments is confidential and may be privileged, and is for the sole use of the intended recipient(s). Any unauthorized review, use, disclosure or distribution is prohibited. Unless explicitly stated otherwise in the body of this communication or the attachment thereto (if any), the information is provided on an AS-IS basis without any express or implied warranties or liabilities. To the extent you are relying on this information, you are doing so at your own risk. If you are not the intended recipient, please notify the sender immediately by replying to this message and destroy all copies of this message and any attachments. ASML is neither liable for the proper and complete transmission of the information contained in this communication, nor for any delay in its receipt.
Loading...