I am just getting started with go and caddy.
I am following the doc here: Extending Caddy — Caddy Documentation
to extend caddy
I created rons.go directly from what is shown on the quick-start:
package mymodule
import "github.com/caddyserver/caddy/v2"
func init() {
caddy.RegisterModule(Gizmo{})
}
// Gizmo is an example; put your own type here.
type Gizmo struct {
}
// CaddyModule returns the Caddy module information.
func (Gizmo) CaddyModule() caddy.ModuleInfo {
return caddy.ModuleInfo{
ID: "foo.gizmo",
New: func() caddy.Module { return new(Gizmo) },
}
}
I completely uninstalled go, caddy, xcaddy and reinstalled - no difference.
I modified the sample module from the webpage to change gizmo to gizmo1, and mymodule to ronsmodule - no difference.
I attempted to build caddy from source with “go buyile”, but it wants gcc, which (on windows) wants cygwin or mingW, so I installed the binary - it runs
.
xcaddy appears to want modules that aren’t here or not where it expects to find them.
Hi Matt,
I haven’t made any changes to the sourcve. I tried go build to build caddy, but it barks about wanting gcc executables, and gcc wants cygwin or mingw, so I didn’t go any further down that path.
I honestly don’t know then. You’ll probably have to fiddle with it.
It’s not an xcaddy problem – xcaddy doesn’t yield those errors, those are from the Go compiler – so I would navigate into the caddy source directory and run go build and see where it fails, then investigate in those files and see why.
Hi Matt, I installed MingW & GCC, following the doc at: Build from source — Caddy Documentation
now the “go build” starts, but fails with invalid parms for ld.exe.
C:\caddy\cmd\caddy>go build
# github.com/caddyserver/caddy/v2/cmd/caddy
c:\go\pkg\tool\windows_amd64\link.exe: running gcc failed: exit status 1
c:/mingw/bin/../lib64/gcc/x86_64-w64-mingw32/4.8.3/../../../../x86_64-w64-mingw32/bin/ld.exe: unrecognized option '--high-entropy-va'
c:/mingw/bin/../lib64/gcc/x86_64-w64-mingw32/4.8.3/../../../../x86_64-w64-mingw32/bin/ld.exe: use the --help option for usage information
collect2.exe: error: ld returned 1 exit status
running help for ld, there is no parm that includes “high” or “entropy”.
Any clues?
Also, looking at caddy.go, it does reference "adminConsole, Logging, etc as shown in the error messages from xcaddy. How are these supposed to be resolved?
I have no idea… honestly I’ve never seen these errors before nor do I use Windows or have experience there. Your best bet would be to ask the Go community:
I’ve only ever had problems using mingw (at least directly).
I still recommend using scoop.
scoop install go gcc
See the package definitions for those to see what it does:
xcaddy works just fine for me on windows that way.
AFAIK I didn’t even need gcc myself for things to compile. Caddy is a pure-go project, so you shouldn’t need it I think. You might need to set CGO_ENABLED=0 in your system environment for it to stop trying to use gcc. But I don’t think I needed to do that
Thanks! I installed scoop, and started the “scoop install go gcc” failed at third entry.
I checked the repo, expat has been updated to 2.2.10, but the install doesn’t appear to know it.
Do I download a local copy of the json and fix it on my PC?
PS C:\Users\Ron> scoop install go gcc
Installing '7zip' (19.00) [64bit]
7z1900-x64.msi (1.7 MB) [=====================================================================================] 100%
Checking hash of 7z1900-x64.msi ... ok.
Extracting 7z1900-x64.msi ... done.
Linking ~\scoop\apps\7zip\current => ~\scoop\apps\7zip\19.00
Creating shim for '7z'.
Creating shortcut for 7-Zip (7zFM.exe)
'7zip' (19.00) was installed successfully!
Installing 'gcc' (9.3.0-2) [64bit]
mingw-w64-x86_64-binutils-2.34-1-any.pkg.tar.xz (13.9 MB) [===================================================] 100%
Checking hash of mingw-w64-x86_64-binutils-2.34-1-any.pkg.tar.xz ... ok.
mingw-w64-x86_64-crt-git-8.0.0.5815.9517d302-1-any.pkg.tar.xz (3.1 MB) [======================================] 100%
Checking hash of mingw-w64-x86_64-crt-git-8.0.0.5815.9517d302-1-any.pkg.tar.xz ... ok.
The remote server returned an error: (404) Not Found.
URL http://repo.msys2.org/mingw/x86_64/mingw-w64-x86_64-expat-2.2.9-1-any.pkg.tar.xz is not valid
PS C:\Users\Ron>
Nevermind! I’m abandoning Caddy. I never expected to have to rebuild the whole thing to extend it, but ok.
I shouldn’t have to debug the freakin’ build routines, before I even start MY work! Caddy obviously isn’t ready for prime time - good luck with it.
It’s not our fault that you’re having trouble using your computer. The issues you’re having have nothing to do with Caddy, and everything to do with the way you configured your environment.
If it makes you feel good to blame me that gcc won’t build your code following 2 different methods of yours, then go ahead. Telling the user to “fiddle with it” doesn’t help. Gcc works, golang works, mingw works, Still can’t build caddy. This was an experiment to try the new kid on the block.