Community Packages

Please read this before reporting a bug:
https://wiki.archlinux.org/title/Bug_reporting_guidelines

Do NOT report bugs when a package is just outdated, or it is in the AUR. Use the 'flag out of date' link on the package page, or the Mailing List.

REPEAT: Do NOT report bugs for outdated packages!
Tasklist

FS#19100 - [e-svn] Recent build breaks loading of modules on i686

Attached to Project: Community Packages
Opened by Eric M. Gonzalez (tasker) - Wednesday, 14 April 2010, 17:19 GMT
Last edited by Ronald van Haren (pressh) - Tuesday, 15 June 2010, 19:14 GMT
Task Type Bug Report
Category Packages
Status Closed
Assigned To Ronald van Haren (pressh)
Architecture i686
Severity Medium
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

Description: Prior versions of Enlightenment have not exhibited this behavior. Investigation led me to believe that this version of Enlightenment (47761-1) was built on an x86_64 architecture. Examining the contents of the package listing at http://www.archlinux.org/packages/community/i686/e-svn/ shows that there is evidence of this statement. When attempting to load itask-ng-svn (AUR, built on an i686 architecture) I recieve an error stating:

"There was an error loading module named: itask-ng

No module named itask-ng/linux-gnu-x86_64-ver-pre-svn-05/module.so could
found in the module search directories.

Would you like to unload this module?

[Yes] [No]"

Searching into /usr/lib/enligtenment/modules I discovered that the itask-ng-svn module is instead installed into 'itask-ng/linux-gnu-i686-ver-pre-svn-05' (see attached image). Making a link from linux-gnu-i686-ver-pre-svn-05 to linux-gnu-x86_64-ver-pre-svn-05 did not work, and instead causes Enlightenment to crash due to a segmentation fault.

Additional info:
* package version(s)
e-svn: 47761-1
itask-ng-svn: 771-1
uname -a: Linux damnit 2.6.32-sB #3 ZEN SMP PREEMPT Mon Apr 12 19:50:19 CDT 2010 i686 Intel(R) Pentium(R) 4 CPU 2.80GHz GenuineIntel GNU/Linux


* config and/or log files etc.


Steps to reproduce:
1) Retrieve AUR itask-ng-svn
2) build and install
3) Open menu and select "Settings -> Modules"
4) Select 'Itask-NG' from "System" and then press "Load"
   itask-ng-bugreport-2010-04-10... (105.2 KiB)
This task depends upon

Closed by  Ronald van Haren (pressh)
Tuesday, 15 June 2010, 19:14 GMT
Reason for closing:  Fixed
Additional comments about closing:  should work again with the latest snapshot I suppose
Comment by Ronald van Haren (pressh) - Wednesday, 14 April 2010, 18:14 GMT
just to be sure... it is just itask-ng not working, not the e17 packages itself? The packages were created in an i686 chroot on top of x86_64 userspace so I'm not quite sure where this x86_64 part in the filenames comes from (at least if I didn't make any mistakes).
Comment by Eric M. Gonzalez (tasker) - Wednesday, 14 April 2010, 18:29 GMT
it is not limited to itask.

the modules that were packaged with e-svn work just fine. it's when i introduce a module from outside of the package that the error is presented. the core of 'e' is looking for x86_64, and doesn't take anything from outside of that.

let me know if you need anything else.
Comment by Ronald van Haren (pressh) - Wednesday, 14 April 2010, 18:58 GMT
reference to myself so I don't forget...

configure script seems to use 'uname -m' or some sort which defaults to x86_64 when using an i686 chroot on a x86_64 userspace. Supposedly we can fix this by supplying the --build=i686 switch to the configure script for the i686 architecture.

@Eric: the other way around may work as well (though I haven't tested any of the above). You may want to try it before I have time to build new packages.
Comment by Eric M. Gonzalez (tasker) - Thursday, 15 April 2010, 03:15 GMT
sorry, but i don't quite understand what you're getting at? is your suggestion to build the module with ARCH=x86_64?
Comment by Ronald van Haren (pressh) - Thursday, 15 April 2010, 10:36 GMT
no, the i686 e17 packages think they are build on the x86_64 architecture, although they are not. My suggestion was, until I have time to fix it, to fool the itask-ng package much the same way.

You can do this by changing the autogen line in the itask-ng PKGBUILD to

./autogen.sh --prefix=/usr --build=x86_64

and just build on your i686 architecture.
Well, I haven't tested it, so it may or may not actually work.
Comment by Eric M. Gonzalez (tasker) - Thursday, 15 April 2010, 14:23 GMT
that was what i got out of your suggestion, but i presumed that it would build 64bit binaries which (as far as i know) wouldn't run on my arch. I'll give a shot here in a little while and post the results.
Comment by Eric M. Gonzalez (tasker) - Thursday, 15 April 2010, 14:43 GMT
Well, it compiled, and made the package without error, but listing the contents of the package revealed the module.so was missing.

but if you'll notice in the screenshot that the build did make a difference for the arch, but system is set to 'none' instead of 'linux'.
   2010-04-15-093723.png (32.9 KiB)
Comment by Ronald van Haren (pressh) - Thursday, 15 April 2010, 14:51 GMT
ic, maybe there is a switch for that as well, don't know. I have to find some time to look into it.
Comment by Eric M. Gonzalez (tasker) - Thursday, 15 April 2010, 16:15 GMT
i'm sure there's a way i can force the build environment. i'll take a look into some things and see what i can come up with.
Comment by Eric M. Gonzalez (tasker) - Thursday, 15 April 2010, 16:52 GMT
autogen.sh --build=x86_64 --host=linux

did not work. i'm not finding much to go on, and my search-fu isn't the greatest.

it's great, i run ./autogen.sh --help and it passes that to configure, so i learned two things:

1) whatever autogen.sh is given, is passed on
2) configure's help didn't have much to offer

Loading...