204177 - fix IPC ports bustage

Status: RESOLVED FIXED

(Core :: IPC, defect)

Description

[Jonathan Wilson]

I tried to build the new IPC code, it didnt build. It built lockmodule.dll but
it then asked for liblockmodule.dll.

Comment 1

[Jonathan Wilson]

BTW, if this isnt going to be fixed anytime soon, someone should modify the
win32 build instructions to tell MingW builders to build with
--disable-profilesharing

Comment 2

[Jonathan Wilson]

make[1]: *** No rule to make target `liblockmodule.dll', needed by `libs'.  Stop.
make: *** [all] Error 2

Thats the error I got.
Looks like some build rule on MingW is causing one bit of the system to build a
lockmodule.dll then another bit to ask for liblocmodule.dll

Comment 3

[Axel Hecht]

note that this particular Makefile is breaking the static builds, too.

Comment 4

[[e-mail]]

looks like the same error that linux balsa dep (ports) is showing.

a bunch of other bustage on ports too.

Comment 5

[Conrad Carlen (not reading bugmail)]

Looking at it...

Comment 6

[Conrad Carlen (not reading bugmail)]

> make[1]: *** No rule to make target `liblockmodule.dll', needed by `libs'.

Since this is killing both static builds, is it possible that the expected
lib*.dll is not being produced because it's a static build? Instead, only a
static lib?

Comment 7

[Conrad Carlen (not reading bugmail)]

From ipc/extensions/lock/src/module/Makefile.in:

IS_COMPONENT = 1
NO_DIST_INSTALL = 1

I think IS_COMPONENT is having bad side-affects with the static build. This
makefile is building a component that the ipc code loads - but it's not a
component as far as the rest of the build is concerned. It was needed at some
point for OS X in order to get the linker args which you get with IS_COMPONENT.
Doing a Mac static build right now to test this.

Comment 8

[cls]

.

Comment 9

[Darin Fisher]

ipc/extensions/lock/src/module/Makefile.in
 
probably shouldn't have IS_COMPONENT=1 in it.  the code in there is a daemon
module.  currently, even in static mozilla builds, the daemon code should
continue to build dynamically loaded modules.  i'm guessing that IS_COMPONENT=1
just crept in there by accident.

Comment 10

[Conrad Carlen (not reading bugmail)]

Darin, see comment 7 - IS_COMPONENT was needed. In order to get it to build a
shared lib, even in a static build, it needs FORCE_SHARED_LIB. That will require
 FORCE_USE_PIC here and there... 

Comment 11

[Conrad Carlen (not reading bugmail)]

Attachment: patch to fix static build bustage

Comment 12

[Conrad Carlen (not reading bugmail)]

r=, somebody? Fixes my Mach-O static build, trying others now...

Comment 13

[Darin Fisher]

Comment on attachment 122322 [details] [diff] [review]
patch to fix static build bustage

sr=darin

Comment 14

[Conrad Carlen (not reading bugmail)]

Checked in. That should fix balsa and worms. nebiros is hopefully fixed. That
leaves IRIX and OS/2.

Comment 15

[Darin Fisher]

Attachment: wishful patch for irix bustage

Comment 16

[Darin Fisher]

Comment on attachment 122348 [details] [diff] [review]
wishful patch for irix bustage

got a verbal sr=dbaron on this patch, and checked in.  let's see if it does the
trick.

Comment 17

[Conrad Carlen (not reading bugmail)]

Attachment: another patch to fix static build bustage

Camino Tinderbox gives: make[3]: *** No rule to make target
`../../dist/lib/liblockmodule.a', needed by `mozilla-bin'.  Stop.

Looks like anything which uses EXPORT_LIBRARY = 1 causes it to end up in
config/final-link-libs. But, since FORCE_SHARED_LIB was used, it doesn't exist.


The question is: does EXPORT_LIBRARY need to be removed from all the makefiles
in ipc/ipcd? Or, as long as static libs exist, they'll just be dead-stripped by
the linker during staticmod link?

Comment 18

[Darin Fisher]

Comment on attachment 122353 [details] [diff] [review]
another patch to fix static build bustage

sr=darin

Comment 19

[Jonathan Wilson]

MingW is still broken.
Looking at the makefile.in for the directory in question, it looks like the
problem on MingW is that it uses $(LIB_PREFIX) instead of $(DLL_PREFIX) in the
_IPC_FILES defintion. On Visual C++ this doesnt matter because $(LIB_PREFIX) and
$(DLL_PREFIX) are the same. But for MingW, this is whats causing the error I think.

Comment 20

[Conrad Carlen (not reading bugmail)]

Attachment: another static build patch

With this, the full build finally links.

Comment 21

[Jonathan Wilson]

Attachment: patch for the mingw bustage

This should fix the MingW bustage caused by usage of $(LIB_PREFIX) instead of
$(DLL_PREFIX). Dont know if there is a logical reason to use $(LIB_PREFIX) with
$(DLL_SUFFIX) or if it was a mistake but it breaks MingW :)

Comment 22

[Dan Mosedale (:dmosedale, :dmose)]

Comment on attachment 122370 [details] [diff] [review]
patch for the mingw bustage

This looks like the correct fix to me. sr=[e-mail]

Comment 23

[Sergei Dolgov]

BeOS port is still in bustage:
http://bugzilla.mozilla.org/show_bug.cgi?id=204298

Comment 24

[Axel Hecht]

OS/2 bustage is at least a problem of XP_WIN != !XP_UNIX in ipcTransport.*
Not sure what OS/2 really needs to do, of course.

Comment 25

[Sergei Dolgov]

*** Bug 204298 has been marked as a duplicate of this bug. ***

Comment 26

[Axel Hecht]

Attachment: fix checking out standalone modules

Comment 27

[Axel Hecht]

Comment on attachment 122476 [details] [diff] [review]
fix checking out standalone modules

ipc needs to copy all code in client.mk, not just the fun bits, cls, mind
reviewing this?

Comment 28

[Axel Hecht]

Comment on attachment 122476 [details] [diff] [review]
fix checking out standalone modules

cls suggested that I try to get bryner to review this fixup in client.mk

Comment 29

[Darin Fisher]

Comment on attachment 122370 [details] [diff] [review]
patch for the mingw bustage

r=darin

Comment 30

[Asa Dotzler [:asa]]

Comment on attachment 122370 [details] [diff] [review]
patch for the mingw bustage

a=asa (on behalf of drivers) for checkin to 1.4.

Comment 31

[Axel Hecht]

Comment on attachment 122476 [details] [diff] [review]
fix checking out standalone modules

this patch fixes that xpcom standalone and other standalone builds like
transformiix pull ipc. requesting 1.4 approval

Comment 32

[(not reading, please use [e-mail] instead)]

Comment on attachment 122476 [details] [diff] [review]
fix checking out standalone modules

a=sspitzer

Comment 33

[Axel Hecht]

Comment on attachment 122476 [details] [diff] [review]
fix checking out standalone modules

this patch is in. thanx.

Comment 34

[Darin Fisher]

so can this bug be closed now?

Comment 35

[Dan Mosedale (:dmosedale, :dmose)]

I don't think the MinGW patch has been checked in yet.  I'll try and do that in
the next few days, unless someone else gets to it first.

Comment 36

[Dan Mosedale (:dmosedale, :dmose)]

MinGW gcc patch has been checked in.

Comment 37

[timeless]

I made changes to get BeOS building.

I believe that when IPC landed people assured me that it would not be enabled
for places where it wouldn't work. The world is not just win or unix.
You can't assume that !win is always the same as unix or vice versa,
whatever conditions you choose in once file should be used for the same
codepath in other files.

Comment 38

[Conrad Carlen (not reading bugmail)]

It's a bit overboard to change the status/platform to blocker/All if it's
building everywhere except BeOS and OS/2.

The problem now is that it should not be nescesary to use
--disable-profilesharing in order to build. We need some logic in configure.in
which turns that off for any platforms on which it doesn't build. AFAIK, that's
BeOS, OS/2, and VMS.

I could use some pointers on configure.in, but, would something like this do it?

MOZ_PROFILESHARING=1
case "$target" in
  *-beos*)
    MOZ_PROFILESHARING=
    ;;
  *-openvms*)
    MOZ_PROFILESHARING=
    ;;
  *-os2*)
    MOZ_PROFILESHARING=
    ;;
esec

Comment 39

[timeless]

Just some terminology from the page which describes those terms:
     Blocker   Blocks development and/or testing work
     All (...; cross-platform bug)

My default BeOS build failed. That blocked my development work <period>
It happens on more than just Windows XP and OS/2 => All

As for configure, how about making it opt in instead of opt out?

set it to 1 for unix and windows, when other platforms implement it, let them
add a line which sets it to 1 for their platform.

Comment 40

[Darin Fisher]

timeless: BeOS, VMS, and OS2 are not officially supported by mozilla.org (they
are ports).  we try not to bust the ports, but we try even harder not to bust
the primary platforms.  it simply can't be the job of every developer to
maintain the ports.  we can all try, but it can't be our first priority. 
blocker status seems misused if only the ports are busted.  moreover, your
development is not hindered... you can add --disable-profilesharing to your
mozconfig.  so, why don't you help out with the patch (since you are capable of
testing on BeOS) instead of fussing over the status of this bug?

conrad: your approach looks right to me.

Comment 41

[Darin Fisher]

Attachment: patch to disable profilesharing on os2, openvms, and beos

Comment 42

[timeless]

While we're listing os's that don't do domain sockets:
QNX6.0/6.1

Please add that to your list :)

Comment 43

[Brian Ryner (not reading)]

Comment on attachment 123378 [details] [diff] [review]
patch to disable profilesharing on os2, openvms, and beos

If you're going to do it this way, please indent the block under the *)
appropriately.	Personally, I'd do it a bit differently... after the
MOZ_ARG_DISABLE_BOOL() I'd put:

case $target in 
  *-os2*|*-openvms*|*-beos*)
  MOZ_PROFILESHARING=
  ;;
esac

Also, please add qnx (I'm not sure what the target string is for that offhand)
as timeless mentioned.	r=bryner with those addressed.

Comment 44

[Paul]

Comment on attachment 123378 [details] [diff] [review]
patch to disable profilesharing on os2, openvms, and beos

please remove beos from this list.  currently, even though it doesn't work, the
ipc code does not stop the beos build from completing.	Plus, I almost have a
native beos implementation completed, and don't want to have to patch this file
again.

Comment 45

[Darin Fisher]

What if anything still needs to be done for this bug?  The ports all seem to be
fine now.  Does that mean we can mark this as fixed?

(taking bug)

Comment 46

[timeless]

i have no idea what the status on qnx is, my guess is it's still hosed. my
computers should arrive next week, so maybe i'll get root and try qnx w/ this flag.

as for beos, afaik it still doesn't have an impl, so anything that forcefully
uses this stuff will fail miserably (at runtime).

Comment 47

[Darin Fisher]

Well, the summary suggests that some ports build doesn't compile on account of
code in ipc/ipcd.  I believe that is no longer the case or else someone would
have raised a red flag by now.  I understand that the IPCD code may not be
functional on some platforms, but that doesn't really meet the definition of
"bustage" especially since the IPCD code is currently unused.  It sounds to me
like the task of implementing IPCD for the various ports where it is not
implemented would be better handled by separate bugs for each port.

If anyone knows of a build that is busted on the trunk because of code under
ipc/ipcd, please speak up.  Otherwise, I think we can close this bug.

Comment 48

[David G King]

(In reply to comment #47)
> If anyone knows of a build that is busted on the trunk because of code under
> ipc/ipcd, please speak up.  Otherwise, I think we can close this bug.


Resolving, please reopen as needed.