Summary: | app-accessibility/brltty : does not respect LD | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Agostino Sarubbo <ago> |
Component: | Current packages | Assignee: | Chris Brannon (RETIRED) <teiresias> |
Status: | RESOLVED FIXED | ||
Severity: | QA | CC: | accessibility |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | |||
Bug Blocks: | 243502 |
Description
Agostino Sarubbo
2013-09-05 14:49:29 UTC
It respects LD when the value is an absolute path. But when LD is a relative path, it is ignored. Is this not standard behavior? I'm guessing that you were using a relative path. The other ar bug is definitely a bug though, because the call is hard-coded. (In reply to Chris Brannon from comment #1) > It respects LD when the value is an absolute path. > But when LD is a relative path, it is ignored. > Is this not standard behavior? > I'm guessing that you were using a relative path. > > The other ar bug is definitely a bug though, because the call is > hard-coded. ld at link time should be called by the CC. Works in this case something like that? the correct order should be: $(CC) $(CFLAGS) $(LDFLAGS) $(OBJECTS) $(LIBS) In the brltty build system, ld isn't always called by cc. Instead, it is sometimes called like this: $(MKOBJ) $@ $(OBJ_FILES) where MKOBJ is defined as: $(LD) -r -o The build output that you included in your original bug report was using one of these MKOBJ calls, so it should have been using the value of LD that you gave at configure-time. Fixed in app-accessibility/brltty-4.5-r2. Thanks for the report. |