IRC logs for #openttd on OFTC at 2018-08-08
⏴ go to previous day
03:09:35 *** Supercheese has joined #openttd
05:53:56 *** haudrauf has joined #openttd
06:07:47 *** Supercheese has joined #openttd
07:21:06 *** peter1138 has joined #openttd
07:21:06 *** ChanServ sets mode: +o peter1138
07:29:31 *** andythenorth has joined #openttd
08:10:27 *** andythenorth has joined #openttd
09:44:30 <planetmaker> I consider that a bit... unfortunate
10:19:56 <LordAro> i would suggest removing
10:23:47 *** andythenorth has joined #openttd
10:24:44 <planetmaker> yeah... having entries marked as "used in neither TTDP nor OTTD" is... kinda pointless.
10:27:06 <andythenorth> it does need a solution though
10:27:11 <andythenorth> patchpacks are the future
10:27:31 <planetmaker> but that is not the solution IMHO. Or it will be very quickly an utter clutter
10:27:34 <andythenorth> fragmenting the grfspec without a plan is unfortunate
10:28:08 <planetmaker> that is supposed to be OpenTTD's canonical specs. No point in having it feature the specs of every patch pack ever was and will be
10:28:21 <planetmaker> or better: ideas of what could be
10:28:37 <planetmaker> that's why frosch made the station thing on his own... and not there
10:29:06 <andythenorth> what options can we think of?
10:29:13 <planetmaker> and are patch packs with everyone with its own specs really the future?
10:29:13 <andythenorth> other than a big table listing what implements what
10:29:27 <planetmaker> that will lead to fragmentation. And no grf working anymore
10:29:38 <planetmaker> I doubt it, seriously
10:30:12 <andythenorth> current vision is stable core + patchpacks
10:30:20 <planetmaker> they usually live as long as a single author contributes
10:30:49 <andythenorth> I think this hinges on the relationship of the content APIs to 'stable core'
10:30:51 <planetmaker> so they can do all the PP they want. But we cannot maintain every PP's specs there. Nor do we want that really, I think
10:30:58 <andythenorth> I don't want that no
10:31:03 <andythenorth> just to be clear
10:31:19 <andythenorth> I also doubt many people are going to fork nml
10:31:32 <planetmaker> I doubt it, too, yes
10:32:04 <andythenorth> so is this a spec definition problem, or just a docs problem?
10:32:10 <andythenorth> they are subtly different
10:33:12 <planetmaker> if we progress this path, the specs WILL become cluttered with cruft which make future development of the grf specs utterly more crappy and unconsistent than already necessary
10:33:25 <planetmaker> it's a docs problem for the PPs
10:33:27 <andythenorth> and that is a low baseline already :)
10:33:33 <planetmaker> but a specs problem for OpenTTD itself
10:34:04 <andythenorth> I have proposed moving away from wiki for API docs
10:34:09 <andythenorth> but frosch was very -1 to that
10:34:17 <andythenorth> NoGo isn't a wiki though
10:34:43 <planetmaker> yes... But generating that from in-source docs doesn't work as nicely as the wiki is now
10:35:08 <planetmaker> The wiki has so much more than a doc generator (easily) generates. That'd be a hell lot of work for very little benefit
10:35:17 <andythenorth> is there any difference between API spec and 'guides to newgrf'?
10:35:18 <planetmaker> or maybe even negative benefit
10:35:44 <planetmaker> there likely is some. But it's a fluent transition in the wiki as-is.
10:36:28 <andythenorth> ok, well in that case, it's inevitable that PP-only features will be documented in wiki
10:36:37 <andythenorth> then it needs an editorial policy
10:37:14 <planetmaker> well. Depends on how you define the scope of that wiki. Whether it is supposed to be the canonical one. Or cover all the non-official fringes
10:37:32 <planetmaker> IMHO it's the canonical documentation. And not the fringe one.
10:38:14 <andythenorth> I have no argument against that :)
10:38:34 <planetmaker> we should ask frosch and alberth when they're here what they think
10:38:49 <planetmaker> can you try to remember to bring up that topic? :D
10:38:55 <andythenorth> I am guessing they hope someone else sorts it out :)
10:39:15 <planetmaker> but it will deteriorate quickly, if we have this start pass
10:39:42 <planetmaker> the later, the worse
10:51:26 <peter1138> If spec additions don't go in the wiki, where should they go?
10:51:52 <planetmaker> the question is which spec additions?
10:52:08 <peter1138> How did TTDPatch feel when we started adding stuff?
10:52:39 <Wolf01> Ok, but we were one, not 16
10:52:50 <Wolf01> With 16 different specs
10:52:51 <peter1138> I think the fact that is it not official needs to be marked more clearly.
10:53:09 <LordAro> maybe a dedicated page for a particular patchpack?
10:53:14 <Wolf01> The problem is that we don't have anything like "is this grf feature supported?"
10:53:20 <planetmaker> the wiki will be worthless, when everyone adds his favourite properties, variables etc everywhere
10:53:22 <peter1138> I'm also torn. I do dislike it as well, but actually, we did the same :p
10:53:23 <LordAro> "this are the additions/changes/deletions for this version"
10:54:02 <peter1138> For stations, what is 1A? I've never heard of it o_O Did I write it?
10:54:32 <peter1138> (And I dislike 1B because it reinforces the stupid 8 tile limit)
10:55:19 <planetmaker> might be that frosch wrote 1A. But not sure
10:56:01 <peter1138> Lol at bridges. Got to use GRM. Haha.
10:56:14 <planetmaker> I never figured how GRM even works
10:56:28 <planetmaker> so I don't even know what that means :P
10:57:48 <peter1138> Use action D (IIRC) to reserve an ID, and then use action 6 to *modify the raw data* of the proceeding action, so that it uses the reserved IDs.
10:58:20 <peter1138> It is very much a kludge for the lack of dynamic ID allocation.
10:58:47 <planetmaker> sounds... pretty cruft and unnecessary
10:58:47 <peter1138> I guess bridges don't have action 1,2,3, so they came up with this hack :S
10:58:53 <planetmaker> for today's standard
10:58:54 <peter1138> planetmaker, it's very much ttdpatch-like.
10:59:09 <peter1138> I'd guess that NML doesn't use it, or at least doesn't expose it.
10:59:21 <planetmaker> NML doesn't yet do bridges. Nor stations :|
10:59:32 <planetmaker> and no, NML doesn't expose GRM
11:01:51 <peter1138> I guess we need the specs to be in git, so they can be forked and branches ;)
11:02:37 <planetmaker> that's what andy also suggested. I recon it's a LOT of work to move that
11:08:17 <andythenorth> I am not really prepared to do the work to move specs to git :)
11:08:24 <andythenorth> so I can't really ask other people to do it :)
11:09:23 <andythenorth> but we'd need to be able to auto-generate, and that's not happening
11:09:32 <peter1138> planetmaker, yeah. "Unofficial" though.
11:40:07 <reldred> 'it's very much ttdpatch-like' you know, you're not wrong, but I still look back at the ttdpatch source absolutely amazed that whole fucking thing worked. And worked as well as it did for so long.
11:41:11 <reldred> from a purely academic point of view it was almost a work of art
11:43:12 <reldred> I do not miss working in asm though
11:44:51 <peter1138> I don't think it's a bad design for the limitations that were there.
11:45:42 <peter1138> It amazes me how you all managed to find the hooks and patch jumps etc in. It's black magic voodoo stuff, tbh.
11:50:21 <reldred> yeah, I really shouldn't comment too much on the guts of it since I never really committed a patch all on my onesies but josef helped me learn ida pro back in the day, figure out how the trains determine what tracks they're allowed to run on, etc.
11:50:51 <reldred> I wanted to repurpose maglev for like an urbna rail type thing
11:51:03 <reldred> and wanted to be able to hop off one set of tracks onto another
11:51:20 <reldred> But as a teenager seeing under the hood and learning that shit was unreal
11:51:29 <reldred> I never did become a programmer but learning that shit shaped my career
11:58:04 <SpComb> TTDPatch would have been pretty harecore
11:58:20 <SpComb> self-modifying x86 assembler
11:59:23 <reldred> A lot of it was driven from paranoia over getting sued
11:59:38 <reldred> So it only ever attacked the executable when it unpacked to ram
11:59:58 <reldred> So many things would have been so much easier modifying the exe directly
12:01:25 <reldred> The sheer amount of time you'd spend just stepping through instruction by instruction in ida pro furiously scribbling notes just to figure out something simple, let alone how in the hell josef and oskar and everyone else figured out the really hard shit
12:02:59 <SpComb> I wonder if hand-written asm would be easier or harder to reverse-engineer than compiler-generated asm
12:03:34 <reldred> hmmm, once it goes through the linker it looks nothing like what you originally wrote
12:06:39 <reldred> and theyall behaved slightly differently, had additional features, etc
12:10:34 <reldred> oh neat, my plane is here, ttyal
12:12:53 *** chomwitt has joined #openttd
13:17:12 *** andythenorth has joined #openttd
13:47:24 <Eddi|zuHause> <planetmaker> yeah... having entries marked as "used in neither TTDP nor OTTD" is... kinda pointless. <-- i disagree. the idea here is that TWO patcpacks are now offering this, and they need some coordination.
13:48:05 <Eddi|zuHause> mainly, the newgrf authors need some security that the things are not being reused for other stuff
13:48:24 <Eddi|zuHause> otherwise they will never develop newgrfs using these features
13:49:09 <planetmaker> and that's the point. That makes the specs... even worse to handle than they are now
13:49:52 <Eddi|zuHause> the specs are NOT for representing the current implementation of master
13:50:12 <planetmaker> I wouldn't want to give the guarantee that it's not re-defined. And yes, that is exactly what they DO
13:51:10 <Eddi|zuHause> the specs were always this separate cross-platform agreement between developers of different projects (TTDP, OTTD, NewGRFs)
13:51:27 <planetmaker> adding there random additions w/o any means to find out which apply to your current version you run - makes the specs worthless
13:52:01 <planetmaker> that was the case before. With the PPs that's not the case. Thus you'll get NewGRFs which - seeming randomly - don't work. W/o any means for a user to see why
13:52:10 <Eddi|zuHause> the detection whether the version provides this piece of specs is a problem, yes
13:52:55 <Eddi|zuHause> the versioning needs also a solution in master, because there is no incremental revision anymore
13:53:03 <planetmaker> And the point is to indeed document the specs for OpenTTD/master
13:53:30 <planetmaker> if that's not the point, we can well skip it and abandon it.
13:53:36 <andythenorth> my assumption was that the wiki documents TTDP as well?
13:53:41 <planetmaker> wishlists go to general wiki
13:53:42 <andythenorth> I know that's now almost dead
13:53:52 <Eddi|zuHause> it's not a wishlist
13:54:06 <Eddi|zuHause> it's still tracking what's actually implemented _somewhere_
13:54:13 <andythenorth> I always treated it as a document for a cross-platform API, which isn't 100% implemented on either platform
13:54:31 <andythenorth> maybe that was wrong, or needs to change
13:54:39 <Eddi|zuHause> i said in the JGR thread already, it CANNOT detoriate into a wishlist
13:55:01 <andythenorth> there's already a process for putting up wishlists
13:55:22 <Eddi|zuHause> but it must be lenient enough to handle this upcoming issue, that several patchpacs must coordinate their implementation of the same feature
13:55:33 <planetmaker> ^^ that's also implemented somewhere. So we add every branches fiddling there now?
13:55:49 <Eddi|zuHause> that's a working proposal
13:55:55 <planetmaker> "must coordinate". But what will happen that it's cluttered by bad design decisions
13:56:04 <andythenorth> this is a really hard problem :)
13:56:16 <planetmaker> and that's why it has to continue?
13:56:49 <planetmaker> "let's add 3 more bridge types".
13:56:59 <planetmaker> without making it a 1st-class feature. That's exactly that
13:57:35 <Eddi|zuHause> planetmaker: changing the number from 13 to 16 is a one-line patch, reworking the bridge feature is a year-long task
13:57:47 <Eddi|zuHause> planetmaker: they are not blocking each other
13:58:09 <Eddi|zuHause> we're randomly deciding to up cargo numbers and railtype numbers here
13:58:20 <Eddi|zuHause> why make such a fuzz about a tiny change like that?
13:59:03 <Eddi|zuHause> i'd say you'd be quicker just backporting that same commit from JGR/NMF patchpacks
13:59:42 <planetmaker> that'd be adding bad to worse. As they are NOT implemented as the other 13.
13:59:49 <planetmaker> at least it's stated differently
14:01:09 <planetmaker> and why is the NRT "not implemented". But another patchpack is? What's the difference really between a patchpack and a "concept"?
14:01:12 <peter1138> Because the other 13 are hardcoded already.
14:01:22 <peter1138> I wouldn't want someone to hardcode an additional 3.
14:02:00 <Eddi|zuHause> planetmaker: a patchpack is something different, because it's something semi-stable (ideally)
14:02:11 <Eddi|zuHause> planetmaker: a patch like NRT is still very fluid
14:02:29 <peter1138> Does this "town road" flag exist in NRT?
14:02:56 <Eddi|zuHause> dunno, we discussed it a bunch of times
14:03:38 <andythenorth> somewhere a repo knows
14:03:57 <peter1138> I know it was discussed yesterday but not if it exists.
14:04:01 <Eddi|zuHause> well, i've been proposing it from the very beginning
14:04:16 <Wolf01> <peter1138> Does this "town road" flag exist in NRT? <- yes, supermop provided a grf for that and I implemented it
14:06:12 <Wolf01> TODO: properly store the chosen town road, better algorythm to choose between the falgged roadtypes, handle the changing of the roadtype in different eras or when new flagged roadypes will be available
14:07:46 <Eddi|zuHause> you could provide a "global" callback so the newgrf can return a roadtype suggested for towns
14:08:06 <Eddi|zuHause> i believe we have this kind of stuff already somewhere
14:08:23 <Eddi|zuHause> for AI station selection or something
14:08:54 <peter1138> Someone will want to mix road types.
14:09:10 <peter1138> Hmm, as they do stations. Must be solvable.
14:09:12 <Wolf01> <Eddi|zuHause> you could provide a "global" callback so the newgrf can return a roadtype suggested for towns <- Wouldn't that mean that every town will have the same roadtype?
14:09:13 <Eddi|zuHause> yeah, last definition wins
14:09:33 <Eddi|zuHause> Wolf01: yes, why not?
14:09:54 <Eddi|zuHause> Wolf01: well, you can still decide when the town runs that callback
14:10:05 <peter1138> See, if you want just some towns to have an "old town" area that's still cobbled...
14:10:19 <Wolf01> That could be handled with town zones
14:10:19 <peter1138> Is that a town choice or a newgrf choice?
14:10:58 <Eddi|zuHause> that's a question of whether the town runs an "upgrade existing roads" feature
14:11:07 <Wolf01> But what if in 1800 you want 50% of towns to have dirt road and other 50% cobble road?
14:11:22 <Wolf01> Maybe that could be decided by town size too
14:11:42 <Wolf01> Everything via newgrf, because the game doesn't know about dirt and cobble
14:12:02 <peter1138> How often do towns expand? Do you want a callback being called every time it does?
14:12:07 <Eddi|zuHause> add something to extra_callback_info1/2
14:12:37 <Eddi|zuHause> the newgrf could also check PARENT to get town info
14:12:42 <Wolf01> The callback to change type should be called only when new roadtypes become available
14:12:56 <Eddi|zuHause> i don't think it works that way
14:13:11 <Eddi|zuHause> the town should periodically run the callback, like once a year
14:13:20 <Eddi|zuHause> and store the result
14:13:37 <peter1138> And don't try to calculate it on load :D
14:13:48 <Eddi|zuHause> towns don't necessarily jump on every "new roadtype" hype :p
14:15:02 <peter1138> You could, of course, do both. Yearly, and if a new roadtype is available.
14:15:28 <peter1138> That beats calling it every time.
14:16:05 <peter1138> What's the return value?
14:16:15 <peter1138> "What road type to build" is pretty terrible idea.
14:17:51 <peter1138> City connections are vital I think but not directly related.
14:18:21 <peter1138> Roads are pretty expensive and should just exist, preferably in shitty slow windy form.
14:21:26 <Eddi|zuHause> at some point i thought city connections could be handled by a game script
14:21:58 <peter1138> Problem with game script is there's just one of them.
14:22:10 <peter1138> Which kinda makes sense for the purpose of what it is.
14:22:28 <peter1138> But removes flexibility.
14:23:50 <Eddi|zuHause> so the road connections would be a library, that game script authors would be encouraged to include. but you'd get dozens of requests that gamescript X should include them
14:24:00 <Eddi|zuHause> it's not a perfect solution
14:29:39 <Wolf01> Yeah, I fucked up C:S... citizens started to get sick and placed 1 more hospital, now I'm losing $1000
14:33:50 <SpComb> sounds like your sewage is most likely spilling over into your water intake
14:34:06 <SpComb> check the pollution map
14:34:24 <SpComb> it causes rapid population decline :)
14:34:28 <Wolf01> Nah, the entire city is sick and I don't have any other problem than RAIN
14:35:45 <Wolf01> Lost 20% of population so far and expenses are rampaging :(
14:40:41 <Wolf01> Ok, maybe a bit the water...
14:43:31 <SpComb> your fresh water intake isn't supposed to be brown :P
14:45:14 <Eddi|zuHause> the water pump alters the water flow
14:46:20 <Eddi|zuHause> also, you can probably turn off the second hospital to save money
14:46:25 <Wolf01> I moved the water pump on the other edge of the map, upstream
14:46:52 <SpComb> yeah, toggle the hospital off and wait for it to fix itself
14:47:23 <Wolf01> I did better, reloaded, moved the water source, no more pestilence
14:47:40 <SpComb> my first city survived its water poluttion episode :)
14:50:00 <Wolf01> How do I set the industry as "farms"? The districts tool seem to be the one, but I can't understand how to use it
14:50:26 <Eddi|zuHause> 1) you draw a district
14:50:40 <Eddi|zuHause> 2) in the district tool you have tabs, select the industry one
14:50:58 <Eddi|zuHause> 3) then you can select the industry focus "farms" and click on the district
15:25:21 <Eddi|zuHause> coming back to the specs discussion: OpenTTD can happily live without the specs, the target audience for the specs is the newgrf authors. ideally, we would have some independent committee that prevents the specs from detoriating. but just because it isn't implemented in master is not an immediate reason to exclude something from the specs
15:27:06 <Eddi|zuHause> we do need a solution for the versioning, though
15:40:52 *** ToBeFree has joined #openttd
15:43:14 <Wolf01> Mmmh, is it possible to upgrade a T junction to a cloverleaf?
15:43:32 <Eddi|zuHause> junctions are made up of individual road sections
15:43:38 <Eddi|zuHause> they are not monolithic
15:44:34 <Eddi|zuHause> the builtin junctions never seem to really fit anywhere, though
15:44:38 <Eddi|zuHause> so i always build my own
15:44:47 <Eddi|zuHause> which is a bit fiddly
15:56:45 *** Alberth has joined #openttd
15:56:45 *** ChanServ sets mode: +o Alberth
16:15:09 <LordAro> place your bets on memory or icu
16:20:38 <nielsm> is there any timeline for 1.9 release yet?
16:21:06 <nielsm> if not I'd almost suggest releasing an 1.8.1 that just hasuniscribe for windows and fps-meter for performance debugging backported
16:21:13 <Eddi|zuHause> somewhere between "no" and "same as always"?
16:21:59 <Eddi|zuHause> i'd say yes to backporting the icu stuff, and no to the fps meter for a 1.8.1
16:22:20 <LordAro> frosch usually deals with these things
16:22:46 <LordAro> it'd probanly be a idea to work out how releases are going to work now that git is a thing
16:23:30 <Eddi|zuHause> first step would be getting a compile farm to run :p
16:32:56 <andythenorth> I could make the binaries locally? o_O
16:32:59 <andythenorth> oh wait, I can't :)
16:33:02 <andythenorth> they don't build
16:46:07 <andythenorth> can I hack .configure?
17:50:34 *** Gustavo6046 has joined #openttd
17:52:23 <Gustavo6046> got to go for school, bye
17:57:07 *** Wormnest has joined #openttd
18:42:59 *** frosch123 has joined #openttd
19:17:37 *** ChanServ sets mode: +v tokai
19:36:57 *** andythenorth has joined #openttd
19:42:59 <andythenorth> well I could VM compile
19:43:10 <andythenorth> I could run whatever TB has that produces mac binaries
19:43:37 <frosch123> just add some -liconv in the right place
19:43:43 <lethosor> you're definitely doing a 64-bit build of everything, right?
19:44:16 <lethosor> (make sure you have libiconv installed as well)
19:46:23 <andythenorth> nope, same error
19:48:49 <andythenorth> does libiconv need adding to the wiki as a dep?
19:50:04 <andythenorth> I love an OS upgrade :(
19:52:41 <lethosor> are you building on 10.13? I wish I could help, but I built master on there yesterday and a few days before with no issues...
19:54:25 <lethosor> have you tried a clean build?
19:54:36 <Eddi|zuHause> i feel like missing iconv is something that should have been handled by configure, but this could be a side effect of your configure hacking
19:55:10 <Eddi|zuHause> like, it's running through wrong paths and setting wrong defines
19:55:43 <lethosor> iconv is in /usr/lib for me so it's likely not something that could be missing
19:56:32 <frosch123> iconv is pretty much a standard library
19:57:10 <frosch123> also, andy did have the header files, so it is installed
19:57:25 <andythenorth> installing libiconv didn't change the error
19:57:51 <andythenorth> I didn't follow the instructions right
19:57:53 <andythenorth> "This formula is keg-only, which means it was not symlinked into /usr/local,
19:57:54 <andythenorth> because macOS already provides this software and installing another version in
19:57:55 <andythenorth> parallel can cause all kinds of trouble."
19:57:56 <Eddi|zuHause> i recently had an issue where something woudln't link because i had a .so.1 file, but no symlink from .so to .so.1
19:58:03 <andythenorth> so that's telling me I should add it to my path
19:58:24 <andythenorth> so I need to edit .bash_profile to add libiconv?
19:58:51 <Eddi|zuHause> you've taken a bunch of wrong turns in your rabbit hole
19:58:55 <lethosor> andythenorth: ls /usr/lib/libiconv.dylib
19:59:35 <andythenorth> that returns /usr/lib/libiconv.dylib
19:59:54 <Eddi|zuHause> andythenorth: you might try setting LDFLAGS, maybe
20:00:24 <frosch123> there is also a configure option for iconv
20:00:24 <lethosor> you shouldn't have to do anything special for libs in /usr/lib
20:00:25 <Eddi|zuHause> but this is still several wrong turns deep
20:01:11 <lethosor> what does "file objs/release/os/unix/unix.o" say?
20:01:53 <andythenorth> objs/release/os/unix/unix.o: Mach-O 64-bit object x86_64
20:02:06 <andythenorth> is it plausible that hacking ./configure has left flags unset?
20:16:39 *** Progman has joined #openttd
20:44:42 *** ToBeFree has joined #openttd
20:45:33 <andythenorth> and weird wide angle
20:58:29 <frosch123> there are way more bussed and trams than pedestrians
21:20:50 <andythenorth> lethosor: can you build current tip of OpenTTD?
21:20:57 <andythenorth> and what's your clang version? o_O
21:22:41 <lethosor> probably, because the only thing that changed when I pulled was src/lang/dutch.txt
21:23:01 <lethosor> Apple LLVM version 9.1.0 (clang-902.0.39.2) Target: x86_64-apple-darwin17.6.0
21:23:15 <lethosor> are you certain that you're using clang and not something else?
21:23:35 <andythenorth> I'm not certain no
21:23:38 <lethosor> (and yes, it built fine)
21:25:00 <andythenorth> deps from macports or brew?
21:25:16 <lethosor> try "touch src/engine.cpp && make engine.o VERBOSE=1"
21:25:21 <lethosor> (ignore the really long line)
21:25:36 <lethosor> I use homebrew but didn't have to install anything specifically for this
21:26:11 <andythenorth> that command generates warnings, no errors
21:26:46 <lethosor> ok, what's the compiler command?
21:27:06 <lethosor> "touch src/engine.cpp && make engine.o VERBOSE=1|grep engine.o" should give just that line
21:27:53 * andythenorth looking in the output
21:28:24 <lethosor> (really I just care about the program being run - you don't have to paste the whole thing with paths and all)
21:29:50 <lethosor> yeah, "g++" is probably no good. Try export CXX=clang++, export CC=clang, then rebuild
21:32:21 <andythenorth> so was that using g++ as the default compiler? :o
21:32:27 <andythenorth> or do I misunderstand?
21:32:51 <andythenorth> how would that happen on a mac clean from Apple?
21:33:05 <lethosor> because g++ is actually an alias for clang that behaves differently sometimes
21:33:16 <andythenorth> so that's why the errrors still report clang?
21:33:51 <andythenorth> ok so with those exports
21:34:24 <andythenorth> - make now gets through the build where it was failing on economy.cpp (without ../configure being hacked)
21:34:29 <andythenorth> - but the linker failure still happens
21:34:38 <andythenorth> which is interesting
21:35:19 <lethosor> can you make VERBOSE=1 and send the linker command?
21:35:41 <andythenorth> I should twitch stream this and you can laugh at my lack of knowledge as I type
21:36:01 <lethosor> hey I don't really know what's going on either
21:37:17 <andythenorth> if I understood correctly :P
21:38:02 <lethosor> still the iconv errors? the command doesn't have -liconv - maybe add that manually?
21:38:40 <andythenorth> that was frosch123's suggestion too
21:41:20 <lethosor> oh, and it didn't work? Anyway, I tested building with "g++" (Apple's alias) and it worked, although I *think* I got more warnings than usual. I'm building with clang now and will compare linker commands once it's done
21:41:51 <andythenorth> -liconv will probably work, I just can't figure out how to add it :)
21:42:45 <lethosor> oh. well one (ugly) way is to copy the last command you sent (starting with clang++ -rdynamic) and add -liconv at the end
21:43:06 <lethosor> although that might require you to be in another folder
21:43:33 <frosch123> check config.lib and find a nice place with LDFLAGS
21:43:35 <michi_cc> LDFLGAS="-liconv" ./configure maybe?
21:44:34 <lethosor> yeah, that's probably better than editing configure-related files again
21:47:04 <andythenorth> let's try from clean to be sure
21:48:40 <andythenorth> I need to be cast iron on the repro and fix
21:52:28 <andythenorth> how do I reset 'export CXX=clang++' so I can repro the original issue?
21:52:35 <lethosor> (also your libpng is 1.6.35 and mine is 1.6.34, heh)
21:52:43 <lethosor> unset CXX and unset CC should do it
21:52:57 <lethosor> alternatively you can export CC=gcc, export CXX=g++
22:09:10 <michi_cc> andythenorth: CC=clang CXX=clang++ LDFLAGS="-iconv" ./configure should work, too, and doesn't need cleanup.
22:10:23 <lethosor> true. I mean, it'll get cleaned up when you exit the shell in any case
22:16:11 <andythenorth> that one's not working
22:16:30 <andythenorth> linker error is back
22:17:09 <lethosor> -liconv, not -iconv (michi_cc)
22:56:50 <glx> hebrew.lng + ICU, I guess it's easy to blame ICU
23:05:27 <andythenorth> nielsm: eh I have a working build now :)
23:05:31 <andythenorth> so nml is plausible again
23:07:34 *** Supercheese has joined #openttd
23:10:28 *** andythenorth has left #openttd
continue to next day ⏵