Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

fix implicit dependency on flite_voice_list.c (fixes #86) #92

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

barsnick
Copy link

Also make flite_lang_list a proper rule, so that it only builds once.

Both C files were repeatedly being clobbered, as were their respective object files.

Convert flite_voice_list.c is into an explicit dependency with a creation rule. flite_voice_list.o continues to be implicit from flite_voice_list.c.

Convert flite_lang_list into a similar, proper object rule.

Fixes #86

Also make flite_lang_list a proper rule, so that it only builds once.

Both C files were repeatedly being clobbered, as were their respective
object files.

Convert flite_voice_list.c is into an explicit dependency with a creation
rule. flite_voice_list.o continues to be implicit from flite_voice_list.c.

Convert flite_lang_list into a similar, proper object rule.

Fixes festvox#86
@rathann
Copy link
Contributor

rathann commented Mar 23, 2023

That doesn't seem to fix parallel builds completely. I'm still getting errors:

gcc -O2 -flto=auto -ffat-lto-objects -fexceptions -g -grecord-gcc-switches -pipe -Wall -Werror=format-security -Wp,-U_FORTIFY_SOURCE,-D_FORTIFY_SOURCE=3 -Wp,-D_GLIBCXX_ASSERTIONS -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -fstack-protector-strong -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1  -m64  -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer  -Wall     -o ../bin/flite_cmu_us_kal flite_main.o flite_voice_list.o flite_lang_list.o -L../build/x86_64-linux-gnu/lib -lflite_cmu_us_kal -lflite_cmu_time_awb -lflite_cmu_us_kal16 -lflite_cmu_us_awb -lflite_cmu_us_rms -lflite_cmu_us_slt -lflite_usenglish -lflite_cmu_indic_lang -lflite_cmu_grapheme_lang -lflite_cmulex -lflite_cmu_indic_lex -lflite_cmu_grapheme_lex -lflite -Wl,-z,relro -Wl,--as-needed  -Wl,-z,now -specs=/usr/lib/rpm/redhat/redhat-hardened-ld -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1  -Wl,--build-id=sha1 -specs=/usr/lib/rpm/redhat/redhat-package-notes  -lm -lpulse-simple -lpulse 
/usr/bin/ld: /usr/lib/gcc/x86_64-redhat-linux/13/../../../../lib64/Scrt1.o: in function `_start':
(.text+0x1b): undefined reference to `main'
collect2: error: ld returned 1 exit status
make[2]: *** [Makefile:136: ../bin/flite_cmu_us_kal] Error 1

For some reason, the above error isn't fatal on x86_64 and doesn't occur on s390x, but it fails the build on aarch64, ppc64le and i686. See https://koji.fedoraproject.org/koji/taskinfo?taskID=99064127 for full build logs.

@barsnick
Copy link
Author

I can't reproduce easily, my fastest machine is too slow. I might have to use a COPR in Fedora's infrastructure, but then I can't access the build root manually.

See https://koji.fedoraproject.org/koji/taskinfo?taskID=99064127 for full build logs.

That error is peculiar, because main() is in flite_main.{c,o}, and that has proper dependencies, and is built only once according to your logs, and well before it's used for linking. I don't see what's wrong there.

There's another error in there:

gcc -O2 -flto=auto -ffat-lto-objects -fexceptions -g -grecord-gcc-switches -pipe -Wall -Werror=format-security -Wp,-U_FORTIFY_SOURCE,-D_FORTIFY_SOURCE=3 -Wp,-D_GLIBCXX_ASSERTIONS -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -fstack-protector-strong -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1  -m64 -mcpu=power8 -mtune=power8 -fasynchronous-unwind-tables -fstack-clash-protection  -Wall     -o ../bin/flitevox_info flitevox_info_main.o flite_voice_list.o flite_lang_list.o -L../build/powerpc64le-linux-gnu/lib -lflite_cmu_us_kal -lflite_cmu_time_awb -lflite_cmu_us_kal16 -lflite_cmu_us_awb -lflite_cmu_us_rms -lflite_cmu_us_slt -lflite_usenglish -lflite_cmu_indic_lang -lflite_cmu_grapheme_lang -lflite_cmulex -lflite_cmu_indic_lex -lflite_cmu_grapheme_lex -lflite -Wl,-z,relro -Wl,--as-needed  -Wl,-z,now -specs=/usr/lib/rpm/redhat/redhat-hardened-ld -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1  -Wl,--build-id=sha1 -specs=/usr/lib/rpm/redhat/redhat-package-notes  -lm -lpulse-simple -lpulse 
/usr/bin/ld: /tmp/cctwr1qp.ltrans0.ltrans.o: in function `main':
/builddir/build/BUILD/flite-2.2/main/flitevox_info_main.c:68: undefined reference to `flite_set_lang_list'

which indicates that something's still wrong with flite_lang_list.

That said:

making ../build/powerpc64le-linux-gnu/lib/libflite_usenglish.so
/bin/sh: line 1: cd: shared_os: No such file or directory

This is due to a big no-go in config/common_make_rules:

# Used in the lib/ directory and in building new voices
$(LIBDIR)/%.so: $(LIBDIR)/%.shared.a
        @ echo making $@
        @ rm -rf shared_os && mkdir shared_os

In parallel builds, each lib creation is clobbering another lib's creation dir. This should probably be using mktemp or a directory name based on the target.

@barsnick
Copy link
Author

For some reason, the above error isn't fatal on x86_64 and doesn't occur on s390x, but it fails the build on aarch64, ppc64le and i686. See https://koji.fedoraproject.org/koji/taskinfo?taskID=99064127 for full build logs.

Actually, failing to build one of the binaries doesn't seem to be fatal at all for the whole build process. That's dangerous, because binaries are missing. You should see make install also "fail" later, but non-fatally. This also needs to be fixed in the flite Makefiles.

(And your spec file uses a wildcard for packaging - I tend to list most every file explicitly in large projects, to detect changes. Your builds may succeed, but be missing certain binaries!)

Those failing koji builds trip over the other parallelism mentioned (in config/common_make_rules), and on x86_64 that just didn't happen to show up.

@rathann
Copy link
Contributor

rathann commented Mar 24, 2023

(And your spec file uses a wildcard for packaging - I tend to list most every file explicitly in large projects, to detect changes. Your builds may succeed, but be missing certain binaries!)

Thanks for catching this, I'll fix it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2.2: fails to build with make 4.4
2 participants