Jean,
Good question.
When doing the build the install line (line 50) will install into the
proto area for the 32-bit build this will include the etree.so and
objectify.so libraries. This is not changed. If there were such a
thing as a partial pkgmk we would be golden. But then the 64-bit build
would come along and over write the same libraries for the install line
(line 58) if the proto-64 directory is not used. So we would end up
with a 64-bit library only within the packaging.
An alternative would be to create a 64-bit directory within the
proto area. Then do the build and manually copy over the appropriate
libraries into the new 64-bit directory within the proto area.
A 3rd alternative would be to modify the build within the lxml download
to build both the 32-bit and 64-bit versions with the same build
command. I thought that would be undesirable because then we
would have to port the change each time we upgraded lxml.
I am not married to either the first or the second method of getting
the libraries into the package. I do not believe the third method
should be done.
Probably more then you wanted to know but...
Thanks,
John
jeanm wrote:
> John,
>
> I'm curious about the proto-64 directory. Does this currently exist? Why
> did you create it and not just have the build put them into the
> proto/${PROC}/usr/lib/python$(PYTHON_VERS)/site-packages/lxml/64
> directory in the first place?
>
> Jean
>
> John Fischer wrote:
>> All,
>>
>> The Python lxml case (PSARC 2009/579) required that there be a 64-bit
>> version of the shared objects. I filed defect 12535 to track this
>> issue.
>>
>> webrev:
>>
>> http://cr.opensolaris.org/~johnfisc/lxml/
>>
>> Open Solaris defect:
>>
>> 12535 - lxml need 64-bit version of the shared objects
>>
>> The fix is to use the -m64 option for the C compiler within the
>> Makefile. The one odd thing about the make is that repeated builds
>> would not complete cleanly because of remaining .so files so I had to
>> add some code to clean things up within the Makefile. The other part
>> of the fix is an update to the appropriate prototype files to build
>> the resulting package.
>>
>> When someone has a chance I would appreciate a review.
>>
>> Thanks,
>>
>> John
>> _______________________________________________
>> caiman-discuss mailing list
>> caiman-discuss at opensolaris.org
>> http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
>
