EV on AIX?
darin.mcbride at shaw.ca
Sun Apr 29 07:41:12 CEST 2012
On Sunday April 29 2012 1:57:00 AM Marc Lehmann wrote:
> On Sat, Apr 28, 2012 at 08:02:21AM -0600, Darin McBride
<darin.mcbride at shaw.ca> wrote:
> > On Saturday April 28 2012 2:24:45 PM Marc Lehmann wrote:
> > > On Thu, Apr 26, 2012 at 12:28:07PM -0600, Darin McBride
> > > Hmm, I am not aware of any fix needed for aix at the moment, and I don't
> > > really get anything out of the quote either, which fix do you mean? You
> > > mean xlC thread support?
> > I mean the one that is in your cvs for libev with the entry in the Changes
> > file:
> > - (ecb) add memory fence support for xlC (Darin McBride).
> Hmm, that dds support for xlC, it doesn't really fix anything.
It fixes this:
"libev/ev.c", line 941.3: 1506-205 (S) #error "memory fences not defined for
your architecture, please report"
> > > Looking at the old thread, there are lots of feasible workarounds
> > You mean using -DECB_NO_SMP or -DEV_NO_THREADS?
> Or using gcc, or pthreads.
GCC requires a fix similar to the lawyer fix, except this one is for management.
We have a fully licensed xlC build system, we're expected to use it and not
use gcc, at least on AIX.
As for pthreads, perl -V says:
cccdlflags=' ', lddlflags='-b64 -bhalt:4 -G -bI:$(PERL_INC)/perl.exp -bE:
$(BASEEXT).exp -bnoentry -lpthreads -lc -lm -L/usr/local/lib'
So it seems that I should be using pthreads already. And ldd confirms:
$ ldd /opt/darin/perl5_64/bin/perl | grep pthread
So simply using pthreads is not sufficient.
> > especially considering there is a fix in your cvs that just simply hasn't
> > been
> Except it doesn't fix anything, certainly not the problem you have.
If I apply said patch, the problem I have goes away. Well, the technical one.
The lawyer problem ratchets up.
> > > Well, the soltuion for not wanting to patch would be to not patch. Also,
> > > your problem with your legal department seems to be a problem with your
> > > legal department, and the solution would be to solve that problem - a
> > > release of libev will not fix any legal or procedural issues.
> > Sure it will.
> Simply insisting on this does not make it so. Again, you have a problem,
> and it's with your legal department. A libev release cannot fix this
> problem. Postpone it maybe, hide it maybe, but the problem will not go
Sure, I still have to go through legal for everything else. But one question
they ask is "will you be modifying the source" and if I say "yes", then they
will bring much more scrutiny because then I could be "tainting" proprietary
code with open-source code by spending time looking at the code. After the
SCO vs IBM lawsuit, there's a desire to keep as much barrier between OSS code
and proprietary code as possible.
"Simply insisting" that my employer's lawyers are a problem doesn't help the
> > but this is all relative. They don't like us patching code for shipment
> > because they think that opens us up to something legal.
> You still don't have to patch code for that.
I'm sorry, I'm not following. You have a fix in cvs that, if it should be
released before I go to the lawyers, would reduce my interrogations by said
lawyers, should I wish to simply use the defaults (which would definitely be
easier). All I asked at the outset here is if you were planning on making an
official release of EV that included said fix in the near future. Actually, I
asked what timeline you were planning on for that release. I'm only asking if
you have plans for "this week" vs "this month" vs "some time from now, maybe a
few months, maybe more" or what. I don't need assistance telling me how
screwed up the legal requirements are, I've been telling that to various
managers for two years now. While working to improve things, I still have to
work within the existing framework until then.
More information about the anyevent