Skip Menu |
 

This queue is for tickets about the Module-Build CPAN distribution.

Report information
The Basics
Id: 34438
Status: stalled
Priority: 0/
Queue: Module-Build

People
Owner: Nobody in particular
Requestors: mschwern [...] cpan.org
Cc:
AdminCc:

Bug Information
Severity: Unimportant
Broken in:
  • 0.2808
  • 0.2808_01
Fixed in: (no value)



Subject: Multiple XS files with c_source causes relink
Download (untitled) / with headers
text/plain 1.8k
When there are multiple XS files and a c_source set, Module::Build will sometimes try to relink the first object file causing the compilation to fail. To see this happen, unpack the tarball, run Build.PL and then continuously clean, build and rebuild until it fails. Should take just a few iterations. $ perl -wle 'system(q[./Build clean && ./Build && echo "Build" && echo "Rebuild" && ./Build]) while $? == 0' Eventually it should fail something like this (YMMV for your OS) Rebuild env MACOSX_DEPLOYMENT_TARGET=10.3 cc -L/sw/lib -bundle -undefined dynamic_lookup -L/usr/local/lib -L/opt/local/lib -o blib/arch/auto/MB/Foo/Other/Other.bundle lib/MB/Foo/Other.o ./test.o ./lib/MB/Test.o ./lib/MB/Foo/Other.o /usr/libexec/gcc/i686-apple-darwin8/4.0.1/ld: multiple definitions of symbol _XS_MB__Other_other lib/MB/Foo/Other.o definition of _XS_MB__Other_other in section (__TEXT,__text) ./lib/MB/Foo/Other.o definition of _XS_MB__Other_other in section (__TEXT,__text) /usr/libexec/gcc/i686-apple-darwin8/4.0.1/ld: multiple definitions of symbol _boot_MB__Other lib/MB/Foo/Other.o definition of _boot_MB__Other in section (__TEXT,__text) ./lib/MB/Foo/Other.o definition of _boot_MB__Other in section (__TEXT,__text) collect2: ld returned 1 exit status error building blib/arch/auto/MB/Foo/Other/Other.bundle from lib/MB/Foo/Other.o ./test.o ./lib/MB/Test.o ./lib/MB/Foo/Other.o at /usr/local/lib/site_perl/ExtUtils/CBuilder/Base.pm line 213. This is because link_c() is linking each library against all the object files. process_support_files() just puts all the object files into one big list. Because it builds last, this means lib/MB/Test.o is sometimes newer than lib/MB/Foo/Other.o and thus MB thinks recompilation is necessary. I believe each library should link only against its own object file. I may be wrong but it does work. The attached patch does so.
Subject: MB-Test.tgz
Download MB-Test.tgz
application/x-gzip 621b

Message body not shown because it is not plain text.

Subject: xs.patch
Download xs.patch
text/x-diff 1k
--- lib/Module/Build/Base.pm (revision 55266) +++ lib/Module/Build/Base.pm (local) @@ -2270,7 +2270,7 @@ my $files = $self->rscan_dir($p->{c_source}, file_qr('\.c(pp)?$')); foreach my $file (@$files) { - push @{$p->{objects}}, $self->compile_c($file); + $p->{objects}{$file} = $self->compile_c($file); } } @@ -3972,18 +3972,19 @@ $self->add_to_cleanup($spec->{lib_file}); - my $objects = $p->{objects} || []; + my @objects = $spec->{obj_file}; + push @objects, $p->{objects}{$spec->{lib_file}} + if $p->{objects}{$spec->{lib_file}}; return $spec->{lib_file} - if $self->up_to_date([$spec->{obj_file}, @$objects], - $spec->{lib_file}); + if $self->up_to_date(\@objects => $spec->{lib_file}); my $module_name = $self->module_name; $module_name ||= $spec->{module_name}; $self->cbuilder->link( module_name => $module_name, - objects => [$spec->{obj_file}, @$objects], + objects => \@objects, lib_file => $spec->{lib_file}, extra_linker_flags => $p->{extra_linker_flags} );
From: kwilliams [...] cpan.org
Download (untitled) / with headers
text/plain 612b
On Wed Mar 26 05:28:10 2008, MSCHWERN wrote: Show quoted text
> This is because link_c() is linking each library against all the object > files. process_support_files() just puts all the object files into one > big list.
Yeah, it's definitely the wrong thing to do. It's been like that since the beginning of time, the idea was to support builds with an XS file and a few .c files, all going into one loadable XS module. Obviously that one use case shouldn't have driven the entire design. What I think needs to happen is to let the author explicitly say which ingredients should get mixed into which XS build. -Ken
CC: mschwern [...] cpan.org
Subject: Re: [rt.cpan.org #34438] Multiple XS files with c_source causes relink
Date: Wed, 26 Mar 2008 17:21:23 -0700
To: bug-Module-Build [...] rt.cpan.org
From: Michael G Schwern <schwern [...] pobox.com>
Ken Williams via RT wrote: Show quoted text
> <URL: http://rt.cpan.org/Ticket/Display.html?id=34438 > > > On Wed Mar 26 05:28:10 2008, MSCHWERN wrote:
>> This is because link_c() is linking each library against all the object >> files. process_support_files() just puts all the object files into one >> big list.
> > Yeah, it's definitely the wrong thing to do. It's been like that since the beginning of time, the > idea was to support builds with an XS file and a few .c files, all going into one loadable XS > module. Obviously that one use case shouldn't have driven the entire design. > > What I think needs to happen is to let the author explicitly say which ingredients should get > mixed into which XS build.
Is that necessary? Don't they all get linked together in the end? -- 87. If the thought of something makes me giggle for longer than 15 seconds, I am to assume that I am not allowed to do it. -- The 213 Things Skippy Is No Longer Allowed To Do In The U.S. Army http://skippyslist.com/list/


This service is sponsored and maintained by Best Practical Solutions and runs on Perl.org infrastructure.

Please report any issues with rt.cpan.org to rt-cpan-admin@bestpractical.com.