Object Splitting and the Base Package Makefile

Michael Weber michaelw at foldr.org
Sun Oct 13 11:33:34 EDT 2002


* Wolfgang Thaller <wolfgang.thaller at gmx.net> [2002-10-09T00:42+0200]:
> When building the library archive libHSbase.a, the makefile system 
> includes not only all the split object files, but also the file 
> PrimopWrappers.o. Consequently [at least on Mac OS X], ranlib generates 
> a warning about duplicate symbols and fails to generate a sorted symbol 
> table for the library (it generates an unsorted symbol table instead, 
> which leads to slower linking).
> Happens with the current HEAD.

In a related issue, it seems that in ghc-5.04 libraries *_hsc.o files
are left out when linking with SplitObjs=YES.

michaelw at stargate:.../build-stage1/libraries/network$ rm libHSnetwork.a
michaelw at stargate:.../build-stage1/libraries/network$ make libHSnetwork.a
rm -f libHSnetwork.a libHSnetwork.a.tmp
(echo  cbits/ancilData.o; /usr/bin/find Network_split
Network/BSD_split Network/CGI_split Network/Socket_split
Network/URI_split -name '*.o') | xargs ar q libHSnetwork.a
: libHSnetwork.a
michaelw at stargate:.../build-stage1/libraries/network$ rm libHSnetwork.a
michaelw at stargate:.../build-stage1/libraries/network$ make libHSnetwork.a SplitObjs=NO
rm -f libHSnetwork.a
/usr/bin/ar clqs    libHSnetwork.a  Network.o Network/BSD.o
Network/CGI.o Network/Socket.o Network/URI.o Network/BSD_hsc.o
Network/Socket_hsc.o cbits/ancilData.o 
: libHSnetwork.a
michaelw at stargate:.../build-stage1/libraries/network$ make show VALUE=EXTRA_OBJS
EXTRA_OBJS="cbits/ancilData.o"
michaelw at stargate:.../build-stage1/libraries/network$ make show VALUE=C_OBJS
C_OBJS="Network/BSD_hsc.o Network/Socket_hsc.o cbits/ancilData.o"
michaelw at stargate:.../build-stage1/libraries/network$

With SplitObjs=YES, Network/BSD_hsc.o and Network/Socket_hsc.o are
missing from the archive, since different linking commands are used.

After a short look into .../mk/target.mk, $(EXTRA_OBJS) seems to be
the culprit.

Can somebody please verify that it is indeed the case and the attached
fix doesn't break anything else (and do a check-in, if so)? (I'm a bit
short on time).


Cheers,
Michael
p.s.: is $(STUBOBJS) needed there?



More information about the Glasgow-haskell-bugs mailing list