[twrp-9.0] Error compiling with symlinks libservices.so

[mauronofrio]

[ 99% 567/568] glob vendor/omni/overlay/common/**/*
ninja: error: '/home/mauronofrio/minimal-omni-9.0/out/target/product/fajita/system/lib64/libservices.so', needed by '/home/mauronofrio/minimal-omni-9.0/out/target/product/fajita/obj_arm/SHARED_LIBRARIES/libbmlutils_intermediates/teamwin', missing and no known rule to make it
13:55:19 ninja failed with: exit status 1

Got this error at the beginning

[MartinX3]

Will remove the downloaded source code and redownload it again (this time as shallow clone) and use your OnePlus 6T fajita device tree.
Maybe I have some files, you don't have, because of my work at the manifest files.

[mauronofrio]

Ok, i will wait for your news

[MartinX3]

Which build environment do you use, @mauronofrio ?
Mine is Ubuntu 18.04
Another one facing this error told me, that he is using arch linux.

[mauronofrio]

I'm using linux mint 19, but i have not this problem with full source, so i don't think is a build environment problem

[MartinX3]

I am using Linux Mint 19, too without having this problem with the full omni 9.0 sources.

Right after finished downloading the source code, I will

export ALLOW_MISSING_DEPENDENCIES=true;
. build/envsetup.sh;
lunch; # fajita-eng
make -j8 bootimage;

[mauronofrio]

mmm, i'm building also adbd, so you need of
mka adbd recoveryimage -j8

[mauronofrio]

This is what i have on the readme
. build/envsetup.sh
export ALLOW_MISSING_DEPENDENCIES=true
export LC_ALL=C
lunch omni_fajita-eng
mka adbd recoveryimage

[MartinX3]

Thank you, will try it this way.

I never used adbd.
Is it for ADB support?
Because I am able to use ADB in my Xperia XZ2/c/p/3 builds :S
Or it's because my recovery is included into the bootimage.

And yes
I forgott
export LC_ALL=C
against the compilation
I need export LANG=de_DE.UTF-8 too

[MartinX3]

Jackpot!

[ 99% 567/568] glob vendor/omni/overlay/common/**/*
ninja: error: '/home/developer/android/platform_manifest_twrp_omni_android_9.0/out/target/product/fajita/system/lib64/libservices.so', needed by '/home/developer/android/platform_manifest_twrp_omni_android_9.0/out/target/product/fajita/obj_arm/SHARED_LIBRARIES/libbmlutils_intermediates/teamwin', missing and no known rule to make it
14:56:23 ninja failed with: exit status 1

with
mka adbd recoveryimage

Now I can work on this bug.

[mauronofrio]

OK, actually i'm working on the fajita twrp to fix some little issue, so i can't help you, maybe tomorrow i will check better it.

[CaptainThrowback]

@MartinX3 You didn't have the error using the device trees I linked for you yesterday? I don't do anything more than mka recoveryimage, so it should have nothing to do with adbd, as you can see by the error that it's related to TWRP.

I just tested on my build box (which runs Debian Jessie) and on my Ubuntu 18.04 LTS laptop, and they both fail at the same libservices error. I look forward to seeing a fix for this issue.

[ShevT]

export LC_ALL=C

Yes it helps

[MartinX3]

I can confirm, what @codeworkx said.
If you go into
frameworks/base/libs
and replace the services folder symlink with a real existing folder, it finds the files and starts compiling the project.

So I assume there is a problem following this symlink.
Maybe a too long path?
But I don't think it's the path length.

Maybe someone saw a similar but in the past?
Maybe because of the usage of relative paths.

[CaptainThrowback]

@MartinX3

I can confirm. I first tried an absolute symlink versus a relative symlink, but the file/folder still wasn't found. Only when copying the folder to the expected location did compilation continue (and then subsequently fail due to an issue in partition.cpp).

Can the manifest xml be updated to copy the folder rather than link it?

[mauronofrio]

i can confirm it too. In this case just restore the framework/base, it in all cases will be downloaded so you can also include it

[MartinX3]

@CaptainThrowback
issue in partition.cpp?
I only get one in
graphics_fbdev.cpp
fixed by
https://gerrit.omnirom.org/#/c/android_bootable_recovery/+/33157/

And I will look how to copy the stuff instead of symlink it.

@mauronofrio
Sadly it has a size of 1GB
With most of the stuff not needed (only 50mb) by a twrp image. :)

Edit:
copyfile instead of linkfile
Will test it

[mauronofrio]

Got another error building:

[ 17% 2344/13454] //system/security/keystore:keystore link keystore
FAILED: /home/mauronofrio/minimal-omni-9.0/out/soong/.intermediates/system/security/keystore/keystore/android_arm64_armv8-a_kryo_core/keystore
echo "module keystore missing dependencies: IKeyAttestationApplicationIdProvider.aidl" && false
module keystore missing dependencies: IKeyAttestationApplicationIdProvider.aidl

[MartinX3]

@mauronofrio
the next symlink?

there are three

<project path="TeamWin/.repo/frameworks/base" name="android_frameworks_base" remote="omnirom" revision="android-9.0" clone-depth="1" >
    <copyfile src="core/java" dest="frameworks/base/core/java" />
    <copyfile src="keystore/java" dest="frameworks/base/keystore/java" />
    <copyfile src="libs/services" dest="frameworks/base/libs/services" />
</project>

[mauronofrio]

yes, should be them, restarting the build

[MartinX3]

Using "copyfile" instead of "linkfile" results in
"Cannot copy file"

Interesting...

I assume it wants to copy a file and not a directory.

using "cp" in linux results into "cp: -r not specified; omitting directory"
So a solution would be to "copyfile" every single file needed.

[MartinX3]

Argh

https://gerrit.googlesource.com/git-repo/+/master/project.py#260
https://docs.python.org/3/library/shutil.html#shutil.copy

Accepts only a file, not a directory.
Thousands of files are living there.

[mauronofrio]

I'm seeing, bad news

[MartinX3]

@CaptainThrowback
the easiest and most stable solution would be to add
android_frameworks_base
instead of thousands of copyfile entries in the manifest file.

[mauronofrio]

I want to say that in all cases it is downloaded to relink that folders, so it's just a path relink

[MartinX3]

You mean the 1GB big "TeamWin" folder which get's downloaded anyway?

[mauronofrio]

Yes, it is already there, so it is already downloaded

[MartinX3]

Using the entire base folder sadly results in build errors.
So adding it is not a good solution.
There gets too many dependencies added.
Maybe we can add a bash script into the manifests which copies the needed files.
I will google about it.

find: ‘../opt/telephony/src/java/android/telephony’: No such file or directory
find: ‘../opt/telephony/src/java/android/telephony/gsm’: No such file or directory
find: ‘../opt/net/voip/src/java/android/net/rtp’: No such file or directory
find: ‘../opt/net/voip/src/java/android/net/sip’: No such file or directory
find: ‘../opt/telephony/src/java/android/telephony’: No such file or directory
find: ‘../opt/telephony/src/java/android/telephony/gsm’: No such file or directory
find: ‘../opt/net/voip/src/java/android/net/rtp’: No such file or directory
find: ‘../opt/net/voip/src/java/android/net/sip’: No such file or directory
frameworks/base/packages/SimAppDialog/Android.mk:17: error: frameworks/opt/setupwizard/library/common-platform-deprecated.mk: No such file or directory
17:13:01 ckati failed with: exit status 1

#### failed to build some targets (30 seconds) ####

[MartinX3]

Does this bug still happen with the switch to 9.0_r30?
(It need to be a bug with the AOSP build environment -> Maybe we removed an important package?)

(Sadly no time at the moment to test it myself, due to exams.
But compiling with the normal OmniROM was fine.)

[CaptainThrowback]

Does this bug still happen with the switch to 9.0_r30?
(It need to be a bug with the AOSP build environment -> Maybe we removed an important package?)

(Sadly no time at the moment to test it myself, due to exams.
But compiling with the normal OmniROM was fine.)

Yes, this bug is still present.

[mauronofrio]

I can confirm it too, seems it's not a symlink problem, the symlinks are working, maybe the folder symlink are not accepted from the compilation process

[MartinX3]

@CaptainThrowback @mauronofrio

Readding
platform/frameworks/opt/setupwizard
and
android_frameworks_base
fixed the problem at my site.

In the complete omni tree this git exists without symlinks.
Here we use

<project path="TeamWin/.repo/frameworks/base" name="android_frameworks_base" remote="omnirom" revision="android-9.0" clone-depth="1" >
        <linkfile src="core/java" dest="frameworks/base/core/java" />
        <linkfile src="keystore/java" dest="frameworks/base/keystore/java" />
        <linkfile src="libs/services" dest="frameworks/base/libs/services" />
    </project>

Which introduces symlinks.

I can only assume if this is the cause.

PS:
Yes, I know that you don't want to add the full android_frameworks_base to this minimal manifest.

Counting the size of the "project-objects" folder in the ".repo" folder I measure after my fix

Full Omni 9.0
37.0GB

Minimal Omni
8.6GB

PS0:
I updated the project to _r31

PS1:
I wait for your reaction @CaptainThrowback before I do anything :P

[CaptainThrowback]

@CaptainThrowback @mauronofrio

Readding
platform/frameworks/opt/setupwizard
and
android_frameworks_base
fixed the problem at my site.

In the complete omni tree this git exists without symlinks.
Here we use

<project path="TeamWin/.repo/frameworks/base" name="android_frameworks_base" remote="omnirom" revision="android-9.0" clone-depth="1" >
        <linkfile src="core/java" dest="frameworks/base/core/java" />
        <linkfile src="keystore/java" dest="frameworks/base/keystore/java" />
        <linkfile src="libs/services" dest="frameworks/base/libs/services" />
    </project>

Which introduces symlinks.

I can only assume if this is the cause.

PS:
Yes, I know that you don't want to add the full android_frameworks_base to this minimal manifest.

Counting the size of the "project-objects" folder in the ".repo" folder I measure after my fix

Full Omni 9.0
37.0GB

Minimal Omni
8.6GB

PS0:
I updated the project to _r31

Yes, that was a workaround so that we wouldn't have to download the whole frameworks base folder. The fact that it works fine in the 8.1 tree means that there's a change somewhere that broke it. Until we figure out what that change is, this will remain broken.

I've started just doing a repo sync, removing the symlinks, and then copying those 3 folders from the TeamWin/.repo folder to the locations where the symlinks were. That gets everything working fine, but it has to be undone and re-done every time the Android tag is updated or frameworks/base is otherwise changed.

I thought it might be possible to include some code in vendorsetup.sh to do it automatically, something like this:

BASE=frameworks/base
CORE=core/java
KEYSTORE=keystore/java
LIBS=libs/services
TOP=gettop
TWRP=TeamWin/.repo

if [ -L $TOP/$BASE/$CORE ]; then
	rm $TOP/$BASE/$CORE
	cp -r $TWRP/$BASE/$CORE $TOP/$BASE/core
fi
if [ -L $TOP/$BASE/$KEYSTORE ]; then
	rm $TOP/$BASE/$KEYSTORE
	cp -r $TWRP/$BASE/$KEYSTORE $TOP/$BASE/keystore
fi
if [ -L $TOP/$BASE/$LIBS ]; then
	rm $TOP/$BASE/$LIBS
	cp -r $TWRP/$BASE/$LIBS $TOP/$BASE/libs
fi

But I must have done that wrong too as it did absolutely nothing. If we can get a script like that to run automatically, we can get rid of the symlinks, and just copy the data that way, without needing to sync the whole folder.

[MartinX3]

@CaptainThrowback
But the vendorsetup.sh is independent of this platform manifest.

Do you mean this?
https://gerrit.googlesource.com/git-repo/+/HEAD/docs/repo-hooks.md

But sadly there is only a "pre-upload" hook which doesn't work in our case.
They did never extend the hook list.
Hmm. And we can only create symlinks and copy files, not folders.

[CaptainThrowback]

@CaptainThrowback
But the vendorsetup.sh is independent of this platform manifest.

Do you mean this?
https://gerrit.googlesource.com/git-repo/+/HEAD/docs/repo-hooks.md

But sadly there is only a "pre-upload" hook which doesn't work in our case.
They did never extend the hook list.
Hmm. And we can only create symlinks and copy files, not folders.

I was trying to use vendorsetup.sh to handle this automatically when lunching for a device. But it didn't work. I have no idea if there's a way to do this via repo.

[MartinX3]

@CaptainThrowback
The only (crazy) workaround would be to fork android_frameworks_base and remove the unused stuff.
And to merge every update in it.

But in the end, even if we use the entire android_frameworks_base this minimal manifest only uses 8.6GB code instead of the full 37GB.

[CaptainThrowback]

@CaptainThrowback
The only (crazy) workaround would be to fork android_frameworks_base and remove the unused stuff.
And to merge every update in it.

But in the end, even if we use the entire android_frameworks_base this minimal manifest only uses 8.6GB code instead of the full 37GB.

How much is it without the full frameworks base (i.e. now)?

[MartinX3]

@CaptainThrowback
Without android_frameworks_base it's ~7.2GB

[CaptainThrowback]

You can do whatever you want.

[MartinX3]

Thank you very much!
It would be terrible to workaround something dirty to fix this weird symlink issue :)

[MartinX3]

@CaptainThrowback @mauronofrio @ShevT
Could you test the committed fix please? :)
Then I can close this issue forever.

[mauronofrio]

I will check it tomorrow

[mauronofrio]

Seems it is working, but i need to make some more tests

[MartinX3]

@mauronofrio the testing was successful?
(Will move to 9.0.0_r34 after my exam at 20.3.)

[MartinX3]

After 9.0.0_r34, we got now 9.0.0_r35

[CaptainThrowback]

Is this working now? Can it be closed?

[MartinX3]

@mauronofrio
We're closing this now, it works at my site and you said on 22. Feb it seems to work.
If it happens again, feel free to report it here. :)

[stefanct]

I still get this error when building for hlte (samsung galaxy note 3 - havent tested anything else) and this is my first try to build anything with repo and friends ever IIRC... I am still quite sure that I have that referenced fix already. This is how I build:

mkdir platform_manifest_twrp_omni
cd platform_manifest_twrp_omni
repo init --depth=1 -u git://github.com/minimal-manifest-twrp/platform_manifest_twrp_omni.git -b twrp-9.0

# Add hlte repo
mkdir -p .repo/local_manifests/
cat << EOF > .repo/local_manifests/hlte.xml
<?xml version="1.0" encoding="UTF-8"?>
<manifest>
  <project name="TeamWin/android_device_qcom_common" path="device/qcom/common" remote="github" revision="android-7.1" />
  <project name="TeamWin/android_device_samsung_hlte" path="device/samsung/hlte" remote="github" revision="android-7.1" />
</manifest>
EOF

# Download everything (takes a long while...)
repo sync -c --force-sync --force-broken --no-tags

# Add undistributed boot.img from stock
cp $stock_archive/boot.img device/samsung/hlte/boot.img

# Remove deprecated flags from BoardConfig.mk:
# -TARGET_GLOBAL_CFLAGS += -mfpu=neon -mfloat-abi=softfp
# -TARGET_GLOBAL_CPPFLAGS += -mfpu=neon -mfloat-abi=softfp

export ALLOW_MISSING_DEPENDENCIES=true
. build/envsetup.sh
lunch omni_hlte-eng
mka recoveryimage

I have also tried adding TW_USE_TOOLBOX := true which does indeed change the behavior but only slightly... ;) ninja: error: '.../out/target/product/hlte/system/bin/mkfs.f2fs', needed by '.../out/target/product/hlte/obj/SHARED_LIBRARIES/libbmlutils_intermediates/teamwin', missing and no known rule to make it.

That's also the same error that one would get with busybox fetched correctly, e.g., via this additional manifest:

<?xml version="1.0" encoding="UTF-8"?>
<manifest>
  <project name="TeamWin/android_external_busybox" path="external/busybox" remote="github" revision="android-9.0" />
</manifest>

So maybe the TW_USE_TOOLBOX is what we actually want to default to with the reference patch applied and the mkfs.f2fs is unrelated?

[MartinX3]

Dear @stefanct
maybe your device tree needs a fix

My error is

ninja: error: '/home/developer/android/platform_manifest_twrp_omni_android_9.0/out/target/product/hlte/boot.img', needed by '/home/developer/android/platform_manifest_twrp_omni_android_9.0/out/target/product/hlte/ramdisk-recovery.cpio', missing and no known rule to make it

(Did a normal repo sync and tried it with my own boot.img, not with the one you did)

The error isn't about libservices.so, too.
I recommend to try it again with the newest version of this repo and open a new bug issue ticket if it appears again. :)