Gregory H. Nietsky wrote:
>
> On 02/15/14 10:01, Bruce Dubbs wrote:
>> These automake tests pass if the static library is present and the .so
>> files are missing. `nm libfl.so.2.0.0` gives:
>>
>> U yylex
>>
>> U means undefined. The linker crashes on that. I'll revert the change
>> to flex that creates the dynamic libraries.
>>
>> -- Bruce
> his is correct yylex is implemented in the stub file generated and built
> into a .o file
> ie flex.l -> flex.c -> flex.o
>
> when linking you would -shared -o prog flex.o -lfl
>
> there possible work arrounds
> 1)Dont link with -lfl for this program it is not required [most likely
> scenario]
> 2)add the flex.o stub to the link list [not ideal and could break things]
> 3)add "extern int yylex (void) {return 0;}" or similar to the program
> [not ideal]
> 4)link against the static flex lib explicitly [if its not required this
> will bloat the binary slightly]
>
> this is not a problem with flex but the code not needing to be linked
> with flex.
>
> reverting to static only flex may be prudent for this cycle then release
> patches for affected
> packages in the next dev cycle to support dynamic libfl.
>
> there are 2 flavors of the so it seems a pic / nonpic version
> libfl_pic.so based on a guess from the name.
> this may for x86_64 make no difference as shared objects need to be PIC
> if i understand this right.
Yes, I think the problem may also be in the automake tests, but since
the current method of using the static flex library has worked for so
long, I don't see a really good reason to change that.
-- Bruce
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
