{"id":34521885,"url":"https://github.com/secondlife/3p-freetype","last_synced_at":"2026-01-20T16:40:06.721Z","repository":{"id":138609761,"uuid":"539703862","full_name":"secondlife/3p-freetype","owner":"secondlife","description":"FreeType autobuild package","archived":false,"fork":false,"pushed_at":"2026-01-12T21:35:57.000Z","size":5694,"stargazers_count":0,"open_issues_count":0,"forks_count":4,"subscribers_count":1,"default_branch":"main","last_synced_at":"2026-01-13T01:54:43.081Z","etag":null,"topics":[],"latest_commit_sha":null,"homepage":"","language":"Shell","has_issues":false,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":null,"status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/secondlife.png","metadata":{"files":{"readme":"README.Linden","changelog":null,"contributing":null,"funding":null,"license":null,"code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null,"governance":null,"roadmap":null,"authors":null,"dei":null,"publiccode":null,"codemeta":null,"zenodo":null,"notice":null,"maintainers":null,"copyright":null,"agents":null,"dco":null,"cla":null}},"created_at":"2022-09-21T22:16:23.000Z","updated_at":"2026-01-12T21:35:41.000Z","dependencies_parsed_at":null,"dependency_job_id":"be409dce-a6ad-4d4c-8a16-d31cd1f40bc3","html_url":"https://github.com/secondlife/3p-freetype","commit_stats":null,"previous_names":[],"tags_count":12,"template":false,"template_full_name":null,"purl":"pkg:github/secondlife/3p-freetype","repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/secondlife%2F3p-freetype","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/secondlife%2F3p-freetype/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/secondlife%2F3p-freetype/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/secondlife%2F3p-freetype/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/secondlife","download_url":"https://codeload.github.com/secondlife/3p-freetype/tar.gz/refs/heads/main","sbom_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/secondlife%2F3p-freetype/sbom","scorecard":null,"host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":286080680,"owners_count":28480830,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2026-01-16T11:59:17.896Z","status":"ssl_error","status_checked_at":"2026-01-16T11:55:55.838Z","response_time":107,"last_error":"SSL_read: unexpected eof while reading","robots_txt_status":"success","robots_txt_updated_at":"2025-07-24T06:49:26.215Z","robots_txt_url":"https://github.com/robots.txt","online":false,"can_crawl_api":true,"host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":[],"created_at":"2025-12-24T04:59:06.015Z","updated_at":"2026-01-16T18:29:43.378Z","avatar_url":"https://github.com/secondlife.png","language":"Shell","funding_links":[],"categories":[],"sub_categories":[],"readme":"\n0.  Pre-Checkin Checklist\n\n    Performed from top of repo, default branch, head:\n\n    [ ]  Is tag 'current' at or near head of 'vendor'?\n\n         hg heads\n         hg tags\n\n    [ ]  Expected differences between vendor and default?  Very\n         little of the original source should be modified.\n\n         hg diff -rcurrent freetype\n\n    [ ]  Are the 'vendor' and 'default' branch source directories\n         'freetype' and not 'freetype-\u003cversion\u003e'?\n\n    [ ]  Examine build log and confirm zlib is detected and used:\n\n         checking for gzsetparams in -lz... yes\n         checking zlib.h usability... yes\n         checking zlib.h presence... yes\n         checking for zlib.h... yes\n\n    [ ]  Check the library dependencies and version strings the built\n         .sos:\n\n         $ strings libfreetype.* | grep 1\\\\.[0-9]\\\\.\n         1.2.8\n         1.2.8\n          inflate 1.2.8 Copyright 1995-2013 Mark Adler \n         1.2.8\n          inflate 1.2.8 Copyright 1995-2013 Mark Adler \n         1.2.8\n          inflate 1.2.8 Copyright 1995-2013 Mark Adler \n\n         $ ldd libfreetype.so\n                 linux-gate.so.1 =\u003e  (0xf7769000)\n                 libc.so.6 =\u003e /lib32/libc.so.6 (0xf757f000)\n                 /lib/ld-linux.so.2 (0xf776a000)\n\n    [ ]  Check that the shared libraries are not re-exporting other\n         libraries:\n\n         $ nm libfreetype.so | grep flate\n         000626a0 t inflate\n         00064ea0 t inflateCopy\n         000649c0 t inflateEnd\n         00064a20 t inflateGetDictionary\n         00064bb0 t inflateGetHeader\n         000624e0 t inflateInit2_\n         000625f0 t inflateInit_\n         00065170 t inflateMark\n         00062630 t inflatePrime\n         000623c0 t inflateReset\n         00062410 t inflateReset2\n         00062310 t inflateResetKeep\n         00064ad0 t inflateSetDictionary\n         00064bf0 t inflateSync\n         00064e70 t inflateSyncPoint\n         00065140 t inflateUndermine\n         00078e00 r inflate_copyright\n         00066440 t inflate_fast\n         000651c0 t inflate_table\n\n         On Mac, we use hand-constructed symbol lists to remove the\n         zlib symbols from the build .dylibs.  So be particularly\n         thorough and compare *every* symbol exported by libz.a\n         against what these .dylibs are exporting.\n\n         $ nm stage/lib/release/libfreetype.dylib | grep flate\n         0005bb60 t _inflate\n         0005b780 t _inflateCopy\n         0005b3c0 t _inflateEnd\n         0005ba30 t _inflateGetDictionary\n         0005b420 t _inflateGetHeader\n         0005b1c0 t _inflateInit2_\n         0005b290 t _inflateInit_\n         0005b730 t _inflateMark\n         0005b360 t _inflatePrime\n         0005afc0 t _inflateReset\n         0005b080 t _inflateReset2\n         0005af20 t _inflateResetKeep\n         0005bab0 t _inflateSetDictionary\n         0005b450 t _inflateSync\n         0005b6d0 t _inflateSyncPoint\n         0005b700 t _inflateUndermine\n         0005ed10 s _inflate_copyright\n         0005a860 t _inflate_fast\n         0005d670 t _inflate_table\n\n\n1.  Introduction\n\n    Simple build of freetype library from freedesktop.org.\n\n    This repo was originally following the vendor/default branch\n    strategy outlined below.  But with changeset 75760dc4a522, it\n    started fetching source from external sources.  While somewhat\n    interesting, a download per build probably wasn't what the\n    upstream repo had intended people to do and it prevents local\n    source modifications with anything other than a patch hack.\n\n    So, with changeset d81d6f4539d8, the default branch got another\n    head that is back on the vendor/branch strategy as I need to do\n    some tweaks to Windows project files.  The dead head is still\n    present, beware and do not use it.\n\n\n2.  Modifications\n\n    Windows project file changes to use a packaged zlib build.  Well,\n    there *is* a zlib embedded in the resulting libraries and they've\n    done some hacking to make it work.  Look at gzip/ftgzip.c to see\n    what has been done to prevent interactions between their private\n    gzip and a potential 'real usage' in an application.\n\n    On Linux, we either accidentally or intentionally ship without the\n    freetype library at all.  The result is that the viewer doesn't\n    run with these shared libraries.  We build with them then revert\n    (or upgrade) to system-provided libraries.  Accident or\n    carelessness, VWR-28748 suggests that users are better off as a\n    result.  We might want to either make this thing work well or get\n    rid of it entirely and let the host provide it.  For now, we'll\n    'upgrade' to what fontconfig is doing: fully-qualified .so shipped\n    but the symlinks missing so that the system libraries are used by\n    default.\n\n    On Mac, we need to keep archive symbols from libz.a out of the\n    built dylibs but we don't have a convenient link argument to\n    implement it.  So two symbol list files were manually created from\n    the debug and release libz.a files and these are handed off to the\n    -unexported_symbols_list option to the linker.  These files are\n    now supplied by the Darwin zlib package (libz_darwin.exp).\n\n    The above is mostly an exercise in how to do this on Mac.  We'll\n    use static libraries for now.  Easier packaging and that's the\n    general direction we've been heading.\n\n\n3.  Source Origin\n\n    2.4.4:\n      http://download.savannah.gnu.org/releases/freetype/freetype-2.4.4.tar.bz2\n      MD5:  b3e2b6e2f1c3e0dffa1fd2a0f848b671\n\n\n4.  Package Contents\n\n    Common:\n    * include/ft2build.h\n    * include/freetype2/freetype/*.h\n    * include/freetype2/freetype/config/*.h\n    * include/freetype2/freetype/internal/*.h (some platforms)\n\n    Windows:\n    * lib/debug/freetype.lib\n    * lib/release/freetype.lib\n\n    Mac:\n    * lib/debug/libfreetype.a\n    * lib/release/libfreetype.a\n\n    Linux:\n    * lib/debug/libfreetype.a\n    * lib/debug/libfreetype.so.6\n    * lib/debug/libfreetype.so\n    * lib/debug/libfreetype.so.6.6.2\n    * lib/release/libfreetype.a\n    * lib/release/libfreetype.so.6\n    * lib/release/libfreetype.so\n    * lib/release/libfreetype.so.6.6.2\n\n5.  Known Dependencies\n\n    This is not authoritative, it's just a reminder to followup\n    with dependent packages.\n\n    * fontconfig\n\n    * llqtwebkit (possibly)\n\n    * viewer\n\n\n===================================================================\n\n               Third-Party Library Repo Structure\n\n\nIntroduction\n\nWe want to have a way to capture local modifications to a third-party\nopen-source project, such as libcurl, without needing write access to\ntheir public repository.  We want to be able to carry forward such\nmodifications to newer versions of the public project.  All this\nshould be independent of the organizational decision as to whether\nit's even desirable to try to submit our local modifications upstream.\n\nFortunately, the Subversion folks articulated a process years ago that\naddresses this very requirement.  They call it \"Vendor Branches.\"  The\nsame tactic, suitably adapted, works with Mercurial too.\n\nThe essence of the idea is that we capture and tag a particular\nsnapshot of the open-source project.  We develop our local\nmodifications to that, and the repository tip incorporates them.  But\nwhen we want to update to a newer version of the public project, we\nbring it into the repository in such a way that we can discover the\nchanges from the original snapshot and the new one -- and then have\nMercurial apply those deltas to the ''combined'' source.\n\nThe following material is adapted from\nhttp://svnbook.red-bean.com/en/1.1/ch07s05.html, the Red Bean\nSubversion book, but recast for Mercurial.  The Linden source for this\nmaterial is an internal wiki.  There may be superceding documentation\non the public wiki when you read this.  We recommend searching there\nfor updates to conventions below.  And note that each particular\nlibrary may implement variations of this scheme.\n\n\nGeneral Vendor Branch Management Procedure\n\nManaging vendor branches generally works like this.  You create a\nnamed branch (\"vendor\") to store the vendor source snapshots.  Then\nyou import the third party code into that branch.  Your modified\nbranch (named \"default\") is based on \"vendor\".  You always make your\nlocal changes to the default branch.  With each new release of the\ncode you are tracking you bring it into the \"vendor\" branch and merge\nthe changes into \"default\", resolving whatever conflicts occur between\nyour local changes and the upstream changes.\n\nPerhaps an example will help to clarify this algorithm.  We'll use a\nscenario where your development team is creating a calculator program\nthat links against a third-party complex number arithmetic library,\nlibcomplex.  We'll construct a repository specifically for our\nlocally-modified version of that library.  To begin, we must\ninitialize our repository and create at least one file in our\n\"default\" branch.\n\n $ hg init ourcomplex\n $ cd ourcomplex\n $ touch README.txt\n $ hg commit README.txt\n\nNow we can create the vendor branch and do the import of the first\nvendor drop.  We'll call our vendor branch \"vendor\", and each\nsuccessive code drop will be tagged \"current\".\n\n $ hg branch vendor\n $ tar -xjf ../libcomplex-1.0.tar.bz2\n $ mv libcomplex-1.0 libcomplex\n $ hg addremove\n $ hg commit -m \"1.0 source drop\"\n $ hg tag -r tip current\n $ hg tag -r current 1.0\n\nWe now have the current version of the libcomplex source code in\nbranch \"vendor\", tagged \"current\" and in a non-version-specific source\ncode subdirectory (\"libcomplex\").  Next, we merge it into the default\nbranch.  It is in the default branch that we will make our\ncustomizations.\n\n $ hg update default\n $ hg merge vendor\n $ hg commit -m \"initial: 1.0\"\n\nWe get to work customizing the libcomplex code.  Before we know it,\nour modified version of libcomplex is now completely integrated into\nour calculator program.\n\nA few weeks later, the developers of libcomplex release a new version\nof their library, version 1.1, which contains some features and\nfunctionality that we really want.  We'd like to upgrade to this new\nversion, but without losing the customizations we made to the existing\nversion.  What we essentially would like to do is to replace our\ncurrent baseline version of libcomplex 1.0 with a copy of libcomplex\n1.1, and then have Mercurial re-apply the custom modifications we\npreviously made to that library to the new version.  But we actually\napproach the problem from the other direction, applying the changes\nmade to libcomplex between versions 1.0 and 1.1 to our modified copy\nof it.\n\nTo perform this upgrade, we update our repository to our vendor\nbranch, and update the \"current\" tag with the new libcomplex 1.1\nsource code.  We quite literally replace the existing files with the\nnew files, clearing out the whole tree and exploding the libcomplex\n1.1 release tarball in its place.  The goal here is to make the tip of\nour vendor branch contain only the libcomplex 1.1 code, and to ensure\nthat all that code is under version control.  Oh, and we want to do\nthis with as little version control history disturbance as possible.\n\n $ hg update vendor\n $ rm -rf *\n $ tar -xjf ../libcomplex-1.1.tar.bz2\n $ mv libcomplex-1.1 libcomplex\n $ hg addremove -s 60\n $ # Additional 'hg add' and 'hg rm' commands if needed\n $ hg commit -m \"1.1 source drop\"\n\nAfter unpacking the 1.1 tarball, hg status will show files with local\nmodifications as well as, perhaps, some unversioned or missing files.\nIf we did what we were supposed to do, the unversioned files are only\nthose new files introduced in the 1.1 release of libcomplex.  The\nmissing files are files that were in 1.0 but not in 1.1.  The 'hg\naddremove' command deals with both, and more: the '-s 60' switch\ndirects Mercurial to compare added files to deleted files, recognizing\nany file at least 60% similar as a move/rename.\n\nFor simple or stable libraries, the 'hg addremove' command should be\nreliable.  For more complicated libraries subject to refactoring or\nlarge gaps of time between updates (e.g. libcurl), it can get a little\nlost trying to match files in the old release with files in the new\nrelease.  Pay attention to the output of the command or better still,\ndo dry runs.  Files erroneously moved can be excluded with the '-X'\noption and then dealt with individually with 'hg add' and 'hg rm'\ncommands after 'hg addremove'.  (The readme file in the curl library\nshould document a particularly challenging case.)\n\nThe 'addremove' process doesn't have to be perfect.  Recreating the\nevolution of the upstream source tree isn't universally practical.\nBut we'd like to capture movement of files in the vendor branch that\nare modified in the default branch.  If achieving that becomes too\ntedious, then re-implementation of the default branch edit in a new\nfile is fine.  Just note it here for the next developer.\n\nFinally, once our current working copy contains only the libcomplex\n1.1 code, we commit the changes we made to get it looking that way.\n\nOur current vendor branch now contains the new vendor drop.  We move\nthe 'current' tag to the new version (in the same way we previously\ntagged the version 1.0 vendor drop), and then merge the differences\nbetween the version 1.0 and version 1.1 into our default branch.\n\n $ hg tag -f -r tip current\n $ hg tag -r current 1.1\n $ hg update default\n $ hg merge vendor\n # resolve all the conflicts between their changes and our changes\n # if you will have conflicts in .hgtags, simply take *all* lines\n ...\n $ hg commit -m \"update with 1.1\"\n\nAny additional work needed to get the merged library working can\nnow be done on the default branch.\n\n\nRevision Tags\n\nWe don't currently make use of Mercurial tags in the build and release\nprocess for 3rd-party libraries.  But we would like to establish a\nconvention to document update and release points.  The tags we would\nlike to establish are:\n\n * 'current' Points to a succession of vendor releases checked into\n   the 'vendor' branch.  Will almost always be at or close to branch\n   head.\n\n * '\u003cversion\u003e' Tag on the 'vendor' branch pointing to a verbatim\n   checkin of a 3rd-party's \u003cversion\u003e release.  Example:  '7.21.1' for\n   a particular version of libcurl we have used.\n\n * Release-type tags on the default branch aren't as useful given how\n   Mercurial handles tags and how autobuild works.\n\n\nSchematic of a Third-Party Repository\n\nBelow is the output of the 'hg glog' command showing a library project\ngoing through an initial 1.0 release and an update from the vendor to\n1.1.  Significant revisions in the repository lifecycle are as\nfollows:\n\n 0  Creation of the repo with an initial file.\n 1  1.0 code drop on branch 'vendor'\n 4  Merge of 1.0 code onto branch 'default'\n 5  Modifications to library we wish to keep over time.  Released.\n 6  1.1 code drop on branch 'vendor'\n 9  Merge of 1.1 code onto branch 'default'\n10  Fixes to merge yielding production 1.1 library.  Released.\n \n\n@  changeset:   10:888229641f6e\n|  tag:         tip\n|  user:        Monty Brandenberg \u003cmonty@lindenlab.com\u003e\n|  date:        Wed Oct 30 13:35:51 2013 -0400\n|  summary:     Work to get 1.1 merge working.  Release.\n|\no    changeset:   9:925ccdf09f50\n|\\   parent:      5:83c5775c23dc\n| |  parent:      8:977001a08e48\n| |  user:        Monty Brandenberg \u003cmonty@lindenlab.com\u003e\n| |  date:        Wed Oct 30 13:35:20 2013 -0400\n| |  summary:     update with 1.1\n| |\n| o  changeset:   8:977001a08e48\n| |  branch:      vendor\n| |  user:        Monty Brandenberg \u003cmonty@lindenlab.com\u003e\n| |  date:        Wed Oct 30 13:33:49 2013 -0400\n| |  summary:     Added tag 1.1 for changeset 5f6cb89add91\n| |\n| o  changeset:   7:59bce0f6d12f\n| |  branch:      vendor\n| |  user:        Monty Brandenberg \u003cmonty@lindenlab.com\u003e\n| |  date:        Wed Oct 30 13:33:41 2013 -0400\n| |  summary:     Added tag current for changeset 5f6cb89add91\n| |\n| o  changeset:   6:5f6cb89add91\n| |  branch:      vendor\n| |  tag:         current\n| |  tag:         1.1\n| |  parent:      3:8525ad934ecd\n| |  user:        Monty Brandenberg \u003cmonty@lindenlab.com\u003e\n| |  date:        Wed Oct 30 13:33:29 2013 -0400\n| |  summary:     1.1 source drop\n| |\no |  changeset:   5:83c5775c23dc\n| |  tag:         1.0\n| |  user:        Monty Brandenberg \u003cmonty@lindenlab.com\u003e\n| |  date:        Wed Oct 30 13:32:31 2013 -0400\n| |  summary:     Linden-specific changes to the library.  Release\n| |\no |  changeset:   4:bccb736585f4\n|\\|  parent:      0:400e4516c406\n| |  parent:      3:8525ad934ecd\n| |  user:        Monty Brandenberg \u003cmonty@lindenlab.com\u003e\n| |  date:        Wed Oct 30 13:31:40 2013 -0400\n| |  summary:     initial:  1.0\n| |\n| o  changeset:   3:8525ad934ecd\n| |  branch:      vendor\n| |  user:        Monty Brandenberg \u003cmonty@lindenlab.com\u003e\n| |  date:        Wed Oct 30 13:30:21 2013 -0400\n| |  summary:     Added tag 1.0 for changeset 8ac3828d03bb\n| |\n| o  changeset:   2:7aa1a1cb62d9\n| |  branch:      vendor\n| |  user:        Monty Brandenberg \u003cmonty@lindenlab.com\u003e\n| |  date:        Wed Oct 30 13:30:14 2013 -0400\n| |  summary:     Added tag current for changeset 8ac3828d03bb\n| |\n| o  changeset:   1:8ac3828d03bb\n|/   branch:      vendor\n|    tag:         1.0\n|    user:        Monty Brandenberg \u003cmonty@lindenlab.com\u003e\n|    date:        Wed Oct 30 13:30:09 2013 -0400\n|    summary:     1.0 source drop\n|\no  changeset:   0:400e4516c406\n   user:        Monty Brandenberg \u003cmonty@lindenlab.com\u003e\n   date:        Wed Oct 30 13:29:16 2013 -0400\n   summary:     Created repo with initial readme file\n\n","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fsecondlife%2F3p-freetype","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Fsecondlife%2F3p-freetype","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fsecondlife%2F3p-freetype/lists"}