Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=470696 Mohammed Morsi <mmorsi@xxxxxxxxxx> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |mmorsi@xxxxxxxxxx --- Comment #62 from Mohammed Morsi <mmorsi@xxxxxxxxxx> 2010-09-13 17:33:56 EDT --- I just spent a little while going through this and trying to figure out what exactly would need to be done to get passenger working with the stock boost in Fedora. The following are issues we may run into: Issues which shouldn't post a problem: * Additional 'defined' checks simply check for netbsd or solaris, neither of which is applicable here * elif BOOST_PP_INTERATION_DEPTH changes, made for gcc 4.4 compatibility. Since boost is already working against gcc in Fedora, this change isn't needed (correct me if I'm wrong) * whitespace changes in non_type.hpp, which I'm guessing shouldn't be there as nothing else is different Issues which might pose a problem: * the vendorized boost is at version 1.35 while in Fedora 14 we are going to be at 1.44. I believe this just about summarizes the issue Fedora has with vendorized libs, and I'm not sure if the thread library between these two versions are compatible. * the condition_varaible and mutex destructors and the condition_variable::wait method try to repeat the necessary pthread destruction code until it is successful, as opposed to attempting it once and verifying the result with BOOST_VERIFY. As of right now I'm not sure why it does this, it seems to me that if the pthread destruction call fails once, it'll fail everytime, and if this is necessary on Linux. It may not be, this change maybe only for solaris or something; some additional clarification would be great. If it is required this is going to be very hard if not impossible to remove as if assertions in boost are enabled, BOOST_VERIFY will terminate a running program (if the condition being verified is false) and there isn't much we can do about it. * changes to the exception hierarchy and additional exception information has been added to thread_exception, thread_resource_error, and thread_interrupted, to add backtrace and system_error_code support. Unless I'm mistaken these are purely informational only (for debugging) and thus this shouldn't pose an issue (once again correct me if I'm wrong). The apache hooks may have to be modified though to remove the TRACE_POINTs (or perhaps not, still needs more exploration) * the thread constructor and start_thread method take an optional stack size. >From my current understanding this is platform specific, and since boost is already working on Fedora Linux x86 and x86_64 as is, this is unneeded. That about covers it, I am going to attempt to see if I can passenger working against boost in Fedora, but might not be able to for the aforementioned reasons. If anyone knows any fault in my analysis above, or some other reason why I won't be able to, please correct me, so that I don't invest a ton of time into this. Also if I am successful, it may come at the price of a heavily modified passenger source, but we'll tackle that if/when we get to that point. P.S. would creating a separate upstream project resolve this issue without any of this? Obviously someone would have to maintain this, but would something like a passenger-boost project work? -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. _______________________________________________ package-review mailing list package-review@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/package-review