<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
<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>
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>
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]