Bugzilla Bug 201786

app-accessability/flite will fail when --as-needed is defined in LDFLAGS,
removing it works:

gcc -march=k8 -O2 -pipe -msse3 -Wall    -o regexcomp regexcomp_main.o  -Wl,-O1
-Wl,--as-needed -L./lib -lflite -lm   -L../lib -lflite -lm
../lib/libflite.so: undefined reference to `sqrt'
../lib/libflite.so: undefined reference to `fmod'
../lib/libflite.so: undefined reference to `exp'
../lib/libflite.so: undefined reference to `sin'
../lib/libflite.so: undefined reference to `cos'
collect2: ld returned 1 exit status
make[1]: *** [regexcomp] Error 1
make: *** [.make_build_dirs] Error 2
 *
 * ERROR: app-accessibility/flite-1.2-r1 failed.
 * Call stack:
 *             ebuild.sh, line 1701:  Called dyn_compile
 *             ebuild.sh, line 1039:  Called qa_call 'src_compile'
 *             ebuild.sh, line   44:  Called src_compile
 *   flite-1.2-r1.ebuild, line   41:  Called die
 * The specific snippet of code:
 *      emake -j1 || die "Failed compilation"
 *  The die message:
 *   Failed compilation

Reproducible: Always

Created an attachment (id=138112) [details]
Workaround, that filters the flag

This makes it compile.

(From update of attachment 138112 [details])
That's just wrong solution... :)

Created an attachment (id=141574) [details]
Patch for 2 Makefiles that may fix the --as-needed bug

Managed to hack a few MAKEFILES and get this to work for me. Would make an
ebuild, but seeing i've done the hard work now to get it going (albeit a bit
nasty i think) you've got the easy job :)

I added a few more lines of output verbosity for debugging purposes, feel free
to remove them. ( this library does some magic which i deem to be weird (ie:
unpack an AR file to a dir and then recompile as a lib seems unusual to me, but
im no makefile guru or anything, i was simply _LUCKY_ enough to fix this myself
)

I just found patches that made it possible to commit flite 1.3 to the tree. 
Can you please check the new version and see if this issue is still present?

Thanks much.

William

(In reply to comment #4)
> I just found patches that made it possible to commit flite 1.3 to the tree. 
> Can you please check the new version and see if this issue is still present?
> 
> Thanks much.
> 
> William
>

I can't even confirm if the --as-needed problem exists any more because of a
new bug that will have to get fixed before I'll be able to know. 

386-linux-gnu/obj/lang/cmu_us_kal16/cmu_us_kal16_res.os
i686-pc-linux-gnu-gcc -fPIC   -I../../lang/usenglish  -I../../lang/cmulex
-I../../include -O2 -march=native -pipe  -Wall    -c cmu_us_kal16_residx.c -o
../../build/i386-linux-gnu/obj/lang/cmu_us_kal16/cmu_us_kal16_residx.os
a - cmu_us_kal16_diphone.os
a - cmu_us_kal16.os
a - cmu_us_kal16_lpc.os
a - cmu_us_kal16_res.os
a - cmu_us_kal16_residx.os
making in lib ...
making libflite.so
making libflite_cmulex.so
/bin/sh: line 0: cd: shared_os: No such file or directory
make[1]: *** [libflite.so] Error 1
make[1]: *** Waiting for unfinished jobs....
make: *** [build/i386-linux-gnu/obj//.make_build_dirs] Error 2
 *

Having run through this code enough to know what "shared_os" is, im going
"huh?, somethings bust"

cos its doing this:


# Used in the lib/ directory and in building new voices
%.so: %.shared.a
        @ echo making $@
        @ rm -rf shared_os && mkdir shared_os
        @ rm -f $@ $@.${PROJECT_VERSION} $@.${PROJECT_SHLIB_VERSION}
        @ (cd shared_os && ar x ../$<)
        @ (cd shared_os && $(CC) -shared
-Wl,-soname,$@.${PROJECT_SHLIB_VERSION} -o ../$@.${PROJECT_VERSION} *.os -L../
$($(@:%.so=%_LDLIBS)))
        @ ln -s $@.${PROJECT_VERSION} $@.${PROJECT_SHLIB_VERSION}
        @ ln -s $@.${PROJECT_SHLIB_VERSION} $@
        @ rm -rf shared_os

strangely, when i cd into the directory, source
app-accesbility/flite/temp/environment,  and then hit make, seems to run fine. 

(( weird ))

Created an attachment (id=141774) [details]
compile errors for flite 1.3

I get this error while trying to emerge flite 1.3

(In reply to comment #5)
> (In reply to comment #4)
> > I just found patches that made it possible to commit flite 1.3 to the tree. 
> > Can you please check the new version and see if this issue is still present?
> > 
> > Thanks much.
> > 
> > William
> >
> 
> I can't even confirm if the --as-needed problem exists any more because of a
> new bug that will have to get fixed before I'll be able to know. 
> 
> 386-linux-gnu/obj/lang/cmu_us_kal16/cmu_us_kal16_res.os
> i686-pc-linux-gnu-gcc -fPIC   -I../../lang/usenglish  -I../../lang/cmulex
> -I../../include -O2 -march=native -pipe  -Wall    -c cmu_us_kal16_residx.c -o
> ../../build/i386-linux-gnu/obj/lang/cmu_us_kal16/cmu_us_kal16_residx.os
> a - cmu_us_kal16_diphone.os
> a - cmu_us_kal16.os
> a - cmu_us_kal16_lpc.os
> a - cmu_us_kal16_res.os
> a - cmu_us_kal16_residx.os
> making in lib ...
> making libflite.so
> making libflite_cmulex.so
> /bin/sh: line 0: cd: shared_os: No such file or directory
> make[1]: *** [libflite.so] Error 1
> make[1]: *** Waiting for unfinished jobs....
> make: *** [build/i386-linux-gnu/obj//.make_build_dirs] Error 2
>  *

This is solved by setting MAKEOPTS to "-j1". Seems flite 1.3 is not parallel
build save.

I have changed the "emake" to "emake -j1" in the ebuild so that it will run
only one job.  Please check again and let me know if the issue with --as-needed
still exists.


Thanks much.

Nope, problem solved.

But honestly, -j1 is just as bad as filtering --as-needed.
Judging by all the warnings the build spits out this is really some wicked
software. ;)

(In reply to comment #9)
> Nope, problem solved.
> 


Looks solved for me too with -j1. Its peculiar, becuase the place its bugging
in with parallel build hasn't changed since 1.2 as far as I can tell, unless of
course its running 2 instances of the 'library unpack and compile' phase in
parallel for some reason where it wasn't before. 

You could of course re-mangle the make file so that instead of creating
shared_os for every unpack, you could do shared_os_$(SOMEJOBSUFFIX) 

> But honestly, -j1 is just as bad as filtering --as-needed.

But admittedly, forcing a single threaded build instead of multi-threaded is
hardly something to complain about, unlike --as-needed which changes resultant
output and runtime significantly ;)

I am closing this bug since it is fixed.

Thanks much for the report.