Re: Strange rpath behavior

2011-08-14 Thread Jorge Gallegos
On Sun, 2011-08-14 at 14:47 +0900, TASAKA Mamoru wrote:
 Jorge Gallegos wrote, at 08/14/2011 09:22 AM +9:00:
  Hi,
 
  I am looking for a sponsor for uwsgi server in this ticket
  https://bugzilla.redhat.com/show_bug.cgi?id=682704 however I am trying
  to fix the rpath issues I commented there because otherwise i think it
  simply won't pass. I am faced with some... weird behavior.
 
  The software does not use the standard configure/makefile approach,
  instead it is built using a python program (uwsiconfig.py) to decide
  what flags it should use, then simply calls them (os.system(bla)) to
  build it.
 
  When I build the package using the python program I get warnings about
  rpath being present (sure enough I inspect the binaries and I can
  see /usr/lib64 in there) but, when I basically pipe the output of the
  program to another shell file (sans comments) and execute that shell
  file, I get no warning whatsoever and /usr/lib64 is nowhere to be found
  in the binaries.
 
  Now, I could cheat and patch uwsgiconfig.py to write the shell script
  instead of calling os.system (actually I have a patch/spec I just tested
  and works just fine) but that sounds like bad form. Can any of you
  veterans tell me why this is happening?
 
  My initial thought would be: python _has_ rpath issues, which the
  binaries inherit because they are compiled under python's scope
 
  Thoughts?
 
 
 Only commenting about rpath issue here (fixing packaging issues is also
 needed).
 
 Try finding LD_RUN_PATH string in uwsgi source. This string is actually
 there and this causes rpath to be embedded in built binaries.
 
 Note that there seems some API change in jansson and your srpm won't build
 in F-16 currently.
 
 Regards,
 Mamoru
 
 
 

Mamoru:

Excellent! thanks for the tip, that is actually what was happening: the
LD_RUN_PATH env var was being set in two of the plugins at build time,
affecting the rest as well. When I was running the build instructions
manually no environment was set, so that was the difference.

Thanks a lot, will update the ticket.

~kad


signature.asc
Description: This is a digitally signed message part
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Strange rpath behavior

2011-08-13 Thread TASAKA Mamoru
Jorge Gallegos wrote, at 08/14/2011 09:22 AM +9:00:
 Hi,

 I am looking for a sponsor for uwsgi server in this ticket
 https://bugzilla.redhat.com/show_bug.cgi?id=682704 however I am trying
 to fix the rpath issues I commented there because otherwise i think it
 simply won't pass. I am faced with some... weird behavior.

 The software does not use the standard configure/makefile approach,
 instead it is built using a python program (uwsiconfig.py) to decide
 what flags it should use, then simply calls them (os.system(bla)) to
 build it.

 When I build the package using the python program I get warnings about
 rpath being present (sure enough I inspect the binaries and I can
 see /usr/lib64 in there) but, when I basically pipe the output of the
 program to another shell file (sans comments) and execute that shell
 file, I get no warning whatsoever and /usr/lib64 is nowhere to be found
 in the binaries.

 Now, I could cheat and patch uwsgiconfig.py to write the shell script
 instead of calling os.system (actually I have a patch/spec I just tested
 and works just fine) but that sounds like bad form. Can any of you
 veterans tell me why this is happening?

 My initial thought would be: python _has_ rpath issues, which the
 binaries inherit because they are compiled under python's scope

 Thoughts?


Only commenting about rpath issue here (fixing packaging issues is also
needed).

Try finding LD_RUN_PATH string in uwsgi source. This string is actually
there and this causes rpath to be embedded in built binaries.

Note that there seems some API change in jansson and your srpm won't build
in F-16 currently.

Regards,
Mamoru



-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel