Bug 226400 - science/py-tensorflow: please update to 1.6
Summary: science/py-tensorflow: please update to 1.6
Status: Open
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: --- Affects Only Me
Assignee: Yuri Victorovich
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2018-03-06 19:49 UTC by Dmitri Goutnik
Modified: 2019-07-18 18:23 UTC (History)
9 users (show)

See Also:
dg: maintainer-feedback?


Attachments
Partial Poudriere log. (13.85 KB, text/plain)
2018-06-01 00:01 UTC, Hyun Hwang
no flags Details
INCOMPLETE_science_py-tensorflow.shar (11.49 KB, text/plain)
2018-06-04 19:01 UTC, Hyun Hwang
no flags Details
google-cloud-cpp.shar (25.00 KB, text/plain)
2019-07-14 08:21 UTC, Yuri Victorovich
no flags Details
Fix installing Files into bin dir (649 bytes, text/plain)
2019-07-17 17:24 UTC, Anthony
no flags Details
google-cloud-cpp.shar (8.04 KB, text/plain)
2019-07-17 19:33 UTC, Yuri Victorovich
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Dmitri Goutnik 2018-03-06 19:49:24 UTC
Current port version is 1.2.1 and marked as BROKEN. Any chance to unbreak it and update to 1.6 [1]?

[1] https://github.com/tensorflow/tensorflow/releases
Comment 1 Martin Wilke freebsd_committer 2018-05-19 19:54:47 UTC
Hi,

Would u mind to prepare a patch ?
Comment 2 Hyun Hwang 2018-05-21 23:21:20 UTC
Hi,

I will try to get this port cranked up to 1.7.1.
Comment 3 Hyun Hwang 2018-05-23 21:11:46 UTC
There looks like a Bazel bug [0][1] that prevents building whatever version of TensorFlow. So far, I have tried py{27,34,35,36}-TensorFlow-{1.7.0,1.7.1,1.8.0} with Bazel-0.13.0 and all failed.

I am going to test again with Bazel-0.12.0.

[0]: https://github.com/tensorflow/tensorflow/issues/19015
[1]: https://github.com/bazelbuild/bazel/issues/5177
Comment 4 Hyun Hwang 2018-05-24 18:04:59 UTC
Tried Bazel-0.12.0 + TensorFlow-1.8.0.

I am stuck on a problem regarding gRPC [0]; cannot proceed anymore.
It looks like Bazel fetches the gRPC code on-the-fly, so there is no other way to perform the patch on our side (Makefile).

Also, the combination of Bazel-0.12.0 and any version of TensorFlow less than 1.8.0 has another problem of detecting CPU architecture wrong [1][2] (trying to compile as 'armv7-a') so right now the only option left is waiting for gRPC fix.


[0]: https://github.com/grpc/grpc/issues/15010
[1]: https://github.com/bazelbuild/bazel/issues/4794#issuecomment-376078059
[2]: https://github.com/tensorflow/tensorflow/issues/18564#issuecomment-385463643
Comment 5 Kai Knoblich freebsd_committer 2018-05-24 19:30:03 UTC
(In reply to Hyun Hwang from comment #4)

Hello Hyun,

maybe the patches from the port devel/grpc might help you in that case. Here are my notes when I was working on that port for a little while:

- patch grpc -> src/core/lib/grp/arena.cc (use patch from grpc port)

- patch tensorflow/tools/build_info/gen_build_info.py (shebang fix)

- patch tensorflow/tools/git/gen_git_source.py (shebang fix)

- patch tensorflow/core/platform/posix/posix_file_system.cc (replace APPLE with FREEBSD)

- patch line #350 in tensorflow/core/platform/env.cc (same as in arena.cc)

My approach was at that time:

- add the required files that are downloaded on the fly to the makefile (will be fun, because a lot of entries will be needed)
- patch both ${WRKSRC}/WORKSPACE + ${WRKSRC}/tensorflow/workspace.bzl to give bazel the hint to search locally for the required files

Maybe those notes will help you further to bring py-tensorflow again in a good shape. If you're interested, I can also attach my non-finished Makefile.
Comment 6 Hyun Hwang 2018-05-25 00:39:18 UTC
(In reply to Kai from comment #5)

Hi Kai,

Thank you for the lead! I will continue tomorrow. :)
Comment 7 Hyun Hwang 2018-05-31 23:59:12 UTC
Another linking nightmare encountered and I don't know where to look at to fix this; looks like Python is trying to find `backtrace(3)` function inside TensorFlow's shared object, not from libexecinfo. Error output to be uploaded soon.

I've been continuously fixing link errors when they were encountered; the most frequent one was `-ldl not found`, which in Linux exists as a separate library while FreeBSD has it in libc. I have tracked all the occurrence of `-ldl` in linker options to clear this issue out.
Next one I encountered is `unknown symbol backtrace_symbols_fd`, which in Linux does not require special linker flag while in FreeBSD does. I managed to fix this by adding link option `-lexecinfo` to ALL Python-related build rules.
Comment 8 Hyun Hwang 2018-06-01 00:01:10 UTC
Created attachment 193882 [details]
Partial Poudriere log.
Comment 9 Hyun Hwang 2018-06-04 19:01:03 UTC
Created attachment 194004 [details]
INCOMPLETE_science_py-tensorflow.shar

Hi,

I'm giving this upgrading process up, as I have no more time to pour in. I originally aimed to use TF on FreeBSD for my thesis, but there are too many obstacles for me to continue; I'm switching to Linux (alas!) to meet the deadline.

Attached is the shell archive of what I've been doing. The Makefile is incomplete in the sense of do-install target because the do-build fails in the middle of the process. The pkg-plist file does not exist because I was building this port from scratch.

I send my sincere apology to the original reporter. Hopefully, someone more skillful than me takes this over. Or maybe after I graduate and have more free time, then I might revisit this issue.
Comment 10 Yuri Victorovich freebsd_committer 2018-06-22 09:02:05 UTC
Maintainer has been reset.
Comment 11 Yuri Victorovich freebsd_committer 2018-06-22 09:32:00 UTC
Martin,

I can take it if you don't mind.

Yuri
Comment 12 Rene Ladan freebsd_committer 2018-08-02 12:55:11 UTC
Any updates on this PR? Should we just remove the port?
Comment 13 Yuri Victorovich freebsd_committer 2018-08-02 16:26:47 UTC
Tensorflow is too important to not have in the ports tree.
It needs to be fixed somehow.
Comment 14 Rene Ladan freebsd_committer 2018-08-03 13:25:01 UTC
Note that Tensorflow 1.9 is out and 1.10 is around the corner.

> Tensorflow is too important to not have in the ports tree.
Well, viewed from the ports tree it is just a broken leaf port. It is this PR that still keeps it in.
Comment 15 Yuri Victorovich freebsd_committer 2018-08-03 16:14:52 UTC
(In reply to Rene Ladan from comment #14)

I will make an attempt to fix it.
Comment 16 Yuri Victorovich freebsd_committer 2018-08-03 19:46:31 UTC
Pending upstream response for now: https://github.com/tensorflow/tensorflow/issues/21366
Comment 17 Alexey Dokuchaev freebsd_committer 2019-03-13 08:22:07 UTC
Ping?
Comment 18 Yuri Victorovich freebsd_committer 2019-03-31 09:14:04 UTC
It was removed on 2018-08-08.
Hopefully, it will be re-added some day, when it will become buildable.

Yuri
Comment 19 ed austin 2019-04-25 16:00:53 UTC
This needs to be a priority, as it is a pretty critical piece of software for many. Unfortunately, although I have built many custom versions (Ubuntu) the state of bazel on FreeBSD has left it impossible for me (with limited skills) to do a build.

I will try to checkout 1.13.1 again, but hope is needed ))
Comment 20 Yuri Victorovich freebsd_committer 2019-04-25 16:57:56 UTC
(In reply to ed austin from comment #19)

I have plans to look at this again.
I have some leads that might help, just didn't have time to look again.

Yuri
Comment 21 Yuri Victorovich freebsd_committer 2019-04-25 16:58:21 UTC
reopen
Comment 22 Anthony 2019-07-07 08:57:21 UTC
Have you got any further with this port. I have started work on creating a port, and while everything builds successfully, it is the final linking that fails.

libtensorflow_framework.so.1: Undefined symbol "_ZN3Aws11Environment6GetEnvEPKc"

I'm going to try to address the final linking error today:

Here is my current work on the port, it's currently 1.14.0. One the build is successful, I have other things to address such as tidying up some patches and removing others in place of sed. 

Will also try and tackle killing the downloading and building of remote sources.

https://github.com/Amzo/py-tensorflow
Comment 23 Yuri Victorovich freebsd_committer 2019-07-07 09:36:33 UTC
(In reply to Anthony from comment #22)

Hi Anthony,

I didn't have much time to work on tensorflow die to other things.
If you'll be able to make it build I'll be more than happy to test and commit it.

Thank you for working on the tensorflow port!
Yuri
Comment 24 Anthony 2019-07-07 21:23:18 UTC
It currently builds fine now as I fixed the initial linking errors. However it fails on tensorflow lite while linking. I think this can safely be removed as tensorflow lite is for Android and IOS platforms. Some tinkering with the build files should ignore this being built. I'm guessing when it can't detect the current platform as MacOS, Linux or Windows it's defaulting to building this. So I will address this tomorrow.
Comment 25 Anthony 2019-07-07 21:23:30 UTC
It currently builds fine now as I fixed the initial linking errors. However it fails on tensorflow lite while linking. I think this can safely be removed as tensorflow lite is for Android and IOS platforms. Some tinkering with the build files should ignore this being built. I'm guessing when it can't detect the current platform as MacOS, Linux or Windows it's defaulting to building this. So I will address this tomorrow.
Comment 26 Yuri Victorovich freebsd_committer 2019-07-07 21:32:15 UTC
(In reply to Anthony from comment #25)

Sounds great!

Please drop a line when you are done.

Yuri
Comment 27 Anthony 2019-07-09 12:49:59 UTC
It now builds correctly for me using the Makefile and my patches. Still need to fix the installation and update the pkg-plist. I just need to push my last patch to git and then it should be good for testing.
Comment 28 Anthony 2019-07-09 18:54:54 UTC
It should be ready for testing. I had to rename the git repository I was using as I had to create additional packages as they weren't available in the ports but the latest tensorflow depends on them. absl and Gast both of which are available now and can be tested from here: https://github.com/Amzo/FreeBSD-Ports

I'm not too familiar with creating ports so the Makefiles will need reviewed to ensure I've followed correct porting guidelines and naming.

I will run a clean build in poudiere to ensure I haven't missed any dependencies which I may have already had installed on my system.
Comment 29 commit-hook freebsd_committer 2019-07-10 00:15:16 UTC
A commit references this bug:

Author: yuri
Date: Wed Jul 10 00:14:42 UTC 2019
New revision: 506324
URL: https://svnweb.freebsd.org/changeset/ports/506324

Log:
  New port: devel/py-absl: Abseil Python Common Libraries

  PR:		226400
  Submitted by:	Anthony <amzo1337@gmail.com>

Changes:
  head/devel/Makefile
  head/devel/py-absl/
  head/devel/py-absl/Makefile
  head/devel/py-absl/distinfo
  head/devel/py-absl/pkg-descr
Comment 30 commit-hook freebsd_committer 2019-07-10 00:30:32 UTC
A commit references this bug:

Author: yuri
Date: Wed Jul 10 00:29:33 UTC 2019
New revision: 506325
URL: https://svnweb.freebsd.org/changeset/ports/506325

Log:
  New port: devel/py-gast: AST that abstracts the underlying Python version

  PR:		226400
  Submitted by:	Anthony <amzo1337@gmail.com>

Changes:
  head/devel/Makefile
  head/devel/py-gast/
  head/devel/py-gast/Makefile
  head/devel/py-gast/distinfo
  head/devel/py-gast/pkg-descr
Comment 31 Yuri Victorovich freebsd_committer 2019-07-10 00:41:55 UTC
One problem that I noticed is that the build asks the interactive question:

> Extracting Bazel installation...
> WARNING: --batch mode is deprecated. Please instead explicitly shut down your Bazel server using the command "bazel shutdown".
> You have bazel 0.27.0 installed.
> Please specify optimization flags to use during compilation when bazel option "--config=opt" is specified [Default is -march=native -Wno-sign-compare]: 

This might be a bazel problem, not sure.

The second problem is this:
>    Fetching @grpc; fetching 7s
>    Fetching @farmhash_archive; Restarting.

The build should not fetch anything, this is not allowed. All needed files should appear in BUILD_DEPENDS and the build should use pre-downloaded versions.

Bazel's BUILD files should be patched and all https:// URLs should be replaced with file:// URLS pointing to /usr/ports/distfiles or something like that.
This is how bazel projects are difficult.

Yuri
Comment 32 Anthony 2019-07-10 06:51:45 UTC
I already have plans to remove the downloading of the files via bazel, just wanted to make sure I had a buildable tensorflow first to avoid any problems and make troubleshooting more difficult.

As for the optimization flags, I was going to add a port option to build native or for arch. Since tensorflow uses CPU optimizations this would be best for users building ports, but keep the ability to build for all amd64 machines so that it can be packaged still.

As for bazel downloading files, I have a few solutions to this. The first is to create a tar file of what it downloads and have the ports Makefile download that from my git then modify the bazel files. This would be the easiest and quickest solution.

Or could add the MASTERSITES to Makefiles but this would bloat too much.
Comment 33 Yuri Victorovich freebsd_committer 2019-07-10 06:57:14 UTC
(In reply to Anthony from comment #32)

> As for bazel downloading files, I have a few solutions to this. The first is to create a tar file of what it downloads and have the ports Makefile download that from my git then modify the bazel files. This would be the easiest and quickest solution.


No, the simpler solution is for these files to be added to MASTER_SITES/DISTFILES, and bazel's BUILD files to be patched accordingly.
Comment 34 Anthony 2019-07-10 07:09:41 UTC
(In reply to Yuri Victorovich from comment #33)

Someone else attempted the port on Phabricator but people were unsure about going that route as the MASTER_SITES list would be huge for it. I can do this if this is how it should be done. If I kill the pulling and building of packages we already have in the ports such curl, jpeg, nasm and others. The MASTER_SITES could be reduced substantially and then I would only need to add google specific ones. I'll tackle this today and fix the pulling and downloading of the files.
Comment 35 Yuri Victorovich freebsd_committer 2019-07-10 07:25:31 UTC
(In reply to Anthony from comment #34)

It doesn't matter that it will be huge. Anything that doesn't require a special file preparation in a special step is better.
Comment 36 Anthony 2019-07-13 22:15:42 UTC
I've updated the port on my github so now it uses system libraries and what external sources it needs to download are now downloaded via MASTERSITES.

Since there was a few I created a MASTER_SITES file which the Makefile includes. Not sure if this is best practice or not. I also set the DIST_SUBDIR to ${PORTNAME}, as we need to copy these files to the WRKDIR for bazel and it needs the exact match to what is included in the workspace.bzl. Is there a way to rename these downloaded files?

Also made it respect LOCALBASE, and patch BUILD files to find correct system binaries. E.G swig3.0.

I needed to create a couple of new ports for the build to work. devel/double-conversion needed upgraded and I added: devel/crc32c, devel/nysnc, devel/google-cloud-cpp, devel/py-gast, devel/py-absl and devel/google-mock.

Ran a test build in poudriere and all went well. Just need to add an option for cpu optimization and maybe create a tensorboard package. Since I'm still waiting to be accepted on reviews.freebsd.org. I'll just keep it posted here.
Comment 37 commit-hook freebsd_committer 2019-07-14 05:23:16 UTC
A commit references this bug:

Author: yuri
Date: Sun Jul 14 05:22:46 UTC 2019
New revision: 506603
URL: https://svnweb.freebsd.org/changeset/ports/506603

Log:
  New port: devel/nsync: C library that exports various synchronization primitives like mutexes

  PR:		226400
  Submitted by:	Anthony <amzo1337@gmail.com>

Changes:
  head/devel/Makefile
  head/devel/nsync/
  head/devel/nsync/Makefile
  head/devel/nsync/distinfo
  head/devel/nsync/pkg-descr
  head/devel/nsync/pkg-plist
Comment 38 commit-hook freebsd_committer 2019-07-14 05:32:23 UTC
A commit references this bug:

Author: yuri
Date: Sun Jul 14 05:32:17 UTC 2019
New revision: 506605
URL: https://svnweb.freebsd.org/changeset/ports/506605

Log:
  New port: devel/crc32c: CRC32C implementation supporting CPU-specific acceleration

  PR:		226400
  Submitted by:	Anthony <amzo1337@gmail.com>

Changes:
  head/devel/Makefile
  head/devel/crc32c/
  head/devel/crc32c/Makefile
  head/devel/crc32c/distinfo
  head/devel/crc32c/pkg-descr
  head/devel/crc32c/pkg-plist
Comment 39 Yuri Victorovich freebsd_committer 2019-07-14 06:40:54 UTC
I'm working on devel/google-cloud-cpp because the latest version fails to build.
This may take a while.
Comment 40 Anthony 2019-07-14 07:12:35 UTC
What issues are there with google-cloud-cpp. The version 0.11.0 builds consistently at me, but I was going to spend some more time on tidying it up.
Comment 41 Yuri Victorovich freebsd_committer 2019-07-14 07:17:11 UTC
(In reply to Anthony from comment #40)

No, please delay until I commit it.
Comment 42 Yuri Victorovich freebsd_committer 2019-07-14 08:21:46 UTC
Created attachment 205760 [details]
google-cloud-cpp.shar

The latest version of google-cloud-cpp installs files into the same directory where it builds from: https://github.com/googleapis/google-cloud-cpp/issues/2875

Attaching the latest revision of devel/google-cloud-cpp

This is a show-stopper, and needs to be resolved in order to proceed. Waiting for the upstream to resolve this.
Comment 43 Anthony 2019-07-14 08:59:13 UTC
.build is where the files are downloaded to prevent the build system automatically downloading them. googleapis and nlohmann_json. Could move them to WRKSRC/.build. The original build automatically downloaded these source files. If I remember correctly that is where it placed those files.
Comment 44 Yuri Victorovich freebsd_committer 2019-07-14 19:18:59 UTC
(In reply to Anthony from comment #43)

This issue has nothing to do with .build. They install files into the build directory. This needs to be fixed. Google probably works Mon-Fri, so we need to wait for them to fix this.
Comment 45 Anthony 2019-07-14 20:16:36 UTC
Oh right. Well I will continue to polish the tensorflow build as in poudriere in a clean build it isn't pulling in some dependencies. I probably messed up the depend lines as it's my first time making a port. So I will fix those.
Comment 46 Anthony 2019-07-17 11:35:51 UTC
Based on the information on the bug report I've patched the cmake files so the problem should be fixed. Instead of setting INSTALL_DIR to CMAKE_BIN_DIR where it is executed, install dir is now set to ${LOCALBASE} which fixes the issue until the build system is finished being reworked upstream. I also updated the pkg-descr. 

Here is the results of make makeplist after the patch.

http://sprunge.us/2JJPDk
Comment 47 Yuri Victorovich freebsd_committer 2019-07-17 17:18:44 UTC
(In reply to Anthony from comment #46)

Are you talking about https://github.com/Amzo/FreeBSD-Ports/blob/master/devel/google-cloud-cpp/Makefile ?

It doesn't mention INSTALL_DIR or CMAKE_BIN_DIR.
Comment 48 Anthony 2019-07-17 17:24:39 UTC
Created attachment 205845 [details]
Fix installing Files into bin dir

Fixes installing the files into the build dir and installs them to the correct location.
Comment 49 Yuri Victorovich freebsd_committer 2019-07-17 17:41:12 UTC
(In reply to Anthony from comment #48)

Hm, with the attached patch 'make makeplist' still shows wrong files:
@dir /usr/ports/devel/google-cloud-cpp/work/.build/external
@dir /usr/ports/devel/google-cloud-cpp/work/.build
@dir /usr/ports/devel/google-cloud-cpp/work
@dir /usr/ports/devel/google-cloud-cpp
@dir /usr/ports/devel
@dir /usr/ports

Yuri
Comment 50 Anthony 2019-07-17 17:46:52 UTC
Is that with the modified Makefile from my github? I don't have the issue of installing wrong files anymore.
Comment 51 Anthony 2019-07-17 17:48:01 UTC
Sorry, I had forgot to push changes to my git, had only commited them.
Comment 52 Yuri Victorovich freebsd_committer 2019-07-17 19:33:18 UTC
Created attachment 205849 [details]
google-cloud-cpp.shar

I also made some changes against your port because CMAKE_OFF/CMAKE_ON wasn't used, and because the version wasn't right due to their mislabeling.

This version has the issue in question.

I am reluctant to throw in more time into making a workaround, when they admitted that the problem is on their end, and they are expected to fix it any time now. We shouldn't be "fixing" the port when there is nothing wrong with it.


Yuri
Comment 53 Anthony 2019-07-17 19:43:04 UTC
I created the work around as they said it was marked as low priority and would be fixed when the build system got reworked which they had no ETA for and could be awhile.

The fix is waiting on this issue. 

https://github.com/googleapis/google-cloud-cpp/issues/2802

I don't mind waiting, I just thought a work around would suffice until it is fixed upstream.
Comment 54 Yuri Victorovich freebsd_committer 2019-07-17 19:45:08 UTC
(In reply to Anthony from comment #53)

Ok.

So what exactly is the workaround here? The above patch alone doesn't fix it. What part of Makefile is also related to this workaround?

Yuri
Comment 55 Anthony 2019-07-17 19:50:17 UTC
I added a post-patch: to the Makefile which goes with the patch I added: 

post-patch:
		@${REINPLACE_CMD} "s#%%LOCALBASE%%#${LOCALBASE}#" \
			${WRKSRC}/cmake/external/googleapis.cmake


I feel like i'm cluttering this bug report up.
Comment 56 commit-hook freebsd_committer 2019-07-17 20:37:32 UTC
A commit references this bug:

Author: yuri
Date: Wed Jul 17 20:36:59 UTC 2019
New revision: 506825
URL: https://svnweb.freebsd.org/changeset/ports/506825

Log:
  New port: devel/google-cloud-cpp: C++ Idiomatic Clients for Google Cloud Platform services

  PR:		226400
  Submitted by:	Anthony <amzo1337@gmail.com>

Changes:
  head/devel/Makefile
  head/devel/google-cloud-cpp/
  head/devel/google-cloud-cpp/Makefile
  head/devel/google-cloud-cpp/distinfo
  head/devel/google-cloud-cpp/files/
  head/devel/google-cloud-cpp/files/patch-cmake_DownloadNlohmannJson.cmake
  head/devel/google-cloud-cpp/files/patch-cmake_GoogleCloudCppCommon.cmake
  head/devel/google-cloud-cpp/files/patch-cmake_external_googleapis.cmake
  head/devel/google-cloud-cpp/files/patch-google_cloud_storage_CMakeLists.txt
  head/devel/google-cloud-cpp/pkg-descr
  head/devel/google-cloud-cpp/pkg-plist
Comment 57 Anthony 2019-07-17 21:25:09 UTC
The pkg-descr file is wrong with that google-cloud-cpp submission. It's not the one from my github.com.

https://github.com/Amzo/FreeBSD-Ports/blob/master/devel/google-cloud-cpp/pkg-descr

"Google cloud C++ librariesC++ libraries for use with the Google
Cloud platform. Google Cloud Platform provides infrastructure as a 
service, platform as a service, and serverless computing environments.

WWW: https://github.com/googleapis/google-cloud-cpp"
Comment 58 Yuri Victorovich freebsd_committer 2019-07-17 21:26:42 UTC
(In reply to Anthony from comment #57)

Sorry for this mishap, I will correct it.
Comment 59 commit-hook freebsd_committer 2019-07-17 22:34:44 UTC
A commit references this bug:

Author: yuri
Date: Wed Jul 17 22:33:57 UTC 2019
New revision: 506826
URL: https://svnweb.freebsd.org/changeset/ports/506826

Log:
  devel/google-cloud-cpp: Fix the wrong pkg-descr file that was committed

  PR:		226400
  Reported by:	Anthony <amzo1337@gmail.com>

Changes:
  head/devel/google-cloud-cpp/pkg-descr
Comment 60 Yuri Victorovich freebsd_committer 2019-07-18 04:32:19 UTC
Tensorflow build fails for me: https://people.freebsd.org/~yuri/py36-tensorflow-1.14.0.log
Comment 61 Anthony 2019-07-18 06:20:30 UTC
Yeah, this is the issue i'm trying to fix. If I build tensorflow on my machine it builds fine. If I start a jail and build it it builds fine, but if I build it with poudriere it fails with that error.

Those files are in /usr/local/include/google/ and I need to figure out what is stopping it from finding those files at times.

Did you build it in a jail also or with poudriere. I'm trying to track down what is causing it, Once it does actually find the file sin ${LOCALBASE}/include the rest of the build works but I can only reproduce this sometimes and sometimes I can't. I've ruled out JOBS being the issues. As It works sometimes with --jobs said to 4 and sometimes it doesn't.

Was that the latest port from github you tried as I made a few quite changes since I first posted it to dependencies and configurations as well as a couple of more patches.
Comment 62 Yuri Victorovich freebsd_committer 2019-07-18 07:55:45 UTC
(In reply to Anthony from comment #61)

I tried the latest revision 9d91d3c from https://github.com/Amzo/FreeBSD-Tensorflow

It failed for me both in the poudriere jail, and on my desktop system.


Yuri
Comment 63 Anthony 2019-07-18 08:17:07 UTC
I'm goind to rework it because I did another test in poudriere and either TF_SYSTEM_LIBS isn't being passed, or I'm missing a dependency for the port that I have installed on my system but haven't included in the Makefile which would explain why it isn't building in poudriere for me but is on my host system.

I'll look into it today. Might remove SETENV and add the variables for Configure into CONFIGURE_ARGS and set USE_CONFIGURE= yes.

Once I find the culprit, fix and push it. I'll let you know.
Comment 64 Anthony 2019-07-18 12:02:03 UTC
I think I have found the culprit. When using TF_SYSTEM_LIBS it should symlink ${LOCALBASE}/include/google files to the build dir and include them but it is messing this up.

The genrule to create these files is not being executed first but after.

If you continue the build without cleaning it will continue. Even with jobs set to 1 it still doesn't create these files first.

Need to find out why they aren't being generated first, before executing the protoc commands. It's possible there could be a check that checks for is_linux. so I'll dig into it and find a solution.
Comment 65 Anthony 2019-07-18 18:21:11 UTC
I beleive I have fixed it however this now requires jobs to be set to 1 and avoid parrallel processing. I wonder if the issue is because we're using normal make. I should maybe try setting USES = gmake and see if that also fixes it as I don't want to stop parallel building as it takes significantly longer to build.

However it builds with out this now with a couple of more patches. I'll run the test build on host and in poudriere before pushing.
Comment 66 Yuri Victorovich freebsd_committer 2019-07-18 18:23:03 UTC
(In reply to Anthony from comment #65)

Thanks for working on this!

Yuri