<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
<meta name="Generator" content="Microsoft Word 15 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0cm;
font-size:11.0pt;
font-family:"Calibri",sans-serif;
mso-fareast-language:EN-US;}
span.EmailStyle18
{mso-style-type:personal-compose;
font-family:"Calibri",sans-serif;
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;
font-family:"Calibri",sans-serif;
mso-fareast-language:EN-US;}
@page WordSection1
{size:612.0pt 792.0pt;
margin:70.85pt 70.85pt 70.85pt 70.85pt;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang="FR" link="#0563C1" vlink="#954F72" style="word-wrap:break-word">
<div class="WordSection1">
<p class="MsoNormal"><span lang="EN-US">Hello,<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US">I recently had to compile gdal 3.8 with pdfium support on an AlmaLinux 8 platform and I struggled for a while with an unexpected issue that I could finally come up with.<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US">I used the latest version of the build_linux.sh procedure provided by Even Rouault (https://github.com/rouault/pdfium_build_gdal_3_8/blob/master/build_linux.sh)<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US">I explain below the issue and the fix.<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US">The issue I faced:<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US">- the build_linux.sh script clones depot_tools.git and then checkouts a specific commit (1c4052d88ac510a3db4351e52c088cac524c726c in the case of gdal 3.8). The depot_tools repo is thus now in detached head on the 1c4052d8
commit. <o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US">- Up to now, everything is completely fine and the underlying intent of this checkout (freezing the content of depot_tool) became clear to me when I compared the 1c4052d8 commit date (2023/08/16) and the date of the current
build_linux.sh script (commited the following day)<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US">- But then, the build_linux.sh script launches the two following commands : 'gclient config --unmanaged "$PDFIUM_URL"' and 'gclient sync --revision="$REV"'
<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US">- ... and these commands end with the following error: "depot_tools/update_depot_tools: line 149: goma_ctl: command not found"<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US">After analysis, the issue comes from the fact that these gclient commands perform a change in the state of the depot_tools repo:<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US">- before launching the gclient commands, this repo was, as said above, in detached head on the 1c4052d8 commit. In this state, the goma_ctl script exists in the depot_tools.<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US">- after launching the gclient commands, the depo_tools repo is detached head, but at origin/main. And the goma_ctl script does not exist anymore.<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US">- Looking to the commit history, it appears that goma_ctl was removed on 2024/04/15 (commit "remove goma CIPD package").<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US">The fix:<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US">I tried to find a way to avoid depot_tools to be automatically updated and I finally found that setting the following variable before launching the build_linux.sh script did the trick:<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US">DEPOT_TOOLS_UPDATE=0<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US">Maybe this fix could be included in the several existing compilation procedures ?<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US">(I only used the one related to gdal 3.8 but I think that the same issue - and the same fix - might be applicable for the other versions).<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal">Best regards,<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Patrick Floissac<o:p></o:p></p>
</div>
<font style="font-size: 9px;">The information in this e-mail is confidential. The contents may not be disclosed or used by anyone other than the addressee. Access to this e-mail by anyone else is unauthorised.<br>If you are not the intended recipient, please notify Airbus immediately and delete this e-mail.<br>Airbus cannot accept any responsibility for the accuracy or completeness of this e-mail as it has been sent over public networks. If you have any concerns over the content of this message or its Accuracy or Integrity, please contact Airbus immediately.<br>All outgoing e-mails from Airbus are checked using regularly updated virus scanning software but you should take whatever measures you deem to be appropriate to ensure that this message and any attachments are virus free.</font></body>
</html>