Ticket #52 (closed Enhancement: fixed)

Opened 1 year ago

Last modified 9 months ago

Relaytool: also compile an object file if a library can't be relayed

Reported by: res Assigned to: taj
Priority: Medium Milestone:
Component: devtools Version: 1.2.4
Severity: Normal Keywords:
Cc:

Description

Currently, when a library can't be relayed, compiler flags are emitted on the command line in order to supply the ..._is_present symbols. This seems insensible for two reasons: first, relaytool is supposed to be used with the linker command line, not the compiler's. Second, more code on the client side is needed, since a simple extern int libwhatever_is_present; may be mangled by the generated macro definitions. Thus it's more sensible to generate a stub even if the library can't be relayed, one that just hardcodes the ..._is_present values to 1.

Attachments

relaytool-stub-c.diff (3.3 kB) - added by res on 09/17/07 18:29:08.
relaytool-stub-c.2.diff (3.2 kB) - added by res on 10/11/07 16:36:51.

Change History

09/17/07 18:29:08 changed by res

  • attachment relaytool-stub-c.diff added.

09/21/07 18:18:24 changed by isak

  • owner changed from taj to mike.

Thanks for the patch.

I'm gonna get Mike Hearn involved on this, since he's the one who wrote relaytool and is most familiar with it.

09/22/07 15:52:37 changed by mike

Could you delete the commented out code please. Also, you might want to make the comments clearer (partly this is that I've forgotten some of the code, but # yes .... is not really clear to me).

Other than that, Looks Good To Me ;)

09/23/07 15:43:34 changed by taj

Could you rebuild it against the svn version of relaytool? There's been some major code changes/additions which makes the patches a little harder to apply (some chunks fail). You can download the latest version from http://trac.autopackage.org/browser/apbuild/trunk/relaytool?format=raw

Thanks again!

10/11/07 16:36:51 changed by res

  • attachment relaytool-stub-c.2.diff added.

10/11/07 16:38:03 changed by res

Diff against newer relaytool version.

Which comments are unclear?... Or just all in the stub generation stuff?

(follow-up: ↓ 6 ) 12/29/07 23:53:57 changed by taj

  • owner changed from mike to taj.

Sorry this has taken so long to look at again. It seems to introduce a bug where the -l flag isn't stripped from the output. This causes compile warnings (and possibly problems too): 

$ relaytool --relay ogg -logg
./libogg.so.0.stub.o -logg

It actually should spit out: 

./libogg.so.0.stub.o

Other than that, it looks good!

(in reply to: ↑ 5 ) 12/30/07 00:09:37 changed by res

Replying to taj:

Sorry this has taken so long to look at again. It seems to introduce a bug where the -l flag isn't stripped from the output.

Well, when the "fake" stub is generated the -l should not be stripped since otherwise the symbols from that library are not available - they're not provided by the stub after all.

Although, looking at the diff and trunk relaytool it seems that the -l emission got mixup between the "normal" and "fake" cases - the normal one should be wrapped by the $no_replace check, the "fake" one should emit unconditionally, I think.

12/30/07 14:22:18 changed by taj

  • status changed from new to closed.
  • resolution set to fixed.

Patch applied in r2427 w/ $no_replace check.

Thanks again for the patch!