Skip to content
GitLab
Projects Groups Snippets
  • /
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in / Register
  • D dynamorio
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 1,467
    • Issues 1,467
    • List
    • Boards
    • Service Desk
    • Milestones
  • Merge requests 44
    • Merge requests 44
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
  • Deployments
    • Deployments
    • Environments
    • Releases
  • Packages and registries
    • Packages and registries
    • Package Registry
    • Infrastructure Registry
  • Monitor
    • Monitor
    • Incidents
  • Analytics
    • Analytics
    • Value stream
    • CI/CD
    • Repository
  • Wiki
    • Wiki
  • Snippets
    • Snippets
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • DynamoRIO
  • dynamorio
  • Issues
  • #2
Closed
Open
Issue created Nov 27, 2014 by Derek Bruening@derekbrueningContributor

update makefiles to build with local tools instead of /build/toolchain

From [email protected] on February 11, 2009 15:46:52

The makefiles are currently assuming that the VMware toolchain is present. For a proprietary product, IMHO having the toolchain standardized and either in the repository or on a server is the right way to go, in order to properly build old versions.

However, for an open source project we want to support building on as wide a variety of toolchains as possible, and we don't really need to fix bugs in old versions (though we could support that by listing not only minimum versions but also maximum in our Makefiles). (Plus, we can't exactly commit, say, the Windows DDK into our repository.) So instead of only supporting a single version, long-term we should try to expand support. There are many issues there as different versions of a compiler bring up different subtle issues.

Here is a short list of what we currently require:

Linux:

  • Require gcc built to target both 32-bit and 64-bit
  • Require gas built to target both 32-bit and 64-bit
  • Require gas >= 2.18.50 for -msyntax=intel -mmnemonic=intel
  • Require gas >= 2.16 for fxsaveq
  • Require gcc >= 3.4 for -fvisibility: though we do have a workaround Windows:
  • Require cl for intrinsics
  • Require cl >= 14.0 to target both 32-bit and 64-bit and for C99 macro varargs
  • Require cygwin perl and other cygwin tools Both:
  • Require doxygen >= 1.5.1, 1.5.3+ better

We can split future work (such as switching to cmake, getting version #s from top level instead of being hardcoded in certain places, parallelizing the build, re-enabling dependency checking, etc.) off into separate Issues but for now this issues covers getting things working for the initial developers (we'll reduce the priority once that's covered).

Original issue: http://code.google.com/p/dynamorio/issues/detail?id=2

Assignee
Assign to
Time tracking