loolSteveMcIntyre: Wow, what an agressive tone in response to your linker message15:11
Stskeepsi'd say it's been almost hard to avoid hearing about the linker path when doing armhf distro, it's come up in almost every single talk, presentation, etc15:15
markos_I don't see it being accepted, it took 20 years and still x86 distros can't agree on such things, I don't think arm will be any different15:40
markos_at least armv8 might be set on the right path from the start15:41
SteveMcIntyrelool: FFS, yes19:18
SteveMcIntyremarkos_: the x86 distros at least agreed enough about something as fundamental as the linker path19:19
infinitymarkos_: aarch64 will only get it right if we make sure the toolchain group working on it just defines things sanely before it's solidified upstream incorrectly.  Do we know if that's happening?21:36
infinitySteveMcIntyre: Also, that response from Dennis is just ridiculous.  Connect and Plumbers were the wrong places to discuss it, because it needs "community involvement"?  I'm sorry, but if every toolchain change needed democratic concensus from a community that largely doesn't understand or care about the changes being proposed, we'd never fix anything.21:43
infinity(I'm curious where the larger community involvement was in Fedora trying to completely redefine the FHS to work around their own lazy inability to implement things correctly)21:44
infinityOh, was that my out loud voice?21:44
infinitySteveMcIntyre: I'm increasingly convinces that we may end up having to ship the linker symlink in the LSB package, and force users to choose between multi-arch and Fedora compat, and I'm pretty wildly unhappy about that, given all the time we've put into discussing this with, supposedly, the right people.21:48
markos_infinity, oooor, you can forget fedora compat and force just multiarch21:56
infinityThat's more or less what we're doing right now.21:56
infinityBut this becomes a problem when fedora-arm actually manages to become RHEL-arm and third parties try to target armhf.21:57
infinity(ie: Oracle Java)21:57
markos_infinity, I know for a fact that oracle java use debian armhf to port java to hf21:57
infinityRight now, I've told them that the Debian/Ubuntu way is the Way and the Light, and that RHEL has promised to go that way.21:57
infinityAnd they're using our builds, yes.  Both Debian and Ubuntu.21:57
infinityDo you really think that will continue to be true if and when RHEL ships?21:57
markos_because I've been guiding their devs to port it21:57
markos_no, but at least Oracle will bitch to RH that they'll have to rebuild21:58
infinity(Also, if they're using Debian, that still has the compat link, so they still might be doing it "wrong")21:58
infinityWe really need to drop that link.21:58
markos_no, the compat is for old stuff21:58
infinityEh?  The link is just plain there.  It can't define who uses it. :P21:59
infinityAnd no one will know if their binaries are broken until it's gone.21:59
infinity(I just had this discussing with the lovely young man who just ported fpc to armhf)21:59
markos_I mean no new binaries -ie binaries built with shipped gcc/binutils- use the symlink21:59
infinityI pointed out the error, he pointed out that his incorrect path worked.21:59
infinitymarkos_: Lots of languages hardcode the path for their own nefarious internal use.22:00
infinityI wouldn't be shocked to find Java in that camp.22:00
infinityMuch as fpc is, though it doesn't need to be, since it COULD call out to gcc for final object linking when linking pascal to C.  But it doesn't.22:01
infinity(And that would be a much bigger fix than just fixing their paths, which we did)22:01
markos_it has its own linker!?!?22:01
markos_ugh sounds like pascal alright22:01
infinityThis shocks you? :)22:01
markos_it does22:01
infinityIt has its own linker for pascal->pascal linking, since none of that uses the C linker/loader at all, which is perfectly fine.22:02
infinityBut then they reuse that linker to link pascal->C22:02
infinityWhich makes some sense internally.22:02
infinityJust means this sort of thing is fiddly.22:02
markos_"free pascal" should rather be + " from users"22:02
markos_or rather free users from pascal22:03
markos_or sth ilke that22:03
markos_it's getting late :)22:03
infinityThere are a shocking number of people out there still madly in love with Pascal/Delphi.22:03
infinityI'm not one of them.22:03
infinityBut I never was.22:03
infinityI was doing C in high school when I was supposed to be doing Pascal.22:03
markos_was taught pascal back in the late 80s22:03
markos_can't say I liked it then22:03
markos_it was a nice step up from BASIC22:04
markos_but when I found C I couldn't really bother with pascal anymore :)22:04
infinityI mostly blame our own low level community, to be honest.22:04
infinityIt took us a long time to admit that C/C++ needed pretty IDEs like VB/Delphi.22:05
infinityAnd most of us still prefer text editors (I know I do), but we need to admit that some people prefer drag-and-drop.22:05
markos_I think the opposite22:05
infinityMSVC++ mostly got it right, but long, long, long after Delphi/VB did.22:05
markos_I had many arguments in the university, esp with CS students -I studied physics btw- where they asked me things ilke "ah so linux has visual c++ as well? but how do you use MFC?"22:06
infinityNot saying that drag-and-drop is the "right" way to program, certainly not from the "understanding what your application actually does" perspective, but if Borland had put as much effort into a nice C++ IDE as they did into Delphi, Delphi would have been DOA.22:07
markos_of course, I argued that it has *C++* and Visual C++ is just a name of the particulare IDE/compiler22:07
markos_but they could not understand how you can compile things without pressing a button, using cmd line gcc was totally unthinkable22:07
infinityYeah, entirely different argument. ;)22:08
markos_unfortunately I had it way too many times22:08
infinityI find people reliant on IDEs to be a serious problem, but we can't bury our heads in the sand and pretend those people don't exist, or that they're not important and influential in decisions.22:08
markos_they do, that's why it's nice to have eclipse or kdevelop, etc on linux as well22:09
infinityI mean, heck, Java tends to be more popular than C++ for students too, and it's cetainly not because of the stellar quality and robustness of JVMs.22:09
markos_and to be honest for big projects they really are worth it22:09
markos_eg I couldn't dream of writing a 100k java app on vim22:09
markos_but eclipse fits that role perfectly22:10
infinityThe only "dreams" of writing Java applications I have are nightmares.22:10
markos_100k SLOC that is22:10
broonie"eclipse" "nice"22:10
* markos_ was a j2ee developer for 5 years *shudder*22:10
markos_and then I return to the light22:10
infinityMy condolences.22:11
markos_thank you, writing C again was such a relief22:11
infinityI wonder if someone could write a JVM that breaks spec just enough for me to like the language.22:11
markos_though tbh there's nothing wrong with java, the language in its pure form, but sadly noone uses it like that22:11
infinityGetting rid of lazy GC would be high on my list.22:11
infinityOr, rather, letting me reliably trigger GC, I don't mind lazy in the default case.22:12
markos_I don't have a problem writing java again, and the money was really good, but I'd completely change the terms22:13
infinityI had an argument a few months ago with my friend's prof about why an assignment he gave his student about flushing deleted objects was an exercise in futility and fantasy.22:13
markos_it actually works -to an extent22:14
infinityIn the end, he never understood what I was saying, and my friend wrote his assingment to refcount every object, then spin on waiting for the refs to go away, then say "look, it's flushed".22:14
markos_not a very efficient way to do gc22:15
infinityWell, there's no way in Java to actually make objects go away reliably.  Which is generally fine, if you understand that and don't rely on it.  Lazy GC is a great concept, right up until you don't want it.22:15
markos_gc is a must if you use an application server22:15
infinityOr, in that odd case, have someone who insists it can be forced.22:15
markos_the problem is that there is no alternative other than doing it on your own22:16
markos_and that will definitely break lots of java stuff :)22:16
infinity(He even had some fantasy "GC flushing" method he'd written as an example for the students which, as far as I could tell, he'd only fooled himself into believing worked because it took time, and time is all you need to eventually trigger GC)22:16
infinityHe found my analysis of his brilliant code somewhat insulting.22:17
infinityThis is why I can never go back to school. :P22:17
markos_there is no escape from GC, you either do it or you don't, saving time in the beginning will only mean you will waste so much time in GC sometime in the future all in one go22:17
infinityAt any rate, I like the predictability of C doing exactly what I tell it to, and when.22:18
markos_which might be completely fatal in some case22:18
markos_even C++ is better, because you know the life of its object22:18
infinityWell, the nice thing about C++ is that, no matter how many fancy higher level tricks you pull, you can always remind yourself "it's just C", and if you really want/need to block on freeing a chunk of memory, you can just do that.22:20
* infinity wonders idly why C++ wasn't called ++C22:22
markos_because tab completion doesn't work on ++g :)22:23

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!