in reply to your question Regarding the long-term direction, I don't understand what the shared objects in Open64 are doing for us. They introduce a lot of complexity in the code and the Makefiles, so we should have good reason to maintain them.
The binaries are splitted up into .so's so that they can be swapped at runtime to a newer/older, yet compatible, version of .so to ascertain a certain features/optimization is working or now. It is a way to help developers during development. Naturally, it should be possible (as most systems can do today) to have updates of part of the compiler by pulling in a specific .so Sun On Wed, Aug 3, 2011 at 7:08 AM, David Coakley <dcoak...@gmail.com> wrote: > No. The default build works as before. Only if you configure with > '--disable-shared' will you get libwopt.a linked into be instead of > wopt.so. > > On Tue, Aug 2, 2011 at 3:43 PM, Sun Chan <sun.c...@gmail.com> wrote: >> Are you saying this change will "remove" shared objects in the open64 >> binaries, such as wopt.so? >> Sun >> >> On Wed, Aug 3, 2011 at 4:43 AM, David Coakley <dcoak...@gmail.com> wrote: >>> Mike, thanks for the review. >>> >>> I have attached a minor revision of the patch with two changes to >>> reduce the number of #ifdef's. >>> >>> 1) I found that the error descriptor was not needed in cgdriver.cxx >>> and lnodriver.cxx since it is already set up by be/driver.cxx. >>> Deleting it also removes the need for the ifdef's in the non-shared >>> build. >>> 2) I changed the Makefiles and driver programs so that the init.cxx >>> files are included in the same way for shared and non-shared builds, >>> via #include instead of being linked in. The related ifdef's are no >>> longer needed. >>> >>> Christopher, I am not sure what problem you might be thinking of on >>> Solaris. We are not using '-static' to link the executables in the >>> non-shared build -- we just build the Open64 components as archive >>> libraries instead of shared objects. >>> >>> Regarding the long-term direction, I don't understand what the shared >>> objects in Open64 are doing for us. They introduce a lot of >>> complexity in the code and the Makefiles, so we should have good >>> reason to maintain them. >>> >>> If there are no objections, I will commit this change and follow up >>> with a proposed patch to remove the BUILD_SKIP_PROMPF and >>> BUILD_SKIP_PURPLE macros and the code they enclose. >>> >>> -David Coakley / AMD Open Source Compiler Engineering >>> >>> On Fri, Jul 29, 2011 at 3:06 PM, Mike Murphy <mmur...@nvidia.com> wrote: >>>> The changes look fine to me. There is the separate issue that Sun raises >>>> of whether to move toward non-shared builds. I think there are some >>>> platforms where it simplifies things if we can build non-shared, so I >>>> think it is worth having as an option. >>>> >>>> -----Original Message----- >>>> From: David Coakley [mailto:dcoak...@gmail.com] >>>> Sent: Thursday, July 28, 2011 4:34 PM >>>> To: open64-devel >>>> Cc: Mike Murphy >>>> Subject: Code review request for changes to support non-shared build >>>> [BUILD] >>>> >>>> The attached patch adds support for an experimental '--disable-shared' >>>> configuration option. >>>> >>>> This option is useful for avoiding the portability problems introduced >>>> by the way Open64 uses shared objects. For example, the use of static >>>> initializers to bind pointers to functions (the "weak symbol >>>> workaround") in the loading process does not work in Cygwin/Windows >>>> environments. >>>> >>>> In the non-shared build, the executables be, inline, whirl2c, and >>>> whirl2f are standalone and do not load any shared objects other than >>>> the standard system libraries. >>>> >>>> Long term, I think building the compiler executables without shared >>>> objects might be the way to go for all platforms. The resulting >>>> executables are easier to debug and the driver is simplified -- no >>>> LD_LIBRARY_PATH. And lots of ugly "weak symbol workaround" code could >>>> be deleted. But first ipa_link will need some changes in order to >>>> work for the non-shared configuration; in this patch, the >>>> --disable-shared option implies --disable-ipa. >>>> >>>> Mike, your review would be appreciated since NVIDIA seems to have >>>> encountered these same issues when porting some Open64 components to >>>> Windows. The details of the changes are in the attached msg.txt file. >>>> Thanks, >>>> >>>> -David Coakley / AMD Open Source Compiler Engineering >>>> ----------------------------------------------------------------------------------- >>>> This email message is for the sole use of the intended recipient(s) and >>>> may contain >>>> confidential information. Any unauthorized review, use, disclosure or >>>> distribution >>>> is prohibited. If you are not the intended recipient, please contact the >>>> sender by >>>> reply email and destroy all copies of the original message. >>>> ----------------------------------------------------------------------------------- >>>> >>> >>> ------------------------------------------------------------------------------ >>> BlackBerry® DevCon Americas, Oct. 18-20, San Francisco, CA >>> The must-attend event for mobile developers. Connect with experts. >>> Get tools for creating Super Apps. See the latest technologies. >>> Sessions, hands-on labs, demos & much more. Register early & save! >>> http://p.sf.net/sfu/rim-blackberry-1 >>> _______________________________________________ >>> Open64-devel mailing list >>> Open64-devel@lists.sourceforge.net >>> https://lists.sourceforge.net/lists/listinfo/open64-devel >>> >>> >> > ------------------------------------------------------------------------------ BlackBerry® DevCon Americas, Oct. 18-20, San Francisco, CA The must-attend event for mobile developers. Connect with experts. Get tools for creating Super Apps. See the latest technologies. Sessions, hands-on labs, demos & much more. Register early & save! http://p.sf.net/sfu/rim-blackberry-1 _______________________________________________ Open64-devel mailing list Open64-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/open64-devel
