Skip to content
This repository has been archived by the owner on Jan 30, 2023. It is now read-only.

linux build failing #4

Closed
2 tasks done
rhelmer opened this issue Aug 8, 2018 · 23 comments
Closed
2 tasks done

linux build failing #4

rhelmer opened this issue Aug 8, 2018 · 23 comments

Comments

@rhelmer
Copy link
Contributor

rhelmer commented Aug 8, 2018

libprio is failing to build for Linux, although it works for macOS (which is a very similar environment which makes the failure kinda confusing to me)

@henrycg
Copy link
Collaborator

henrycg commented Aug 8, 2018

The moz.build file should not include the pclient/main.c file in the SOURCES array (line 34):
https://hg.mozilla.org/try/file/f25a14180c85b64334e028fea81f94ed71917454/third_party/prio/moz.build#l34
The pclient directory just contains a test/example program.

This is probably responsible for the multiple definitions of main problem. There may be other build problems too.

@rhelmer
Copy link
Contributor Author

rhelmer commented Aug 8, 2018

Thanks, pushed a new tryserver build:
https://treeherder.mozilla.org/#/jobs?repo=try&revision=4b019f9365e07c8544bc37d5cbcfb5038d9bda25

Will check it in a bit and post if there are still any problems.

@rhelmer
Copy link
Contributor Author

rhelmer commented Aug 8, 2018

This gets us further (thanks!) but seeing a ton of "undefined references" in https://treeherder.mozilla.org/logviewer.html#?job_id=192717640&repo=try&lineNumber=38958

@henrycg
Copy link
Collaborator

henrycg commented Aug 8, 2018

Hmm... I wonder why it's not linking properly against NSS.

Is there an easy way to get a diff between this version of the source and one that works? I wonder if one of the moz.build files got messed up along the way.

@franziskuskiefer
Copy link
Contributor

I don't see any changes that could've caused this (the error is coming from security/apps that you didn't touch as far as I can see), but the error message is pretty clear in that it''s not linking to NSS.
Firefox offers ways to get NSS initialised etc. that could be used. But not sure if that makes sense, considering that it should work standalone as well.

@henrycg
Copy link
Collaborator

henrycg commented Aug 8, 2018

When building locally, I get many errors of the form:
25:38.08 /usr/bin/ld.gold: error: /gecko-dev/obj-x86_64-pc-linux-gnu/toolkit/library/../../third_party/prio/prg.o: requires dynamic R_X86_64_PC32 reloc against 'PK11_GetInternalSlot' which may overflow at runtime; recompile with -fPIC
before the other linker errors. It looks sort of similar to what happened here:
https://bugzilla.mozilla.org/show_bug.cgi?id=1194520

@rhelmer
Copy link
Contributor Author

rhelmer commented Aug 8, 2018

Hm. Well it's clear one of my patches is causing it, I'll bisect to see which.

@rhelmer
Copy link
Contributor Author

rhelmer commented Aug 8, 2018

Actually, bisection isn't going to be very useful here, as we need all the patches except the DOM one (vendoring both libprio and msgpack plus moz.build for each), I'll start digging around in the build config and asking build folks.

@rhelmer
Copy link
Contributor Author

rhelmer commented Aug 8, 2018

Build folks suspect this has something to do with MOZ_FOLD_LIBS being set only on macOS (aka darwin) not Linux... I don't really understand what this setting does yet.

@rhelmer
Copy link
Contributor Author

rhelmer commented Aug 8, 2018

Poking around in bugzilla for code outside of NSS that uses these symbols, noticed https://bugzilla.mozilla.org/show_bug.cgi?id=903135 - trying something similar with USE_LIBS in https://treeherder.mozilla.org/#/jobs?repo=try&revision=90efd6352eb7ea5cab81da764676c4993e850fdc (may need to #ifdef this for different platforms if it works...)

@rhelmer
Copy link
Contributor Author

rhelmer commented Aug 8, 2018

Oops, the way shared libraries are named has changed since that old bug - cribbing from a modern example (sqlite) instead https://searchfox.org/mozilla-central/source/config/external/sqlite/moz.build#16

https://treeherder.mozilla.org/#/jobs?repo=try&revision=d689fe49cb946b8af242ad1b1b938412506a4523

@rhelmer
Copy link
Contributor Author

rhelmer commented Aug 8, 2018

Hm. None of this is helping so far, going to focus on Windows for a bit and ask around for help.

@henrycg
Copy link
Collaborator

henrycg commented Aug 8, 2018

If I add NoVisibilityFlags() to the top of third_party/prio/moz.build, the NSS linker errors disappear. There are still some msgpack errors though.

I have no idea what NoVisibilityFlags() does though... it doesn't seem to be documented anywhere.

@henrycg
Copy link
Collaborator

henrycg commented Aug 8, 2018

If I use the following file for third_party/prio/moz.build, I can build the browser on Linux. The only changes are that I included the NoVisibilityFlags() line and included the msgpack source files here directly. (I couldn't figure out how to get libprio to link against msgpack otherwise.)

Edit: I also included the MPI file mpcpucache.c in SOURCES.

# vim: set filetype=python:
# This Source Code Form is subject to the terms of the Mozilla Public
# License, v. 2.0. If a copy of the MPL was not distributed with this
# file, You can obtain one at http://mozilla.org/MPL/2.0/.
#

DEFINES['PRIO_BUILD_LIBRARY'] = True

LOCAL_INCLUDES += [
    '/third_party/msgpack/include',
    'include',
]

EXPORTS += [
    'include/mprio.h',
]

# We allow warnings for third-party code that can be updated from upstream.
AllowCompilerWarnings()

# Does something that we don't understand.
NoVisibilityFlags()

SOURCES += [
    '../../security/nss/lib/freebl/mpi/montmulf.c',
    '../../security/nss/lib/freebl/mpi/mp_comba.c',
    '../../security/nss/lib/freebl/mpi/mp_gf2m.c',
    '../../security/nss/lib/freebl/mpi/mpcpucache.c',
    '../../security/nss/lib/freebl/mpi/mpi.c',
    '../../security/nss/lib/freebl/mpi/mplogic.c',
    '../../security/nss/lib/freebl/mpi/mpmontg.c',
    '../../security/nss/lib/freebl/mpi/mpprime.c',
    '../../security/nss/lib/freebl/mpi/mulsqr.c',
]

SOURCES += [
    '../msgpack/src/objectc.c',
    '../msgpack/src/unpack.c',
    '../msgpack/src/version.c',
    '../msgpack/src/vrefbuffer.c',
    '../msgpack/src/zone.c',

    'prio/client.c',
    'prio/config.c',
    'prio/encrypt.c',
    'prio/mparray.c',
    'prio/poly.c',
    'prio/prg.c',
    'prio/rand.c',
    'prio/serial.c',
    'prio/server.c',
    'prio/share.c',
]

FINAL_LIBRARY = 'xul'

@rhelmer
Copy link
Contributor Author

rhelmer commented Aug 8, 2018

Thanks! About to give that a shot.

@rhelmer
Copy link
Contributor Author

rhelmer commented Aug 8, 2018

@rhelmer
Copy link
Contributor Author

rhelmer commented Aug 8, 2018

Better but the multiple definition of main crept back in... I can handle that though.

@rhelmer rhelmer mentioned this issue Aug 9, 2018
2 tasks
@rhelmer
Copy link
Contributor Author

rhelmer commented Aug 9, 2018

Hrm well the tryserver is shut down for a bit, will update here when I can :)

@rhelmer
Copy link
Contributor Author

rhelmer commented Aug 9, 2018

@rhelmer
Copy link
Contributor Author

rhelmer commented Aug 9, 2018

After following this through the build system, I think NoVisibilityFlags() suppresses the -fvisibility=hidden flag: https://gcc.gnu.org/wiki/Visibility

I'll ask for build peer review in the bug though.

@rhelmer
Copy link
Contributor Author

rhelmer commented Aug 9, 2018

In any case, we're getting good Linux builds now! https://treeherder.mozilla.org/#/jobs?repo=try&revision=5a61c6839dcef4e40219a497e42584676a786708

@henrycg
Copy link
Collaborator

henrycg commented Aug 9, 2018

Sweet! Adding the msgpack files to the SOURCES array in third_party/prio/moz.build seems like a bit of a hack, though I couldn't find any documentation that explained a better way... maybe whoever reviews the patch will know what the right way to do this is.

@rhelmer
Copy link
Contributor Author

rhelmer commented Aug 9, 2018

This is working \o/ https://treeherder.mozilla.org/#/jobs?repo=try&revision=5da61e100e5d5e021b0893ba44452624f3c6ef98

All related PRs are merged and patches have been rebased into my Firefox+libprio integration patch as necessary, so I think we're done here.

Thanks all!

@rhelmer rhelmer closed this as completed Aug 9, 2018
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants