ggn Posted June 23, 2023 Share Posted June 23, 2023 Oh my goodness, I was concerned! And did something about it, thanks! 2 Quote Link to comment Share on other sites More sharing options...
+cubanismo Posted August 24, 2023 Share Posted August 24, 2023 Just a heads up, the git repos for rmac and rln seem to have been down for hours, and the gitlab mirrors: https://gitlab.com/ggnkua/rmac-mirror https://gitlab.com/ggnkua/rln-mirror Seem woefully out of date. Pointed out by a user trying to build my SDK, which fetches the rmac and rln repos as git submodules. 1 Quote Link to comment Share on other sites More sharing options...
ggn Posted August 25, 2023 Share Posted August 25, 2023 Hi, 16 hours ago, cubanismo said: Just a heads up, the git repos for rmac and rln seem to have been down for hours @Shamus pinged, I'm sure we'll have everything back to normal in a bit. 16 hours ago, cubanismo said: and the gitlab mirrors: https://gitlab.com/ggnkua/rmac-mirror https://gitlab.com/ggnkua/rln-mirror Seem woefully out of date. Pointed out by a user trying to build my SDK, which fetches the rmac and rln repos as git submodules. Aw c'mon, it's only 2 releases behind ;). But thanks for letting me know, gitlab was kind enough to upgrade its UI and wipe all the auto mirroring I've set up for both repositories. I've re-added the mirror hooks, but we'll have to wait till the server is up again. In the meantime, if it's not a huge convenience for your lovely user, the rmac/rln homepage has statically linked binaries for Windows/Mac(x86 and M1)/Linux(x64). I hope that's a valid alternative until we get things back to normal. And apologies for the downtime! 2 1 Quote Link to comment Share on other sites More sharing options...
+BitJag Posted August 25, 2023 Share Posted August 25, 2023 Thanks for taking the time to work and maintain this @ggn and @Shamus and others. I also rely on this for the scripts I use in my Linux environment. It's a great feeling to know that I'm using the latest rln/rmac when I get a chance to work on Jaguar stuff. 3 Quote Link to comment Share on other sites More sharing options...
+cubanismo Posted August 25, 2023 Share Posted August 25, 2023 Agreed, thanks for all the work, it's much appreciated. Just bringing issues to your attention in case you guys weren't aware of them. For advanced users like myself, yes, I know how to edit scripts and do a little git heroics to drop in the Linux binaries when setting up the SDK environment, but for average users, the source repositories being down breaks things right at the initial "git clone" step of SDK setup, because rmac and rln are included as submodules that get recursively cloned if you're following the instructions in the README.md. 3 Quote Link to comment Share on other sites More sharing options...
ggn Posted August 27, 2023 Share Posted August 27, 2023 (edited) A small update on this: So far I haven't been able to get in touch with @Shamus so I can't do much on that front. At least I have pushed what I believe are the latest commits for both rmac and rln on the gitlab mirrors. So if anyone wants to build from source, the gitlab repos are the "official" ones for now. (Of course there are also the prebuilt binaries on the official website) That is all for now. [Edit] I have also set up some contigency repos at the website, so you can "git clone http://rmac.is-slick.com/git/rmac" and "git clone http://rmac.is-slick.com/git/rln" respectively. Edited August 27, 2023 by ggn 3 1 Quote Link to comment Share on other sites More sharing options...
Shamus Posted August 29, 2023 Share Posted August 29, 2023 gitlab will *never* be the official repos; at least as long as I'm still alive. Seems that my ISP is fucking around with my IP (which has been stable for the last umpteen years or so). So I'll be keeping a closer eye on it until I can get figure out what my ISP is doing and keeping the DNS updated. BTW, the DNS has been updated, and the repos should be reachable now. 1 1 Quote Link to comment Share on other sites More sharing options...
ggn Posted March 8 Share Posted March 8 Small update, since there have been outages at the official repo addresses, I have gone and set up a mirror here: http://tiddly.mooo.com:5000/explore/repos, so hopefully there will be some redundancy! (also announced in the official page) 4 Quote Link to comment Share on other sites More sharing options...
+BitJag Posted March 9 Share Posted March 9 1 hour ago, ggn said: Small update, since there have been outages at the official repo addresses, I have gone and set up a mirror here: http://tiddly.mooo.com:5000/explore/repos, so hopefully there will be some redundancy! (also announced in the official page) Thank you @ggn for taking the time to make sure this repository maintained and is available! It means allot to me and I'm sure to the rest of us that rely on these tools. 2 Quote Link to comment Share on other sites More sharing options...
sjc Posted June 20 Share Posted June 20 Hi. Apologies if this is the wrong place to ask. Is it possible to get rln to output an object file which it can then take as input later in the build process? If so, what's the command line incantation please? None of the switches listed through -h seem relevant and trying multiple combinations have not produced anything which the later rln has liked (or I keep meeting the "TO DO: Relocatable linking" message). Using v1.7.4. For my particular use case the archive would be built from .o files containing data only (no code) and incbin'd (-ii) data. This thread mentions rln supporting .a archive files, but it's unclear whether that's as producer or consumer. Thanks. Quote Link to comment Share on other sites More sharing options...
42bs Posted June 20 Share Posted June 20 Hmm, and archive is something different from an intermediate link. Files in an archive are the same as before and intermediate link will combine the different .o files into a single one which can't be split later. What kind of symbols do you need? Only the start of eachs data chunk? Do you have dependecies from outside? Quote Link to comment Share on other sites More sharing options...
sjc Posted June 20 Share Posted June 20 35 minutes ago, 42bs said: What kind of symbols do you need? Only the start of eachs data chunk? Do you have dependecies from outside? Yes, just the symbols for the start of each data chunk should be sufficient. And no external dependencies. For context, I'm playing with Atari's 3D example code, via the Docker version of the jaguar-sdk. The (lack of) file organisation annoys me, so I've rearranged things, moving each model into its own directory. It's these files (models compiled to .o and optional .cry textures) which I'd like to combine and pass to the final link stage, one file per model directory. Thinking about it, I might be better using ar to build an archive. I'll give that a try and see if it works. Quote Link to comment Share on other sites More sharing options...
42bs Posted June 20 Share Posted June 20 Archive are good if you only need parts. Like libc? But I guess you want all of the files, so why not just make a "assets.S" file and .incbin the data? 1 Quote Link to comment Share on other sites More sharing options...
sjc Posted June 20 Share Posted June 20 43 minutes ago, 42bs said: why not just make a "assets.S" file and .incbin the data? Yes, I think that's going to be the most compatible answer. (The alternative would be to patch rln to include the non-.o parts of archives, using the same method as when it includes other binaries. I might still do that, but it's getting further away from what I'm actually trying to do...) Thanks for your help! Quote Link to comment Share on other sites More sharing options...
ggn Posted June 20 Share Posted June 20 Hello, I guess everything is resolved now (thanks to @42bs for the quick response!) but just to be perfectly clear: rln is a linker, it produces only binaties as output. Yes, it can parse .a libraries (aout format only) and pick the .o files it needs from them. Also, it's not an issue if you want to pass everything as an .o file or as an .a - it's all a matter of how you want to organise your data. 1 Quote Link to comment Share on other sites More sharing options...
ggn Posted July 12 Share Posted July 12 We just released rmac 2.2.24! Head over to http://rmac.is-slick.com/index.html#rmac-2-2-24 for the goods. List of changes since last release: Minor fix for .incbin Removed the external dependency for dirent.h on Windows If ^^filesize could not open the requested file, it would show “(null)” as the filename 680x0 parser would fail with “reached end of line while parsing expression” in certain conditions Improved the handling of calculating expressions with labels in different sections Fixed various 56k illegal combinations of parallel moves Added hex value parsing for -Dsymbol=value command line command 56k short immediate value was not clamped, so negatives would corrupt the opcode. Thanks to Steven Tattersall for the report and fix Added a check for number of parameters in a dcb directive And two announcements: Starting with this release, the mirror repositories that were announced in the previous post are now the main. The ones used up to this point are now considered out of date and have code up until v2.2.15. We hope to rectify this in the near future, but for now please update your bookmarks and scripts. Also first for this release is aarch64 builds (for example: Raspberry Pi 5) provided Happy coding! 6 1 Quote Link to comment Share on other sites More sharing options...
+CyranoJ Posted July 13 Share Posted July 13 Nice work, guys Quote Link to comment Share on other sites More sharing options...
42bs Posted July 13 Share Posted July 13 (edited) @ggn Just two notes: * (c) year does not need to be updated unless someone new comes to the party (for example token.h) This makes merging a pain, as it looks like every file differs. * compiling throws a lot of warning because of using "%lx" instead of "%llx" for 64 values when compiling on AArch64 Mac with Clang Besides this: Great work. Edited July 13 by 42bs 1 Quote Link to comment Share on other sites More sharing options...
ggn Posted July 13 Share Posted July 13 4 hours ago, 42bs said: @ggn Just two notes: * (c) year does not need to be updated unless someone new comes to the party (for example token.h) This makes merging a pain, as it looks like every file differs. * compiling throws a lot of warning because of using "%lx" instead of "%llx" for 64 values when compiling on AArch64 Mac with Clang Besides this: Great work. "The compiler throws warnings when it wants to tell you that you're doing a good job!" -- A friend who wishes to remain anonymous. But seriously, every compiler on every system has different sensitivities when it comes to warnings, so my Visual Studio is mostly silent, and then check out what happens when I build the different targets: - Alpine Linux: https://github.com/ggnkua/rmac-builder/actions/runs/9909857765/job/27378896652#step:3:33 - Ubuntu aarch64: https://github.com/ggnkua/rmac-builder/actions/runs/9909857765/job/27378897277#step:3:1454 - Visual Studio 2019: https://github.com/ggnkua/rmac-builder/actions/runs/9909857764/job/27378896605#step:4:132 - MinGW: https://github.com/ggnkua/rmac-builder/actions/runs/9909857763/job/27378896836#step:3:27 (practically warning free) - MacOSX 12: https://github.com/ggnkua/rmac-builder/actions/runs/9909857761/job/27378896619#step:2:28 I honestly don't know how serious to take this to be honest. I might have a round of fixing all of them, but then again all these casts or whatever can make the code look bloated and hard to understand. So I'll think about it. As for the year bump - did you get merge conflicts? That's strange. If your fork contains changes that could be added back to our repo maybe send us the changes so we can incorporate them? Quote Link to comment Share on other sites More sharing options...
42bs Posted July 13 Share Posted July 13 Currently my fork contains only fixes for warnings and in the makefile some -Wno- 🙂 where I stopped adding castings: CFLAGS+= -Wno-pointer-sign -Wno-deprecated-non-prototype As for the (c) year, I just ran a "sed -i s/2021/2024/" on all sources in my repo and then made a diff. Quote Link to comment Share on other sites More sharing options...
+cubanismo Posted July 13 Share Posted July 13 9 hours ago, 42bs said: * (c) year does not need to be updated unless someone new comes to the party (for example token.h) In fact, I've heard from lawyer types the copyright year on individual files should only be updated when they have changed "substantially," where substantially is open to interpretation, but generally means something more invasive than whitespace fixes, propagating variable renaming, etc. should correspond to some functional change. Otherwise, someone could theoretically challenge your copyright claim. This contradicts many repository's stupid naive copyright-update CI checks, unfortunately. Quote Link to comment Share on other sites More sharing options...
Aesthetic Debris Posted July 18 Share Posted July 18 On 7/13/2024 at 3:38 PM, cubanismo said: In fact, I've heard from lawyer types the copyright year on individual files should only be updated when they have changed "substantially," where substantially is open to interpretation, but generally means something more invasive than whitespace fixes, propagating variable renaming, etc. should correspond to some functional change. Otherwise, someone could theoretically challenge your copyright claim. This contradicts many repository's stupid naive copyright-update CI checks, unfortunately. Sounds like rubbish to me. You are not even required to include a copyright statement, copyright is simply granted at the creation of something. So the idea it could be challenged merely by an accompanying informal message being incorrect is highly dubious. Quote Link to comment Share on other sites More sharing options...
+cubanismo Posted July 18 Share Posted July 18 What I meant was the extension of the copyright to the new year or an additional author could be challenged. Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.