_whitelogger has joined ##openfpga
<whitequark> _whitelogger: o/
<whitequark> yep, works
<azonenberg> whitequark: Trying to figure out some quirks of the GNU linker
<azonenberg> in particular, suppose i have multiple LD installs on a given machine
<azonenberg> For example...
* whitequark is an involuntary expert on the quirks of the GNU linker
<whitequark> go on
<azonenberg> /usr/bin/mips-elf-ld
<azonenberg> /usr/bin/arm-linux-gnueabihf-ld
<azonenberg> /usr/bin/ld
<azonenberg> I've found those by searching for $PATH files called "ld" or $TRIPLET-ld and then running -version to sanity check they're actually linkers
<azonenberg> and determined that they happen to be GNU linkers in particular
<azonenberg> Now I have a bunch of object files that i generated for some triplet
<azonenberg> Say, i386-linux-gnu (note that my host arch in this example is x86_64-linux-gnu)
<whitequark> triple*
<azonenberg> Which linker do I use?
<azonenberg> And how do i know?
<whitequark> well
<whitequark> there's no really good way to know :)
<azonenberg> i mean common sense tells me as a user that if i am on an x86 box i use the default linker
<azonenberg> in particular...
<azonenberg> ld -m -V prints supported linker emulations
<azonenberg> but this does not directly translate to GNU triples
<whitequark> so with GNU binutils, you can use ld built for a $ARCH-$OS-$VENDOR-$ENV for any triple that has the same $ARCH
<azonenberg> Which are what i use when IDing architectures for things like selecting a compiler
<whitequark> the rest of it does not matter*
<azonenberg> So you're saying if i take the $ARCH out of the triple from the compiler
<whitequark> * it sort of does, but if you have it built for say a Linux triple, you can pretend that it doesn't
<azonenberg> and ld -m -v displays that
<azonenberg> i'm good?
<whitequark> so your system ld can link PE executables
<whitequark> yes
<whitequark> also, with x86
<whitequark> as a special case
<whitequark> any iX86 and x86_64 triples are ok
<azonenberg> azonenberg@skipjack:/nfs4/home/azonenberg/code/splash-build-system/build$ ld -m -v
<azonenberg> Supported emulations: elf_x86_64 elf32_x86_64 elf_i386 i386linux elf_l1om elf_k1om i386pep i386pe
<azonenberg> ld: unrecognised emulation mode: -v
<whitequark> where did yo uget the -m -v
<azonenberg> Whoops
<azonenberg> should have been -V
<azonenberg> or, wait that still warns
<azonenberg> azonenberg@skipjack:/nfs4/home/azonenberg/code/splash-build-system/build$ ld -V
<azonenberg> elf_x86_64
<azonenberg> Supported emulations:
<azonenberg> GNU ld (GNU Binutils for Debian) 2.25
<azonenberg> <list trimmed>
<azonenberg> that does it
<azonenberg> except its confusing for a lot of arches
<azonenberg> like "elf32ebmip" for mips-elf-ld
<whitequark> yes
<azonenberg> is this really so hard to do?
<whitequark> like I said, there's no really good way
<azonenberg> it seems natural that if you have multiple toolchains installed
<azonenberg> you should be able to pick a triple and say "go find me a sane toolchain for it"
<whitequark> well not for GNU
<whitequark> not having to rebuild a compiler for every target you need is also far too straightforward
<whitequark> I can recommend you use clang for everything but unfortunately I cannot recommend you lld
<azonenberg> well unfortunately i cannot rely on my users having clang
<azonenberg> I'm trying to build a generic build systems here
<azonenberg> one of the first steps is, given a set of targets each listing (or inherting default) target triples
<azonenberg> figure out what compiler to use for each
<cr1901_modern> azonenberg: Semi-related: The official supported target triplets by GNU projects is kept in a file in the autoconf repo.
<azonenberg> This includes things like FPGA targets
<cr1901_modern> Sadly I don't remember what the file's called
<azonenberg> In which case i invented my own triples for things like "spartan6-xc6slx25"
<whitequark> I actually think requiring clang is a reasonable thing to do
<whitequark> or otherwise, not any less reasonable than requiring gcc
<cr1901_modern> You expect Windows users to build/have Clang?
<azonenberg> As of now i have auto-detection of GCC/G++ working fine'
<azonenberg> cr1901_modern: For the time being i am only supporting building on *nix
<whitequark> cr1901_modern: sure
<azonenberg> I support *targeting* windows via mingw etc
<whitequark> you can, you know, download an installer
<azonenberg> but not as a host compiler
<azonenberg> That may change in the future
<azonenberg> whitequark: anyway i can detect C/C++ compilers no problem
<azonenberg> I can detect ISE and Vivado, and for the time being have a hard coded (incomplete) list of devices supported by each version i care about
<azonenberg> i dont yet get license info so i limit the list to webpack devices (which is all i use right now anyway)
<whitequark> azonenberg: ld doesn't record the triple anywhere afaik.
<whitequark> so, you cannot get the triple out of ld
<azonenberg> And i detect linkers and automatically use the triple i was able to figure out
<whitequark> nor is it designed to give you the architecture for which it is built
<azonenberg> in particular, for the default ld i use the OS triple from the package manager
<azonenberg> And for ld's with triples in the filename i use that
<cr1901_modern> I'll probably just build clang and keep it in msys2's /opt
<whitequark> clang on windows doesn't need any posix tools... it's a drop-in replacement for cl.exe
<whitequark> including command line options
<azonenberg> (also what's l10m?)
<azonenberg> l1om*
<azonenberg> whitequark: also that is one of the things my toolchain takes care of, command line option translation
<whitequark> in the same way lld is a drop-in replacement for link.exe
<azonenberg> you specify abstracted flags and it will turn them into gcc syntax, cl.exe syntax, or whatever your target platform needs
<azonenberg> or error/warn if that option is meaningless for that target
<whitequark> azonenberg: so on Debian, binutils installs both /usr/bin/ld
<whitequark> and /usr/bin/x86_64-linux-gnu-ld
<cr1901_modern> whitequark: Oh? How long has this been the case? o.0;
<whitequark> for a pretty long time
<azonenberg> whitequark: yes, and i already have that much figured out
<azonenberg> The hard part is...
<azonenberg> where do i find i386-linux-gnu-ld and x86_64-linux-gnux32-ld? :p
<whitequark> huh?
<whitequark> you odn't
<azonenberg> That's my point
<whitequark> you use the x86_64 one
<whitequark> add a ahrdcoded mapping
<azonenberg> Hmm
<cr1901_modern> whitequark: (Answer at leisure) Alright then, that's cool. So if I say build a CMake project, will CMake be fooled into thinking it's targeting Visual Studio?
<azonenberg> I guess that works
<whitequark> cr1901_modern: dunno, never tried
<azonenberg> whitequark: because for gnu C++ i was able to figure out a way to make the gcc dump other triples
<azonenberg> and not have to hard code
<cr1901_modern> I have no problems getting rid of Visual Studio if Clang is a full replacement (meaning without a libgcc dependency and honors Microsoft's C++ ABI and not MinGW's)
<whitequark> sure, it does that
<whitequark> you still need the headers and import libraries though
<cr1901_modern> Thanks
<cr1901_modern> I never looked into it deeply, but MinGW and Microsoft C++ objects are compatible (but the C objects should be, minus a libgcc dependency)
<cr1901_modern> are NOT compat
<whitequark> yes, mingw doesn't try very hard to match msvc abi
<whitequark> that's because it was a multi-month and still ongoing effort for clang
<azonenberg> whitequark: http://pastebin.com/raw/KL845x53
<azonenberg> Does that look like a sane auto-detection?
<whitequark> should be reasonable
<azonenberg> Basically what i'm trying to do is dynamically (as build servers, which likely do not all have the same exact config, come and go)
<azonenberg> figure out the union of all available compilers for any language/architecture
<whitequark> oh so
<azonenberg> And figure out the best one to use for any particular request
<whitequark> unless you provide your own linker script always, you also need to extract the linker script
<whitequark> from ld
<azonenberg> which may be as simple as "c++/generic"
<whitequark> for every emulation
<azonenberg> or as complex as "c++/gnu/4.6.3"
<azonenberg> The idea is, the end user can request as much or as little version info of the toolchain as they want
<azonenberg> And the build system will either match it, or fail because nothing exists
<azonenberg> if you ask for "generic" it hard-codes a preference for clang over gcc and vivado over ISE
<whitequark> similarly gcc can try linking crt in different ways, depending on its configuration
<azonenberg> then picks the highest version for your requested arch
<azonenberg> I'm a ways from donig that
<azonenberg> i cant even compile hello world for my host architecture yet
<azonenberg> :P
<azonenberg> I'm still trying to figure out what it is that i am building
<azonenberg> Which means turning "c++/generic" into "GNU C++ 4.9.2 (50e16ffd479194653bc4a3ebbf60b2b0ed8bee1f6c676994d693f0e9be3e7ff9))
<azonenberg> "
<azonenberg> Because suppose a new node joins my cluster that has g++ 4.9.3 for x86_64-linux-gnu
<azonenberg> now that will become the new c++/generic
<azonenberg> So i have to re-evaluate the hashes for all of my c++/generic targets
<azonenberg> and next build i may need to recompile them
<azonenberg> (unless i already had cached binaries from before)
<azonenberg> Right now the problem i'm working on is that re-evaluation
<azonenberg> Determining the set of available toolchains
<azonenberg> When that set changes, determine which nodes in the dependency graph were affected
<azonenberg> and re-generating them
<azonenberg> not recompiling (yet), just recomputing hashes and dependencies
<azonenberg> Then when I create a C++ExecutableNode for a given arch/config and set of flags
<azonenberg> and set of sources
kristian1aul has quit [Quit: Reconnecting]
kristianpaul has joined ##openfpga
kristianpaul has joined ##openfpga
kristianpaul has quit [Changing host]
<azonenberg> i have to generate nodes for all of the object and source files (also not implemented)
<azonenberg> Once i have the full graph I need to add commands for the end user to invoke in order to actually build one or more targets
<azonenberg> The scheduler then needs to find an available build server that has the target's requested toolchain installed
<azonenberg> dispatch the build job to it
<azonenberg> and only then do i worry about what actual arguments to pass to the compiler :P
<whitequark> mhm
<azonenberg> So i'm easily 1-2 weeks of work away from actually worrying about how a CPPToolchain can turn a CPPSourceNode and unordered_set<BuildFlag> inot a CPPObjectNode
digshadow has joined ##openfpga
landley_ has joined ##openfpga
<cr1901_modern> hrm Inkscape still refuses to load the file
cr1901_modern has quit [Read error: Connection reset by peer]
eightdot has quit [Quit: Changing server]
eightdot has joined ##openfpga
lain__ is now known as lain
mithro has quit [*.net *.split]
rah has quit [*.net *.split]
rah has joined ##openfpga
mithro has joined ##openfpga
m_w has quit [Quit: leaving]
digshadow has quit [Ping timeout: 252 seconds]
digshadow has joined ##openfpga
digshadow has quit [Quit: Leaving.]
digshadow has joined ##openfpga
doomlord has joined ##openfpga
X-Scale has quit [Read error: Connection reset by peer]
[X-Scale] has joined ##openfpga
[X-Scale] is now known as X-Scale
tecepe has quit [Remote host closed the connection]
tecepe has joined ##openfpga
cr1901_modern has joined ##openfpga