Closed Bug 511945 Opened 10 years ago Closed 3 years ago

OS/2 "make" no rule to make target `-ldl`

Categories

(Firefox Build System :: General, defect)

x86
OS/2
defect
Not set

Tracking

(Not tracked)

RESOLVED WONTFIX

People

(Reporter: wuno, Unassigned)

References

Details

Attachments

(2 files, 2 obsolete files)

User-Agent:       Mozilla/5.0 (OS/2; U; Warp 4.5; en-US; rv:1.9.3a1pre) Gecko/20090820 Minefield/3.7a1pre
Build Identifier: 

OS/2 make stops when linking mozjs.dll

Creating library file `js_static.lib'
echo js_static.lib
js_static.lib
rm -f mozjs.def
echo LIBRARY mozjs INITINSTANCE TERMINSTANCE > mozjs.def
echo PROTMODE >> mozjs.def
echo CODE    LOADONCALL MOVEABLE DISCARDABLE >> mozjs.def
echo DATA    PRELOAD MOVEABLE MULTIPLE NONSHARED >> mozjs.def
echo EXPORTS >> mozjs.def
make.exe[4]: *** No rule to make target `-ldl', needed by `mozjs.dll'.  Stop.
bug506845 added -lfoo to LIB_DEPS using the expression "-l%" 
http://hg.mozilla.org/mozilla-central/file/8fa93262b47b/config/rules.mk#l838
Not sure, why OS/2 make can't cope with it (linux gmake does).

Reproducible: Always
Blocks: 506845
Version: unspecified → Trunk
Using the same expression as in
http://hg.mozilla.org/mozilla-central/file/8fa93262b47b/config/rules.mk#l119
works
Attachment #395902 - Flags: review?(benjamin)
(In reply to comment #1)
> Using the same expression as in
> http://hg.mozilla.org/mozilla-central/file/8fa93262b47b/config/rules.mk#l119
> works

That's using addprefix and EXPAND_LIBNAME gets used through $(call ...).
LIBS_DEPS is different.

I think $(filter -l,$(1) $(LIBS)) would be just removing the dependency (undoing bug 506845).

It looks like make is just not finding dl.lib.
Is it in an unusual place?
Or maybe make just doesn't know the right place to look on OS/2.

Assuming .LIBPATTERNS is set correctly here, options are:

1) Move -ldl from LIBS to OS_LIBS (and it won't be a dependency)
2) Ensure that the vpath commands include the directory that has dl.lib.

I think 1 is probably preferable.
(In reply to comment #2)

> 
> I think $(filter -l,$(1) $(LIBS)) would be just removing the dependency
> (undoing bug 506845).
> 
> It looks like make is just not finding dl.lib.
> Is it in an unusual place?
> Or maybe make just doesn't know the right place to look on OS/2.
configure is able to find it and it's in a common place, where import libs are usually searched. BTW the full name is libdl.lib
> 
> Assuming .LIBPATTERNS is set correctly here, options are:
> 
> 1) Move -ldl from LIBS to OS_LIBS (and it won't be a dependency)
according to autoconf.mk it's already in OS_LIBS
> 2) Ensure that the vpath commands include the directory that has dl.lib.
>
(In reply to comment #3)
> (In reply to comment #2)

> BTW the full name is libdl.lib

That's relevant, thanks.

> > Assuming .LIBPATTERNS is set correctly here

configure.in has:

*-os2*)

    DLL_PREFIX=
    LIB_PREFIX=
    LIB_SUFFIX=lib

    DLL_SUFFIX=".dll"
    IMPORT_LIB_SUFFIX=lib

and rules.mk has

.LIBPATTERNS = $(if $(IMPORT_LIB_SUFFIX),$(LIB_PREFIX)%.$(IMPORT_LIB_SUFFIX)) $(LIB_PREFIX)%.$(LIB_SUFFIX) $(DLL_PREFIX)%$(DLL_SUFFIX) 

so make will be looking for dl.lib and dl.dll (not libdl.lib).

Is the prefix for import libs different from ordinary static libs and dlls?
Or should LIB_PREFIX be set differently?
Or is libdl special?

> > 1) Move -ldl from LIBS to OS_LIBS (and it won't be a dependency)
> according to autoconf.mk it's already in OS_LIBS

I guess -ldl is being added to LIBS in js/src/Makefile.in through NSPR_LIBS?
(In reply to comment #4)
> (In reply to comment #3)
> > (In reply to comment #2)
> 
> > BTW the full name is libdl.lib
> 
> That's relevant, thanks.
> 
> > > Assuming .LIBPATTERNS is set correctly here
> 
> configure.in has:
> 
> *-os2*)
> 
>     DLL_PREFIX=
>     LIB_PREFIX=
>     LIB_SUFFIX=lib
> 
>     DLL_SUFFIX=".dll"
>     IMPORT_LIB_SUFFIX=lib
> 
> and rules.mk has
> 
> .LIBPATTERNS = $(if $(IMPORT_LIB_SUFFIX),$(LIB_PREFIX)%.$(IMPORT_LIB_SUFFIX))
> $(LIB_PREFIX)%.$(LIB_SUFFIX) $(DLL_PREFIX)%$(DLL_SUFFIX) 
> 
> so make will be looking for dl.lib and dl.dll (not libdl.lib).
Yep, that's the problem here

> Is the prefix for import libs different from ordinary static libs and dlls?
> Or should LIB_PREFIX be set differently?
> Or is libdl special?
It's not unique, there is a handful of libs ported from unix that have the lib prefix. Relevant for mozilla code is beside libdl.lib also libsocket.lib

I renamed in usr\lib libdl*.* and in usr\lib\tcpipv4 libsocket*.* to dl*.* and socket*.*, respectively, and was able to overcome the "make" problem (currently I'm in content)
Alternatively, adding LIB_PREFIX=lib to the os2 section in configure.in worked also (I didn't do a complete build yet with this configuration, but was able to compile beyond xpcom). It appears to do no harm to import libs that don't have the lib prefix
Attachment #395902 - Flags: review?(benjamin)
Having or not having the lib prefix shouldn't matter on OS/2 excepting the search order, from the libc release notes,
shared: (default, -Bshared, -call_shared, -dy)
  1. libfoo_dll.a
  2. foo_dll.a
  3. libfoo.a
  4. foo.a
  5. libfoo_s.a
  6. foo_s.a

Of course with -Zomf the suffix is .lib
Also both libdl and libsocket are now just stubs with the sockets and dlfcn being in libc so it is an option to just not link with them.
Strange, while -ldl and -lsocket make the troubles mentioned, -lm which is also called when linking mozjs.dll does _not_, although there is also only a libm.{a,lib} in /usr/lib.

As Dave suggested, I excluded checks for libdl,libm and libsocket for OS/2 in configure.in and commented out OS_LIBS='-lsocket' in nsprpub/configure.in and succeeded to build a working browser (flash-plugin is also working). Even an older build where I substituted the nspr dlls against those which were not linked with libdl and libsocket started w/o problems.

Comparing the log from this build against that from the failing build I found interesting differences:
1) running configure in js/src
--with-nspr-libs='-LE:/mozbuild1/dist/lib -lplds4 -lplc4 -lnspr4' (working)
--with-nspr-libs='-LE:/mozbuild1/dist/lib -lplds4 -lplc4 -lnspr4 -ldl -lsocket' (failing)
2) sed < E:/usr/src/hg/mozilla-central/js/src/js-config.in > js-config.tmp...
-e 's|@JS_CONFIG_LIBS@|-LE:/mozbuild1/dist/lib -lplds4 -lplc4 -lnspr4  -lm |' (working, dunno where -lm comes from as I thought to have the check disabled)
-e 's|@JS_CONFIG_LIBS@|-LE:/mozbuild1/dist/lib -lplds4 -lplc4 -lnspr4 -ldl -lsocket -lsocket -ldl -lm  -lm |' (failing)

So, not only for the purpose of fixing this bug here, it's the question whether we should avoid to link with libdl and libsocket at all.
I think that linking with -lm has always been a no-op though I do notice that even EMX has m.a and m.lib, both very small like klibc.
libdl is also definitely just a stub and can be safely removed.
libsocket is bit more complicated. Basically I've never needed to link against since klibc ver 6 but it may be needed for using the old TCPIP stack. Since we don't support it anyways, it should be fine to remove it, especially since your testing shows it is not needed and we no longer support libc v5 or EMX.
I also think that we should standardize on using the lib prefix as we don't support building on FAT anyways.
We might have to rename some external libs like mzfntcfgft but I believe a simple rename would be good enough.
Ideally we should also be using _dll.lib as the suffix for import libs and _s.lib for static libs. This would no longer work due to the checkin from bug#506845 but is not important as Mozilla doesn't support --enable-shared and --enable-static used together.
(In reply to comment #8)
> I think that linking with -lm has always been a no-op though I do notice that
> even EMX has m.a and m.lib, both very small like klibc.
Are you saying that we were doing sth wrong to link with libm.lib or m.lib?
from js/src/Makefile.in#548
# - EXTRA_DSO_LDOPTS includes the NSPR -L and -l flags.
# - OS_LIBS includes libraries selected by the configure script
# - EXTRA_LIBS includes libraries selected by this Makefile.
JS_CONFIG_LIBS=$(EXTRA_DSO_LDOPTS) $(OS_LIBS) $(EXTRA_LIBS)
piped through sed into js-config:
-e 's|@JS_CONFIG_LIBS@|-LE:/mozbuild1/dist/lib -lplds4 -lplc4 -lnspr4 -ldl
-lsocket -lsocket -ldl -lm  -lm |' (the failing one)
$(EXTRA_DSO_LDOPTS) gets resolved to -LE:/mozbuild1/dist/lib -lplds4 -lplc4 -lnspr4 -ldl -lsocket (NSPR_LIBS in autoconf.mk) 
$(OS_LIBS) to -lsocket -ldl -lm (created by configure)
$(EXTRA_LIBS) to -lm
When I patch only nsprpub/configure in to not set OS_LIBS to -lsocket and to not check for -ldl, EXTRA_DSO_LDOPTS is only -lplds4 -lplc4 -lnspr4 and then the build succeeds, though there is still -lsocket -ldl -lm from $(OS_LIBS) and these are recognized properly.
(In reply to comment #8)
Not something wrong as it seems everything wants to link with -lm, just unneeded as the math stuff has always been in libc.
I really don't understand much of this, so the following request may be irrelevant, but...

In coming up with a solution for this, could you avoid any that require files to be in Unix-standard locations?  I've always been able to build moz, run Samba, etc, without the need for any usr, var, sbin, or whatever.  I'd really like to keep it that way.

FYI... I tried the trick of renaming libdl* & libsocket* but my build still failed.  I then created a /user/lib directory and copied the files from G:\gcc335\lib.  When the build succeeded it made me unhappy :-)
(In reply to comment #12)
Did you do a make distclean or better delete your object directory after renaming libdl* and libsocket* ?
If not you might want to try.
(In reply to comment #13)
> (In reply to comment #12)
> Did you do a make distclean or better delete your object directory
> after renaming libdl* and libsocket* ?

I never do incremental builds.  I either rebuild the specific library I'm working on, or delete the object directory + the 3 configures and build from scratch.  In this case, it was the latter.
(In reply to comment #14)
Ok, I was just wondering if the file names were cached somewhere.
Anyways it doesn't matter as renaming the system libs is not a good solution.
While adding LIBPREFIX=lib is the best solution it is not very practical as quite a few library names seem to be hard coded and patches would have to be applied to various modules at the same time.
For now best to remove -ldl and -lsocket from nsprub/configure.in. I'll attach the simple patch.
As Walter said in comment #10, removing -lsocket from OS_LIBS and not checking for -ldl removes them from EXTRA_DSO_LDOPTS allowing the build to succeed
Attachment #396392 - Attachment is obsolete: true
Attachment #396393 - Attachment is obsolete: true
I don't get it: why are you patching nsprpub/configure.in when the build failure is in js/src/?

But I agree that we shouldn't start renaming libs on our build systems just to get back to a workable state.
Reread comment #4 and comment #10. -ldl (and -lsocket) are being added to LIBS in js/src/Makefile.in through NSPR_LIBS.
Perhaps we should remove -ldl and -lsocket from all the configure.in? I was under the impression that they are all separate modules.
(In reply to comment #18)
> Created an attachment (id=396394) [details]
> Same patch with extra stuff removed.
Dave, though your patch helps us to overcome the trouble here I doubt that it is the correct solution for the problem here. I've opened bug512504 to remove the dependencies on stub libs whose functions live in libc. Could you please attach again in bug512504?
Do you want to make .LIBPATTERNS to better represent the search described in comment 6?

If OS libraries are not in directories that make searches (comment 12), then perhaps those directories need to be added to the vpaths.
"gcc --print-search-dirs" has this info if gcc is being used.
Perhaps the output could be parsed in configure.in and added to vpaths in rules.mk.
(In reply to comment #22)
> If OS libraries are not in directories that make searches (comment 12), > then perhaps those directories need to be added to the vpaths.

An existing environment variable, 'LIBRARY_PATH', identifies the 4 directories that contain all general-purpose libraries (including all those mentioned so far).  Getting 'make' to search them would probably resolve the issue.
OS/2 is no longer a supported platform.
Status: NEW → RESOLVED
Closed: 3 years ago
Resolution: --- → WONTFIX
Product: Core → Firefox Build System
You need to log in before you can comment on or make changes to this bug.