here it is: I think this can be useful also for Eric's sources (I generated it over his git tree)...

Attached Files

0001-l-ncurses-change-the-.so-soft-links-to-include-ltinf.patch.txt (1.6 KB, 28 views)

Hi Ponce

I noticed that trick, it is used in Fedora's ncurses package too. But I do not understand what it does, and I do not apply stuff I can not rationally explain ;-) Is there documentation about the idea behind writing INPUT in a shared object file?

Eric

Yes, thank you very much Ponce, this is very interesting stuff! I also wonder if it will defeat the purpose of splitting off libtinfo in the first place (i.e. producing smaller binaries). I'll look into this some more in the morning. Thanks for all your work on this!

Do you have a script or anything that produces the installer you built for slackwarearm? I might take a look at it and see if the size of the installer can be trimmed down a bit while still being functional

Yeah, it looks like debian and fedora are both using these ld scripts as workarounds for ltinfo failing to link, and fedora is using "AS_NEEDED" -- I'm assuming to avoid overlinking ltinfo. This approach appears to break linking against ncurses with ld.gold, though I'm not aware of any packages in Slackware that are using the gold linker. The folks at Gentoo feel this is a hack and linking against ltinfo should be fixed in all of the packages individually. Based on what I've gleaned from some opensuse threads, they have patched ncurses (but I haven't find the specific patch yet) and have fixes for other packages on a case-by-case basis.

links:
https://patchwork.kernel.org/patch/2179341/
http://lists.opensuse.org/opensuse-p.../msg00106.html

some more info on rationale behind the libtinfo split-out:
https://enc.com.au/2011/09/30/ncurses-library-split/

Using ld scripts does feel a bit like an ad hoc solution rather than a permanent fix. My gut instinct is to retreat to the safety of upstream Slackware, and put libtinfo back in libncurses for the time being. That said, it sounds like the ncurses developers are heading more in the direction of splitting it out.

OpenSuse uses the same INPUT AS_NEEDED approach: https://build.opensuse.org/package/v...penSUSE%3A12.3

I agree that I may have to revert my decision to split out libtinfo. However that will not happen in my ARM port sources too soon, due to lack of time (a lot of recompiling is required when I revert that modification).

Eric

Ahh, you're right - the info I was reading must have alluded to that fix rather than a patch to the ncurses sources, or they changed things subsequently. Dang, I had my hopes up for a patch lol.

I hear ya on the time involved to roll that back. For the time being, I think my approach will be to implement the AS_NEEDED approach in ncurses to retain compatibility with my existing packages that were compiled against split libraries while also avoiding lots of build failures for anyone who is trying to compile additional packages (or the kernel, in ponce's case). If/when you implement a change in your port, I'll adopt it and rebuild as necessary. I'd like to maintain as much compatibility with your source tree as possible.

I think the less harmful fix should be to link libtinfo directly in libncurses and libncursesw at ncurses compile time, but the build system doesn't allow this and I can't see -cause I'm noob- an easy way to patch it (besides the substitution of the .so link with a linker script): if you specify a LIBS=-ltinfo variable (or by LDFLAGS) then all the libraries that are built wants to link to that at compile time, libtinfo itself included, and this, besides going conceptually against the split, breaks the build because libtinfo gets truncated at linking time.

pfft. If you're a noob, I'm not sure what that makes me, but it must be pretty bad :P

I applied the changes to my local ncurses.SlackBuild, rebuilt it, and tested to verify that a package that previously required 'LDFLAGS="-ltinfo"' now builds fine with out it. I'll sync my local repo with the server tonight. Thanks again!

Any of you guys are going to try Parallella?

Ahau, I prepared a kernel (with bfq and aufs) on your platform (modified build scripts derived from David's ones are in the "sources" folder)

http://ponce.cc/slackware/testing/raspi-extras-armv6/

Ponce, that is awesome, thank you so much! Do I have your permission to pull these files and sources into my tree?

I've been busy prepping stuff for Porteus 2.1 but will definitely be returning to add and update to slackwarearmv6

the original sources are of David Spencer, I just forked his stuff for the new kernels and added something: for me it's ok, but you better ask him

Hello fellas,

I have bought a raspberry pi b-model 5 months ago, with 512 MB RAM, and due to overworking months that followed i had not free time to play with it.
Until today , although with no luck and here is where i need your help.

I follow the guide from here using a class 10 8GB card SanDisk.
The problem is that device no boot and an with main orange color appears.
Can anyone help me to resolve this issue????

Thanks

if you're sure your SD card is supported, follow the instructions from here

http://ponce.cc/slackware/testing/ra...ADME.installer

and grab this installer for the task

http://ponce.cc/slackware/testing/raspi-extras-armv6/

The newer boards might require a more up to date firmware. I had just bought a board two months ago, and all the images listed through the slackware arm site for raspi did not boot for me. Ponce's image saved me since I did not know what was wrong either. His image is more up to date and works. So follow his instructions. It's good to see he just updated his image again too. I was going to recommend to update your kernel and firmware, but since he just did that will save you some time.