mailing list of musl libc
 help / color / mirror / code / Atom feed
From: Gregor Richards <gr@purdue.edu>
To: musl@lists.openwall.com
Subject: Re: Draft: musl promo materials
Date: Sat, 14 Jul 2012 20:58:11 -0400	[thread overview]
Message-ID: <500215A3.2030704@purdue.edu> (raw)
In-Reply-To: <20120714174919.435d94ab@newbook>

On 07/14/2012 08:49 PM, Isaac Dunham wrote:
> On Sat, 14 Jul 2012 19:30:38 -0400
> Gregor Richards<gr@purdue.edu>  wrote:
>
>> On 07/14/2012 07:06 PM, Isaac Dunham wrote:
>>> On Sat, 14 Jul 2012 14:45:40 -0700
>>> Charlie Kester<corky1951@comcast.net>  wrote:
>>>
>>>
>>>> It would be good to include a list of apps that have been
>>>> successfully compiled with musl.  No need to list every such app,
>>>> just some representative ones that will help dispel any fears about
>>>> the library's ability to replace glibc in the most common uses.
>>> Somehow, listing compatible applications in PR does not
>>> sound very encouraging, until you can run the really huge
>>> suites/applications (I'm thinking of glibc-linked NVIDIA + Xorg, as
>>> was recently done with a patched version of musl, Google Earth, or
>>> native-built OpenOffice, Firefox/Chromium, the GIMP, Wine, Java,
>>> Mesa, GNOME, KDE, maybe Xfce, R, GRASS, BRL-CAD, FreeCAD, TeX,
>>> GDAL...the list isn't exclusive or a recommendation of the
>>>
> ...
>>> Isaac Dunham
>>>
>> GIMP and XFCE work. I'm working on Firefox, but I believe it
>> currently hits a bug in musl's dlopen, so I'm waiting on that fix. It
>> compiles, it just doesn't launch (hyuk). I routinely run the complete
>> pkgsrc suite through musl to see what works; the current test is
>> ongoing, but here's the results of the most recent one, which
>> unfortunately suffered from some bugs in my setup and so has some
>> false build failures:
>>
>> Tried 10444, depfail 4489, depok 5955, nobuild 2454, testfail 336,
>> success 3165 (53.1486%). Breakdown: http://sprunge.us/jgDO . MVD:
>> http://sprunge.us/cjRK
>>
>> (Tried = packages attempted, depfail = deps failed to build, nobuild
>> = didn't build, testfail = built but tests failed, success = all
>> tests passed, percentage is out of depok, MVD = most valuable
>> dependencies, of which I have since fixed security/p5-Crypt-Rijndael
>> and textproc/xmlrpc-c )
> php, sdl - see latest sabotage pkg for patches
I will, thanks.
> perl, mpg123, mutt... - broken setup or wrong config? I've built both
> w/out patching, but some are picky about the config.
Uhh, perl builds fine for me in pkgsrc? Not sure why you thought 
otherwise. Only its tests failed. mpg123 and mutt probably just build 
with more dependencies and end up exploding.
> heimdal-seriously, someone still wants Kerberos 4 ?!
> (heimdal is a Kerberos4-only implementation; this means only DES-based
> encryption, and MIT Kerberos has deprecated Kerberos 4)
The fact that it exists in pkgsrc does not indicate that it's wildly used.
> ap-auth-kerb - Presume this is MIT Kerberos; 1.8.x can be built with
> one small patch, but 1.10.x fails thanks to Redhat's broken code in
> libverto...
apache2 didn't build, X|-|-| means dependency failure.
> heirloom-* - I had to patch it (mainly makefile changes, one or
> two source changes) last time I tried, but that's several months ago.
I really don't care to get every package in pkgsrc building. I don't 
think anybody cares one iota if this works.
> cups - I think this wants libusb, which I haven't seen built...
Probably. I don't have the full log for this build any more.
>
> I'm wondering about how complete C++ support is, or whether
> __{BEGIN,END}_DECLS is overused--Fox, Qt, FLTK, and xpdf are all C++.
I haven't seen C++ fail significantly, plenty of things work.
>
> Overall, I'd expect you've got at least a couple hundred false failures,
> but I notice that Mesa and parts of TeX are building, which is pretty
> impressive itself.
There are also false failures just because my build setup was all borked 
before, so we'll have to hold off to see more realistic results.
>
> Status of packages mentioned:
> Builds:
> Mesa, GIMP, Xfce, TeX (partial)
> testfail:
> firefox
> buildfail/testfail:
> GNOME, TeX (partial)
> depfail:
> OpenOffice, R, Wine, Java, KDE, GRASS?
>
> Isaac Dunham
>

With valediction,
  - Gregor Richards




  reply	other threads:[~2012-07-15  0:58 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-07-13 18:12 Rich Felker
2012-07-13 19:16 ` Szabolcs Nagy
2012-07-14  6:40   ` orc
2012-07-13 23:30 ` Rich Felker
2012-07-14 19:05   ` Isaac Dunham
2012-07-15  0:01     ` Rich Felker
2012-07-14 21:45 ` Charlie Kester
2012-07-14 23:06   ` Isaac Dunham
2012-07-14 23:30     ` Gregor Richards
2012-07-15  0:49       ` Isaac Dunham
2012-07-15  0:58         ` Gregor Richards [this message]
2012-07-15  0:03     ` Rich Felker

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=500215A3.2030704@purdue.edu \
    --to=gr@purdue.edu \
    --cc=musl@lists.openwall.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.vuxu.org/mirror/musl/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).