OpenMP, Opticks and compiling with Visual Studio Express

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

OpenMP, Opticks and compiling with Visual Studio Express

Kip Streithorst
Administrator
All,

I have discovered that one cannot easily compile plug-ins for Opticks
using Visual Studio Express.  The reason is that the Opticks binaries
are linked with OpenMP which is not included in Visual Studio Express.
However, Trevor and I have discovered over the last week that if we stop
linking the Opticks binaries with OpenMP that will strictly speaking
break backwards binary compatibility (ie. if you plug-in with 4.1.0 or
earlier it will not work on the new release without some kind of
change).  Here are the basic options then, below I'll delve into how it
breaks binary compatibility:


1) Any plug-in developer that wants to build plug-ins using Visual
Studio Express would need to compile Opticks themselves first with
OpenMP turned off.  This plug-in developer wouldn't be able to use all
available plug-ins unless they were fixed.
2) We remove OpenMP from the next release and make the next release a
binary breaking release and require all plug-ins that want to continue
to work be upgraded.
3) We create two trunks, a 4.1.X trunk and a 4.2.X trunk.  The 4.2.X
trunk would be binary breaking and would have OpenMP removed.  The 4.1.X
trunk would continue to have OpenMP enabled and would be binary
compatible.  My problem with this solution is I don't know if the
community has the resources to maintain two parallel release lines at
the moment.

Please let me know what you think we should about this problem or if you
have any other solutions.
 
How does removing OpenMP from Opticks.exe break binary compatibility?

The problem is that since Opticks.exe and the static libaries compiled
into plug-ins have been linked against OpenMP, all earlier compiled
plug-ins possibly have a dll dependence to vcomp.dll or vcompd.dll (ie.
the OpenMP binary).  However, since Visual Studio 2005 a executable or
dll is not allowed to load vcomp.dll unless it has a OpenMP manifest
embedded in it to indicate which version of OpenMP should be loaded.
So, once we stop linking Opticks.exe with OpenMP, every plug-in for
Opticks that is linked against vcomp.dll would need to have the OpenMP
manifest embedded inside of .dll in order for the plug-in to load
properly.  This can be accomplished by running mt.exe which is included
with any edition of Visual Studio.  The problem is that most of the
plug-ins don't have this manifest and they happen to be working by
virtue of the fact that Opticks.exe has already loaded the vcomp.dll
into it's address space by virtue of linking with OpenMP.  So, once we
stop linking Opticks.exe with OpenMP any plug-ins that are using OpenMP
but that don't have the manifest embedded in their binaries will cease
to load, which means we have broken binary backwards compatibility.
Those broken plug-ins could be fixed one of two ways.  You could first
re-build your plug-in but ensuring that the OpenMP manifest is embedded
in the binary (you can use the OpenMP*.vsprops available in the
SDK\Application\CompileSettings).  If you are unable to re-build your
plug-in you could simply run mt.exe to inject the OpenMP manifest into
an already compiled plug-in.

Thanks,
Kip



This message and any enclosures are intended only for the addressee.  Please  
notify the sender by email if you are not the intended recipient.  If you are  
not the intended recipient, you may not use, copy, disclose, or distribute this  
message or its contents or enclosures to any other person and any such actions  
may be unlawful.  Ball reserves the right to monitor and review all messages  
and enclosures sent to or from this email address.

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

RE: OpenMP, Opticks and compiling with Visual Studio Express

Kip Streithorst
Administrator
I have decided to implement solution 2, I have new information however.
The next release of Opticks will be called 4.2.0 and it is binary
breaking.  It is binary breaking only if your Windows plug-in was
compiled against and using OpenMP and you did not include the OpenMP
manifest in your binary.  If you did not use OpenMP in your plug-in it
will continue to load without any changes on your part whatsoever.  If
your plug-in is built on Solaris it will continue to load.  If you were
using OpenMP in your plug-in and you did not embed the OpenMP manifest
you will need to make updates to your binary before it will load in the
next version of Opticks.  You can either re-build your binary and
include the OpenMP* property sheets we include in the
"application\CompileSettings" folder of the SDK.  You can also use
"mt.exe" to embed the manifests into your already compiled plug-in.  Let
me know if you have questions about how to do this.

Thanks,
Kip

-----Original Message-----
From: Streithorst, Kip [mailto:[hidden email]]
Sent: Thursday, May 15, 2008 2:20 PM
To: [hidden email]
Subject: OpenMP, Opticks and compiling with Visual Studio Express

All,

I have discovered that one cannot easily compile plug-ins for Opticks
using Visual Studio Express.  The reason is that the Opticks binaries
are linked with OpenMP which is not included in Visual Studio Express.
However, Trevor and I have discovered over the last week that if we stop
linking the Opticks binaries with OpenMP that will strictly speaking
break backwards binary compatibility (ie. if you plug-in with 4.1.0 or
earlier it will not work on the new release without some kind of
change).  Here are the basic options then, below I'll delve into how it
breaks binary compatibility:


1) Any plug-in developer that wants to build plug-ins using Visual
Studio Express would need to compile Opticks themselves first with
OpenMP turned off.  This plug-in developer wouldn't be able to use all
available plug-ins unless they were fixed.
2) We remove OpenMP from the next release and make the next release a
binary breaking release and require all plug-ins that want to continue
to work be upgraded.
3) We create two trunks, a 4.1.X trunk and a 4.2.X trunk.  The 4.2.X
trunk would be binary breaking and would have OpenMP removed.  The 4.1.X
trunk would continue to have OpenMP enabled and would be binary
compatible.  My problem with this solution is I don't know if the
community has the resources to maintain two parallel release lines at
the moment.

Please let me know what you think we should about this problem or if you
have any other solutions.
 
How does removing OpenMP from Opticks.exe break binary compatibility?

The problem is that since Opticks.exe and the static libaries compiled
into plug-ins have been linked against OpenMP, all earlier compiled
plug-ins possibly have a dll dependence to vcomp.dll or vcompd.dll (ie.
the OpenMP binary).  However, since Visual Studio 2005 a executable or
dll is not allowed to load vcomp.dll unless it has a OpenMP manifest
embedded in it to indicate which version of OpenMP should be loaded.
So, once we stop linking Opticks.exe with OpenMP, every plug-in for
Opticks that is linked against vcomp.dll would need to have the OpenMP
manifest embedded inside of .dll in order for the plug-in to load
properly.  This can be accomplished by running mt.exe which is included
with any edition of Visual Studio.  The problem is that most of the
plug-ins don't have this manifest and they happen to be working by
virtue of the fact that Opticks.exe has already loaded the vcomp.dll
into it's address space by virtue of linking with OpenMP.  So, once we
stop linking Opticks.exe with OpenMP any plug-ins that are using OpenMP
but that don't have the manifest embedded in their binaries will cease
to load, which means we have broken binary backwards compatibility.
Those broken plug-ins could be fixed one of two ways.  You could first
re-build your plug-in but ensuring that the OpenMP manifest is embedded
in the binary (you can use the OpenMP*.vsprops available in the
SDK\Application\CompileSettings).  If you are unable to re-build your
plug-in you could simply run mt.exe to inject the OpenMP manifest into
an already compiled plug-in.

Thanks,
Kip



This message and any enclosures are intended only for the addressee.
Please  
notify the sender by email if you are not the intended recipient.  If
you are  
not the intended recipient, you may not use, copy, disclose, or
distribute this  
message or its contents or enclosures to any other person and any such
actions  
may be unlawful.  Ball reserves the right to monitor and review all
messages  
and enclosures sent to or from this email address.

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]




This message and any enclosures are intended only for the addressee.  Please  
notify the sender by email if you are not the intended recipient.  If you are  
not the intended recipient, you may not use, copy, disclose, or distribute this  
message or its contents or enclosures to any other person and any such actions  
may be unlawful.  Ball reserves the right to monitor and review all messages  
and enclosures sent to or from this email address.

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]